We've all been there - the project that just doesn't turn out like you hoped. You've gone over your work with the team repeatedly, and it just seems like nothing's really sticking. Maybe the design wasn't up to your standard, and you weren't sure why. Or there wasn't a lot of energy to launch the product. Or worst of all, precious time and energy was spent, and users just didn't care for it, dooming your product to stasis and death.
How did you react?
If you're like me, a flood of questions come to mind which can quickly turn into self doubt. You start to think, 'Why didn't I catch this earlier?' Or maybe you're more intuitive, and could FEEL that something was wrong all along, but didn't know what it was or what to do about it.
[Cue sleepless nights, binging on your favorite vice, and endless daydreams about finally opening that boutique coffee shop' and making millions.]
You might even have a great process. At ZURB, our's is highly iterative, involving quickly creating, showing and reacting. Maybe your process has some similarities. This is a great way to mitigate risk in the resource-intensive task of bringing a quality product to life. So how come projects can still go wrong?
The problem lies in how most of us started our design journey. In school, we're taught to care for every pixel, so as designers, we work on mastering great deliverables so our work is successful. But as you know if you've been in the profession for long enough, 80% of design is actually about communicating, discussing, and making decisions on ideas. When are we taught how to master communicating with the people who could kill our projects?
Asking the right questions in the right places
Luckily at ZURB, we get lots of practice. Every day, we have the privilege of designing world-class software with hundreds of companies, from venture-backed startups to multi-billion-dollar conglomerates, and we've discovered a few insights that help us communicate to build successful products.
Insight #1: Every project has different groups involved in them, and it's critical to understand who they are as early as possible.
.jpg?1482347883)
Three common groups we've found in our project work are:
- Stakeholders - This is anyone who has some sway over the direction and momentum of the project. They might have an official title of influence, have some informal authority that makes others defer to them, or even be customers who have active investment in how the project turn out.
- Collaborators - This is anyone who has some skill that can add to a project's success. These could be formal collaborators placed on the team or others whose expertise you respect.
- Users - This is anyone who will end up using your product (who aren't always the same people as your customers, who primarily make purchasing decisions). This could be current or prospective.
Who are the groups of people involved in your project? By being aware of how the people involved in your project fit, you'll be able to understand who you have available to help you make good product decisions, and not miss out on talking to someone who's feedback might be critical.
Insight #2: Because of factors like convenience, power dynamics, and fear of failure, we tend to ask for feedback that these common project groups are specifically unequipped to give, dooming our design decisions with bias and inaccurate data.
- Stakeholder - We tend to think of how we can please those with power, and so we prioritize making decisions solely based on 'what they like', keeping us from making bolder design decisions based on data from real users
- Collaborator - since collaborators tend to be most accessible, we tend to go to them first to 'test our ideas'. Because we avoid conflict, we end up with a frankenstein product that incorporates their idiosyncratic and often contradictory advice on how our experiences 'should' be to 'make sense to them'
- User - IF we talk to users (and many teams don't), we tend to overly guide conversations so users will agree with our decisions and confirm our biases
How much does your communication mirror these behaviors? Getting the wrong feedback can cause you to inaccurately think users will think/behave like collaborators, stakeholders know what is good for the business all the time, and what users report is actually what they do.
Insight #3: Great designers have mastered HOW and WHEN to get the right feedback that makes products successful
- Stakeholder - since stakeholders have influence over the product's direction, momentum, and sometimes purchase, great designers leverage communication to achieve ALIGNMENT on the direction that best meets business and technical needs.
- Collaborator - since collaborators have relevant skills and knowledge to offer, great designers leverage communication to solve difficult problems that if not solved, can break the experience of the product
- User - since users are the ones with the need for the product and will be incorporating it into their lives, great designers leverage communication to validate the problems, ideas and usability of the product
If you could know something from each of your project groups right now based on how they're equipped, what would that be? By getting the right feedback (and avoiding the wrong kind), you can make thoughtful design decisions that solve major experiential issues, is in touch with real needs and desirability, and stay in a reality that your whole team is committed to building.
Get woke now
There's the old adage that you can't design in a vacuum. Stakeholders, collaborators, and users are common groups all integral to a project's success, and it's never too late in a project's timeline to reframe how we interact with each group to put our products on the best path for success. Stop appeasing stakeholders, blindly incorporating collaborator feedback, and putting words in users' mouths. Instead, start influencing stakeholders, problem-solving past stuckness with collaborators, and validating your designs with users to take your designs to the next level of success.
