Originally published: Dec 10, 2013
It wasn’t that long ago that we believed in a romanticized notion of the power of the talented solo designer. This individual would lean back in their chair as everyone else would await the genius idea that would emerge. “Yes! That’s it. That’s what we need to build. Thanks again, Awesome Designer. You’ve made us great again.”
It doesn’t work that way any more. And actually, it’s clear it never did.
Today, the best designs aren’t coming from a single designer who somehow produces an amazing solution. The best designs are coming from teams that work together as a unit, marching towards a commonly held vision, and always building a new understanding of the problem.
These teams create their great designs without using any magic or special formula. They create great designs by applying their design skills to the act of designing.
Design, in its simplest form, is about rendering intent. When a person makes a choice about how they want something to be, they are designing.
Do we want the glasses in the cabinet above the sink because they’d be easier to reach? Yes. We just designed the kitchen layout. We intended easier access to common items in the kitchen and we rendered that intention by placing the glasses in that cabinet.
If we intend to create great designs, how will we render that intention? That’s the role of a design process.
In our research, the teams that produce the best designs, have a process that’s geared towards forming a common understanding. That understanding needs to cover the problem they’re trying to solve, the users they’re solving it for, and the gamut of approaches they can use to get there.
Innovative designs don’t happen because of a single smart person who drives everything the team does. Innovation happens when the team creates an environment where small, powerful ideas can float to the top.
The process that a team needs to create great designs doesn’t just happen. It needs to be intentionally rendered. It needs to be designed.
We all know user research tells us about our users, what they are trying to accomplish, and how they succeed or fail with our designs (and competitive approaches). Many teams now regularly conduct user research. However, the best teams design how that research fits into their process.
It’s easy to throw together a usability test. (Well, relatively easy. It’s still too difficult to do it well, but that’s a discussion for another day.) It’s almost as easy to do a quick-and-dirty customer visit.
Executing user research is a well-understood process. Integrating user research effectively into the design process is something many teams fail at. The best teams are quite intentional about their process of fitting what they’ve learned into what they already understand.
The user researcher’s role has changed. It used to be about running studies. Now it’s about growing the team’s understanding of their users.
In this new role, the user researcher still needs to run a high-quality study. However, the real emphasis is to truly understand what the team thinks about their users. Then, using their well-adapted toolbox of user research techniques, they identify where that thinking is faulty. In time, a great UX researcher guides the team to a more accurate understanding of the user, which means design innovations are more likely to emerge.
Another archetypal process moment: We need to find out what the design should be. We do that by holding a meeting.
It’s not just an efficiency that drives us to collect all the key players and stakeholders into a conference room to discuss what the design should be and where it should go. It’s because there’s a lot of potential to have a group of smart, talented, and experienced people share their different perspectives.
Yet most teams rarely go beyond crafting the list of attendees and a collection of agenda items. Then they complain when the meeting falls flat and is a waste.
The best teams use these meeting opportunities to exercise their design skills. They think about what they intend the experience of the meeting to be in order to get the best results. They then design the meeting for that intention.
Take the act of recording the notes. In most meetings, people bring a notebook and scratch key ideas. Objective, revelations, assignments, and deadlines are spoken, but no-one is ensuring they’ve all been captured.
The best teams solve this creatively. While it’s not uncommon to designate an official note taker, it is uncommon for them to display the notes they are taking publicly, for everyone to see as the meeting progresses. Yet this technique ensures that everyone sees what’s being captured.
Multiple positive effects emerge from designing a public note-taking process for important meetings. People in the room see which points are worthy of recording, thus cementing their importance in everyone’s mind. Participants who feel their point of view wasn’t accurately recorded get another chance to clarify where they’re coming from. The notes end up having a longer lifespan and better cement the team’s understanding of the project’s objective.
Designing useful meetings has huge implications for the team. It means they need to think of their own experiences as something they have to design for. They need to collect successful “patterns” of meeting activities, just like they’d collect up interaction patterns for their designs, so they have a full toolbox of ways to make the meetings über-productive. Meeting facilitation is now a core skill for successful designers.
Projects usually start by listing out the team’s assumptions. However, they aren’t always labeled as ‘assumptions.’ Instead, they are often labeled as ‘requirements.’
Even worse, these ‘requirements’ aren’t ever questioned or tested. Validation is considered harmful to the project.
The result is even more assumptions get built upon these assumptions. And soon we have a house of cards that defines the entire project. No wonder we’re surprised when it collapses upon first contact with the users, after incurring great expenditures.
Lean UX has shown up at the right time. Our world is already under a shift because of the move to more agile development processes, and thus we’re open to new ways to approach the design process. Lean UX presents itself as a shortened upfront design approach that fits with agile thinking. Yet that’s just a ruse.
The (not-so-)hidden agenda of Lean UX is to redesign the upfront assumption process. Using experimentation, we test the assumptions and requirements to discover their validity, when it’s cheapest to do so.
The best teams approach Lean UX incrementally, testing their own hypothesis on how a design process should best suit their needs. They measure and adapt their process over time, with the goal of making it better in each iteration.
Another ruse is the critique. On the surface, we tell the team that we’ll use critique to collect feedback on a few design ideas and approaches. But that’s not all that’s happening.
Frequent, well-executed critiques are growing the team’s design vocabulary. The best teams critique current design approaches, future possibilities, competitor’s designs, and even ideas they find in the wild.
With each critique, the team engages in a conversation about what makes great design and what is undesirable. That ongoing conversation strengthens their vocabulary. Fuzzy concepts become clearer. Principles become stronger.
This new vocabulary surfaces when the team members return to their work. They start to become more intentional about increasingly subtle and nuanced characteristics in their design. A coherence emerges across the entire team.
A strong design vocabulary is key to producing great work. Embedding critique as regular activity in the design process ensures the vocabulary is constantly growing stronger.
Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter @jmspool.
Is your design process geared towards forming a common understanding? Tell us about it at the UIE blog.
Read related articles: