Designing without a Designer
On any team, there are two groups.
- The people who make the design decisions.
- The people who refer to themselves as the designers.
The first group is the most important.
A Tale of Two Designers
Meet Designer Anne. She just came out of a meeting with the developers on her team.
At the end of the meeting, the lead developer turned towards her and asked if they could do one of those sketching sessions. Anne was floored. That had never happened before.
The developers had been mulling over a change in direction for the project. They’d bumped into some new constraints in what the product could and couldn’t do. Now, they had to come up with a new design to make it happen.
Anne tries to be with the team as much as possible, but she has other responsibilities to other teams. So the team is often left to design on their own.
Lately, their designs have turned out ok. They’ve gotten better since she started working with them.
The lead developer wanted to sketch out some ideas with Anne. He wanted each designer and the product owners to be there too, sketching out their ideas. (Basically, he was asking for what we’d call a design studio, but he didn’t know that’s what it was called.)
Anne is happy. This was big.
Meet Designer Jay. Jay just came out of a meeting with the developers on his team.
During the meeting, Jay learned that the team had been moving forward on the project while he wasn’t there.
To make progress, they had to make some decisions about what the screens would look like and how they would flow. Jay was displeased. If only they’d waited until he came back.
Like Anne, Jay tries to be with the team as much as possible, but he also has other responsibilities to other teams. His team was left on their own.
Jay would prefer they wait for him to return instead of making design decisions. He’s the professional and he knows how to do this well. When they make decisions like these, it makes more work for Jay. Now Jay has to undo “the damage” they’ve done to his design
Jay sighs. This is hard.
[Anne and Jay are real designers from our research that go by different names.]
What Happens When You’re Gone
In an ideal world, designers are always present to make every design decision. Yet, in the fast paced world of developing products and services, designers are a scarce resource.
In any product or service, thousands of decisions have to be made. Some affect every aspect of the design. Others only affect a small interaction or a tiny piece of the product.
It’s a rare team that always has the designer available to make every decision immediately. The ratio of non-designers to designers is usually quite high. Designers are often responsible for more than one project simultaneously.
That means we have to figure out what happens when the designer isn’t present and a team member is facing a decision. One approach is to batch up all the decisions and have the designer work through them when they can. The other approach is to let the team make the decisions themselves.
Which approach will deliver the best quality product or service? Which will get the team to a good result quickly?
Non-Designers Gonna Design
When the developers and project stakeholders start making their own decisions, Jay and Anne have completely different reactions. Jay’s reaction is one of frustration, while Anne’s is one of glee.
Jay wishes his developers would leave the designing to him. After all, he’s a specialist with experience. He doesn’t go mucking about in their code.
Anne has a different approach. She thinks everyone can be a designer.
Some of this comes from her background. She never went to design school, like Jay did. While she has as much experience as Jay does, her knowledge of design came from picking things while building products.
Jay’s design school education was hard work. Since school, he’s worked on dozens of projects. The best ones were the ones where everyone just followed his designs. Unfortunately, that doesn’t happen enough and it’s definitely not happening on this project.
Jay wishes the other team members would stop trying to design. Anne pushes her teammates to do more design.
Polar opposite reactions with different outcomes. In the long run, Anne’s approach turns out to be more effective.
Design for Non-Designers 101
Jay’s complaint is that the other team members can’t tell if their design decisions are any good or not. They guess at a design result, often choosing something that makes the design worse. Jay doesn’t like having to tell them they’d done a poor job.
Of course, Jay has tried to teach them what he learned in school. He’s held brown bag lunches where he’s gone over design fundamentals. He worked on a style guide to show them what to do, but he couldn’t get them to follow it.
Nothing has stuck. Jay’s teammates still make the same poor decisions. Jay now prefers to work on the design and hand it over to the team. Now that the team has moved to an agile process, he’s struggling to get the designs done before each development sprint.
Anne’s approach has been different. When she joined the team, her first assignment was to go through what the team had already done. She found most of the screens to be poorly designed, with a lot of jargon and extra work for the users to do simple things.
She immediately scheduled usability tests and invited the developers to watch users work with their designs. The outcome was as she predicted: not very usable.
Initially her teammates were deflated, but they caught on quickly. And saw the opportunities for change.
Anne never held brownbag lectures about fundamentals. Instead, she went to the whiteboard with the developers and sketched out new designs. She explained why she was changing things.
Eventually, the developers started coming to Anne with their sketches before they started implementing anything. She’d share what she thought would work and what she thought might be an issue for the users.
Over time, she told us, the developers would start to critique their own work. They were getting better.
Raising the Bar to Conscious Competence
Whenever someone tries to do something new, they are what we call unconsciously incompetent. They don’t know how to do a good job and, more importantly, they can’t tell if they are doing a bad job. They often imitate what they see others do. That doesn’t get them very far because they don’t know what or why it doesn’t work.
Some folks will progress to consciously incompetent, where they learn that they aren’t good at doing this. While many folks stop here, some will press on and try to learn how to do it themselves.
Those folks who learn how to do a good enough job have become consciously competent. They can make good results happen most of the time, though they often don’t know the underlying theory as to why. (Think of someone who can follow a baking recipe and create great cupcakes, but doesn’t understand the chemistry of baking.)
When both Jay and Anne joined their teams, their fellow team members were unconsciously incompetent at design. While Jay’s teammates haven’t progressed beyond conscious incompetence, Anne’s team is firmly on the way to conscious competence.
The Role of a Design Leader
On his team, Jay plays the role of the designer. There’s nothing wrong with being the designer on the team. It’s an honorable role and we need all the designers we can get. But, when Jay’s not there, design stops until he returns.
On her team, Anne plays the role of the design leader. She’s leading the rest of the team to create their design. Her job is less about creating the design than overseeing the creation of the design.
Anne’s team is learning to continue designing when she’s away. They won’t do as good a job as when she’s there. However, every day, they’re getting better.
Design Leader Tool: Exposing the Team to Users
Upon joining the team, one of Anne’s first activities was to set up visits to several users’ workplaces. She brought stakeholders and developers with her on each of the visits.
They met with users and watched them use the existing processes and tools. For folks who couldn’t come, she streamed the meetings over the Internet.
The team saw how users really worked, versus imaging how the users worked. They got a chance to ask questions and explore the details of the users’ tasks. They saw the hacks and process enhancements the users had created for themselves.
Anne kept exposing the team to users throughout the process. They tried out ideas and got instant feedback. The users, who were initially cautious of the changes, became increasingly interested and started offering their own ideas. It became a true partnership between the users and the team.
Exposure to users is a key tool for the design leader. It gives the team a way to move beyond opinions by seeing what users really do.
Design Leader Tool: Reflecting on Work in Progress
When a developer was working on a screen, Anne would ask to see their work in progress. She wouldn’t tell them what the design should look like. Instead, she’d use the whiteboard as a way to talk about what the alternatives were.
Over time, she’d have the designers try their own hand at designing, giving them course corrections when they went down a wrong path. Their designs started to improve through the process of collaboration.
Using reflection as a basic approach, she would get the developers and stakeholders to talk about their designs in terms of what the users were doing. They developed their own dialect and a sense of what the design should accomplish. Reflection is another essential tool of the design leader.
Design Leader Tool: Vision of the Future Design
Once the developers and stakeholders were comfortable talking about how the current design was working, Anne started to introduce ideas of what the design could look like in a few years. As they talked about current feature, she’d throw in something like, “Wouldn’t it be cool if eventually the computer could do all this work so the user didn’t have to manually enter it?” Some ideas were rejected, but some gained an enthusiastic response.
Anne started to notice what ideas were resonating with the team. And, of course, once she started doing this, other team members would suggest their own futures.
Over time, she started to collect these different ideas into a more coherent vision of what the overall experience could be like. She would socialize these ideas through regular discussions. For instance, when they were talking about the specifics of a current feature, she’d throw in how this helped them get to the future experience.
Eventually, the developers began repeating the vision as they talked to each other and to the stakeholders. Then the stakeholders started using the vision as the framing of their own ideas. The vision is another tool that helps the design leader keep the team on track.
Design Happens When Designers Aren’t There
The most successful teams are teams where everyone has reached a conscious competence with their design skills. They can keep moving forward to the overall vision of the project. And through a constant exposure to the users, they can check their ideas and make improvements.
If an organization wants to have their product and/or service user experiences be their competitive advantage, they have to invest in design leaders. They must spread the knowledge of design throughout the organization. The tools of exposure, reflection, and vision become essential in that journey.
How to Win Stakeholders & Influence Decisions program
Gain the power skills you need to grow your influence on critical product decisions.
Get mentored and coached by Jared Spool in a 16-week program.
Learn more about our How to Win Stakeholders & Influence Decisions program today!