It’s no secret that good design is good business. In recent years, even the most engineering-driven companies are snatching up design talent as if it were going out of style.
But the path to better products isn’t as easy as just hiring designers by the hundreds. When it comes to implementing design processes, company culture must adapt to the new user-centered strategies. The new breed of designers are equal parts ambassador and problem-solver, helping companies understand that it’s more important to solve the right problem than to design the perfect solution.
New York, are you ready?
We’re building Momentum: an all killer, no filler event this November.
Designers are quickly taking up the mantle of design leadership as their influence spreads. But as the altitude increases, the air also becomes thinner. Executives crave certainty while designers thrive in ambiguity. Unless designers can think and talk like businesspeople who’ve mastered design, they might find themselves at the bottom of the totem pole instead of the top.
In order to stay atop, designers must deliver results as Mills Baker, Facebook Product Designer, puts it:
“In order to avoid losing its place atop organizations, design must deliver results. Designers must also accept that if they don’t, they’re not actually designing well; in technology, at least, the subjective artistry of design is mirrored by the objective finality of use data. A “great” design which produces bad outcomes — low engagement, little utility, few downloads, indifference on the part of the target market — should be regarded as a failure.”
In this piece, we’ll explore tactics that help designers earn their seat at the table and keep their new responsibilities.
Understand Business Goals Like a Second Language
Before you can show others the light, you first need to see the world through their eyes. Designers help build products, and the end goal of every product is revenue – there’s nothing subjective about that.
We’re not saying that every designer must go out and earn an MBA. But every designer must understand the larger context of who they’re designing for and why the project was initiated in the first place.
What’s the market cap of your industry? Where does the current product you’re designing fit into long-term goals? Who are the top competitors, and where do they succeed or fall short? You probably won’t know the answers right away (and sometimes stakeholders might not even tell you upfront), so it’s your responsibility to tease out the information from the right people.
Just as you must empathize externally with users, don’t forget to also empathize internally with people on the product team and beyond. Here’s a few tips to get you started:
Learn from other departments
Ask if you can sit in on a sales demo for an initial prospect, or a closing meeting with someone further along in the process.
When it’s done, learn about the buyer and why a certain linguistic approach was used. That way, you’ll better understand product nuances, which can help inform your approach to product updates or future product development.
It might sound daunting, but you’d be surprised by how receptive other teams are toward a designer’s interest in their job. You’ll also be able to strike up a conversation and explain how you approach certain problems, and how you might envision possible improvements based on live customer calls.
2. Interview stakeholders
Like we described in Design Collaboration in the Enterprise, you should always interview stakeholders as one of the first steps in a design kickoff.
Aside from asking technical questions, try to understand them as people. Reassure them that certain questions are off the record, then ask about their fears for the project and what concerns their team on a weekly basis. You rarely get one-on-one time with some of these stakeholders, so use it as an opportunity to make a strong impression.
To learn more, we highly recommend Kim Goodwin’s Stakeholder Interview Checklist.
3. Speak the right language
It’s easy for us designers to get lost in the world of “clean interfaces,” “responsive frameworks,” and “fluid interaction design.” But sometimes the people making the most important decisions think in terms of “monthly churn,” “conversion rates,” and “net income.”
Don’t start spewing business jargon, but try to frame design problems as business problems. Instead of saying that a minimalist interface creates a cleaner impression, explain that it places greater focus on the content and calls-to-action, which helps to persuade and convert users better.
Grigoriy Kogan has some further thoughts on the matter, which are blunt but very true.
4. Stay updated on how design intersects with business
We’re big fans of Smashing Magazine’s Business section and Google Venture’s Library because they provide practical design perspectives on very real and pressing business issues. To bring fresh perspectives to your own company, you must learn beyond the daily grind.
Whether it’s virtual learning or a real mentorship, seek the wisdom of others.
Image Credit: Smashing Magazine
Once you have a stronger business grasp, you also have a stronger position from which to defend your design decisions. It might feel like extra work in the beginning, but better business fluency always pays off in the long-term for your career. It certainly helped me tremendously when authoring UX Design for Startups and the UX Guidebook for Product Managers.
Lift the Curtain on the Design Process
At first, you might feel that you’re weakening your position by divulging the secrets behind the magic. Don’t.
The benefits of collaboration and mutual respect outweigh any concerns your designer’s ego might have. That ego, which we all experience in some form, certainly isn’t easy to overcome. But you must welcome others in the process or else your work dies a lonely death — because no one will be your advocate within the organization.
This happened to me early in my career. At the time, I was a UX designer on an IT frontend team. My work was always being questioned because I was the first UX designer hired and seen as someone who would be interfering with their product development cycles. As a result, I had little influence among the team. I delivered wireframes, prototypes or the usability testing results and it didn’t create an impact among the developers. They carried on as they did before I came along.
An animosity festered. The developers firmly believed the interface was decoration for technology. Analytics were for business, not to learn more about the users. So the developers had no clue as to what worked and what didn’t.
From my perspective, it was maddening, so I fought for dominance. It wasn’t until months later that I realized there was nothing to be gained by instigating petty fights. I’d put the developers on the defensive rather than getting them on my side. Bickering between departments and specialists is silly when you’re all working toward the same goal of creating an amazing product.
Things turned around when I adopted a more inclusive philosophy. Here’s a few activities below that helped me demystify the UX design process.
Collaborative usability research
Watching how users interact with your product will reveal many “Aha!” moments for your team. You can have a marketer and developer conduct contextual interviews with users in their natural environment. This will allow them to get firsthand explanation of any problems, reducing the time it would normally take to understand it.
Collaborative testing sessions immerse stakeholders in the user’s world, which primes them to better receive your suggestions.
2. Design studio workshops
Invite your team to a collaborative brainstorming session that relies on sketching. These design studios help generate a lot of ideas upfront and clear the air with everyone involved. You might encounter some resistance (e.g. “You’re the designer! You draw!”), but remind people that you care about their ideas and not the artistic execution.
Rough and dirty is actually preferred. Grab some pen, paper, and people and follow Kevin Hoffman’s process. Don’t think that this will devalue your position. Instead, this exercise will solidify it because you’ll be explaining why certain ideas have merit based on the business rationale, human psychology and design principles.
Not the easiest concepts for anyone to master, but that’s why you’re on the team.
3. Weekly/monthly “what we solved” emails
Don’t waste words on vanity metrics, such as the number of prototypes tested. Focus on insights gained from analytics or user testing.
Did last week’s usability test reveal a huge flaw in the form completion process? Did your team fix it and do the analytics show an increased conversion rate because of it? That’s what you should include because it’ll get the attention of the higher-ups and demonstrate your value to the business.
The goal of all these activities is to show that “design processes” are really just good business processes. Designers don’t retreat to darkness and emerge with brilliant mockups in hand. We analyze, we question, we iterate, and we validate ideas with users and other team members to make sure we’re solving the right problems.
Show others the real process at work, involve them in some collaborative activities (even if they only have time for one), and they’ll see you less as a visual designer and more as a product problem-solver.
Analyze and Present the Right Data
Data is the language of business — there’s just no getting around it. To be a good designer, you need to be a good scientist.
You need to collect the right data and explain it in the right context. But don’t go overboard and fall into the trap of data fetishization (like Google did with their 41 shades of blue test).
Understand that user data is the single strongest source of evidence for design decisions. Furthermore, being data-focused makes others perceive you as the same category of more “traditional” disciplines like marketing and finance, and nobody really questions their value.
Here’s some tips that have helped me explain design decisions in a more empirical format:
1. Go beyond A/B testing
A/B testing is probably one of the most familiar data-oriented exercises for designers, but it’s not the end-all solution. A/B testing is tactical, and you can easily hit the limit of the local maximum. Instead, triangulate your results with other forms of data: customer surveys, product usage metrics, user interviews, etc.
2. Ask users the right questions with the right people
At some point, you need to get out of the office and talk to potential and current users. The process, however, shouldn’t be conducted in isolation.
When UXPin first moved to the United States around 2012 to build our web app, we conducted over 50 user interviews with designers. But before that, we met with marketing and development people, then spent three-four hours determining knowledge gaps before coming up with a list of 20 questions. Input from other teams prevented us from needing to follow up with interviewees due to missed information and made the interviews feel more like a product exercise instead of a “design exercise”.
The difference seems petty, but perceptions are very powerful – especially in larger corporations where design is still perceived as a black box.
3. Think in terms of assumptions and hypothesis
When she was at Intuit, the UX team conveyed customer feedback suggesting that they simplify multiple tiers of products into one license. Executives resisted, until the team tested their assumption on a small set of users using the experiment grid and found the single license sold better. With the quantitative data in hand, they sold the executive team on the idea and that single-license product now outsells everything else.
Photo credit: Alissa Briggs
Moral of the story? Learn hypotheses-driven UX design.
But it isn’t enough to just present that data. You need to weave that data into a narrative that executives can relate with and digest quickly. Because, as Google’s Daniel Waisberg points out, the combination of data and meaningful story engages people on both an emotional and intellectual level.
Don’t Let Others Drive Design
A final word: don’t let other drive design within the organization. Remember you’re the expert, you have the domain knowledge.
But don’t think that you’re the only who can design. If you think that everyone on the team has the ability to participate in the design process, you’ll be able to help them see the true power of design. And that also allows you to create design through them rather than just implementing it.
As Jared Spool highlights, play the role of design leader rather than designer. In other words, be the driver, not the passenger – but make sure everyone still knows where you’re going.
If you’d like to learn more about collaborating in the design process, check out the free e-book that our team of designers and writers helped create. We’ve done our best to focus as much as possible on helpful exercises and mentalities.
I’d love to hear your experiences in the comments below.
Image credit: Shutterstock