Shayne Bowman’s Post

Over the years I've tried many approaches to design critiques with the teams I've managed. Without fail these 4 simple principles impact the effectiveness of design critiques greater than anything else when established as ground rules. For presenters: ✦ Describe the problem you're solving ✦ State the target audience* ✦ Specify the feedback you're seeking All of the above can be done in less than a minute, either verbally or in written format. For participants: ✦ Ask questions before comments "I think you should go with blue instead of red" is less effective than first asking "Why did you choose red for this?" The additional context that comes from asking questions will lead to more effective feedback. Design critiques are the easiest and most important thing design teams can do to improve design quality. Alone they are not a silver bullet. But they are the foundation for all other improvements to design quality. If you're not holding regular design critiques (usually weekly), this is step 1 for improving design quality. If you're already holding regular design critiques but not doing the 4 principles above well, this is step 1 for improving your design critiques. Better critiques. Better quality. * "Everyone" is rarely acceptable as the target audience. Even if the feature being presented is intended for everyone, 99% of the time there's a specific segment or archetype you're aiming for. #design #critiques #quality

We're hiring a senior product manager to lead the exploration and delivery of new opportunities for our ADP Mobile app users 🚀 🤖 Hit me up if you think you're up for a new challenge 😎

🐑 Business Language vs. UX Language. How to present design work, explain design decisions and get stakeholders on your side ↓ 🤔 Businesses rarely understand the impact of UX work. 🤔 UX language is overloaded with ambiguous terms/labels. 🤔 Business can’t support initiatives it doesn’t understand. ✅ Leave UX language and UX abbreviations at the door. ✅ Explain design work through the lens of business goals. 🚫 Avoid “consistency”, “empathy”, “simplicity”, “affordance”. 🚫 Avoid “design thinking”, “cognitive load”, “universal design”. 🚫 Avoid “lean UX”, “agile”, “archetypes”, “Jobs-To-Be-Done”. 🚫 Avoid “stakeholder management” and “design validation”. 🚫 Avoid abbreviations: WIP, POC, HMW, IxD, PDP, PLP, WCAG. ✅ Explain how you’ll measure success of your design work. ✅ Speak of business value, loyalty, abandonment, churn. ✅ Show risk management, compliance, governance, evidence. ✅ Refer to cost reduction, efficiency, growth, success, Design KPIs. ✅ Present inclusive design as an industry-wide way of working. As designers, we often use design terms, such as consistency, friction and empathy. Yet to many managers, these attributes don’t map to any business objectives at all, often leaving them baffled and utterly confused about the actual real-life impact of our UX work. One way out that changed everything for me is to leave UX vocabulary at the door when entering a business meeting. Instead, I try to explain design work through the lens of the business, often rehearsing and testing the script ahead of time. When presenting design work in a big meeting, I try to be very deliberate and strategic in the choice of words. I won’t be speaking about attracting “eye-balls” or getting users “hooked”. It’s just not me. But I won’t be speaking about reducing “friction” or improving “consistency” either. Instead, I tell a story. A story that visualizes how our work helps the business. How design team has translated business goals into specific design initiatives. How UX can reduce costs. Increase revenue. Grow business. Open new opportunities. New markets. Increase efficiency. Extend reach. Mitigate risk. Amplify word of mouth. And how we’ll measure all that huge impact of our work. Typically, it’s broken down into 8 sections: 🎯 Goals ← Business targets, KRs we aim to achieve. 💥 Translation ← Design initiatives, iterations, tests. 🕵️ Evidence ← Data from UX research, pain points. 🧠 Ideas ← Prioritized by an impact/effort-matrix. 🕹 Design work ← Flows, features, user journeys. 📈 Design KPIs ← How we’ll measure/report success. 🐑 Shepherding ← Risk management, governance. 🔮 Future ← What we believe are good next steps. Next time you walk in a meeting, pay attention to your words. Translate UX terms in a language that other departments understand. It might not take long until you’ll see support coming from everywhere — just because everyone can now clearly see how your work helps them do their work better. [continues in the comments]

Wondering how much people in product design make at Wise? Curious about what a Design Chief of Staff does? Ever heard of a content designer actively working to shape org-wide design culture and careers? Find out! Now you can listen in on my conversation with Nikki Godley and Rob MacFie about the extraordinary work they’ve done at Wise over the past few years. What they’ve accomplished in a very short period of time isn’t just inspiring — it demonstrates what truly empowered designers can accomplish at scale when given the time and space to do it. (Side note: I was so blown away by their smarts and poise that I found myself actually *nervous* every time I spoke with them, which almost never happens. That right there should tell you something.) Enjoy! https://lnkd.in/gUXffNMP

Isn't it time to stop using the term "user"? Taylor Majewski has written an excellent article about the use (and misuses) of the term "user." Although I used it in 1987 when I edited a book entitled User Centered System Design, since then I have argued against the term, saying, hey we are human beings, people, so why not call us people. (When I switched to "human centered" I am now sorry I didn't say "People-Centered.") The article is in Technology Review (an excellent magazine about technology): https://lnkd.in/gFTGJFMD. Taylor covers this -- and other issues.

Ethan Evans is a coach, writer, teacher, and retired VP at Amazon. During his 15 years at Amazon, he helped invent Prime Video, Amazon Video, the Amazon App Store, Prime Gaming (formerly Twitch Prime), and Twitch Commerce. He led global teams of over 800, holds more than 70 patents, and helped draft one of Amazon’s 14 core Leadership Principles, “Ownership.” In our conversion, we discuss: 🔸 The Magic Loop framework for rapid career growth 🔸 Why L6/M1s get stuck in their career 🔸 Advice on how to break out of a career plateau 🔸 How to cultivate inventiveness in your work 🔸 How to stand out in interviews 🔸 A personal story of failing Jeff Bezos, and lessons learned 🔸 Much more Listen now 👇 YouTube: https://lnkd.in/gCt5UHjA Spotify: https://lnkd.in/gKGb9W45 Apple: https://lnkd.in/gGuz57PE

🧭 How To Manage Challenging Stakeholders and Influence Without Authority (free eBook, 95 pages) (https://lnkd.in/e6RY6dQB), a practical guide on how to deal with difficult stakeholders, manage difficult situations and stay true to your product strategy. From HiPPOs (Highest Paid Person’s Opinion) to ZEbRAs (Zero Evidence But Really Arrogant). By Dean Peters. Key takeaways: ✅ Do your research to understand their perspectives. ✅ Show how your strategy supports business goals. ✅ Attach your decisions to a goal, metric, or a problem. ✅ Have research data ready to challenge assumptions. ✅ Explain your tradeoffs, decisions, customer insights, data. ✅ For one-off requests, paint and explain the full picture. ✅ Give some technical insights to explain your decisions. ✅ Study how to keep them engaged and on your side. ✅ Create a space for small experiments to limit damage. ✅ Build trust for your process with regular key updates. One of the most helpful strategies I’ve been using is to provide full transparency about the work we are doing. The decision making, the frameworks we use to make these decisions, how we test, how we gather insights and make sense of them. It’s much more difficult to argue against real data and a real established process that has led to positive outcomes over the years. Stakeholders rarely know how we work. They rarely know the implications of last-minute changes. They rarely see the impact of last-minute changes based on hunches. Explain how your work ties in with their goals. Stay high-level if you can, but don’t be afraid to get technical if you must. In the end, we all we come with our biases and expectations. Support your stakeholders, and you might be surprised how quickly you might get the support that you need. Useful resources: The Delicate Art of Interviewing Stakeholders, by Dan Brown 🤎 https://lnkd.in/dW5Wb8CK Good Questions For Meetings With Stakeholders, by Lisa Nguyen, Cori Widen https://lnkd.in/eNtM5bUU UX Research Studies to Win Over Stubborn Stakeholders, by Lizzy Burnam 🐞 https://lnkd.in/eW3Yyg5k How To Run UX Research Without Access To Users, by yours truly https://lnkd.in/erb-nMiE #ux #design #research