The one where we tried to design a proof of concept
Written by Mario Ferrer & Sergio Vila — March 2019
Season 1, Episode 7
FADE IN: INTERIOR, MEETING ROOM — MIDDAY
A fully fledged agile, scrum focused, data-driven product team is having a kick-off meeting to start working on a new product that the business team thinks will take the market by the storm.
Everyone in the room is euphoric as they discuss how to start.
Product manager: Top of the mornin’ to ya, team. As you may know, the company’s objective for this year is to launch a new and innovative product that takes us right back to the top. I just received this report from the marketing team with some interesting market segments that will allow us get the volume of users we need. In 4 weeks we have a meeting with senior management to show them our progress, so we should plan how can we build something we can show to them.
Tech lead: Ok, we will start developing because we don’t have any design yet and 4 weeks is a very short time to have a full-working prototype. I will plan a separate meeting with the developers to decide which technologies we are going to use and start implementing them.
Designer: Well, maybe we don’t need to build something functional. If we show them some sort of dummy prototype, we could spend more time trying to understand if people actually want what we are offering them.
Product Manager: Nope, we don’t have the time. We have an experienced team and marketing knows perfeclty who our users are. It’s better to have something that works. We will dedicate some time at a later stage to see if people like it.
Designer: Ok. Maybe it makes sense for me to be in that meeting with the developers in order to have more context on what they are going to build.
Tech lead: Nah, we don’t need any designers to build the backend. We will come to you when everything’s ready.
Product manager: Yeah, that makes sense. Let’s focus on building something that works. That’s the most important thing right now.
Designer: I see… by the way, what are we supposed to build?
Product manager: It’s something similar to Google maps, Facebook, and Instagram. Everything in the same place, but don’t worry about that now. Let’s stick to the plan. This is only a proof of concept.
The team decides to start developing. They have 3 developers in the team and it’s better to have them doing something. It doesn’t matter what, as long as they’re coding.
They spend the following 4 weeks building a small version of the product. The designer jumps in a couple of days before the project is finished and only gets a chance to change some colors and icons.
The end result is as follows: a mix of Google Maps, the sign in flow from Facebook, and some social features similar to those used in Instagram and Twitter.
The BIG day arrives. The product manager presents the prototype to senior management and everyone in the room thinks the idea is the next big thing. The best of all social networks in one single place! Awesome!
They get 6 more months to work on the product. They decide to build on top of what they already presented. After a few months, they launch an MVP. People don’t understand what they are supposed to do with the product or why they should stop using the app they already use and love.
Disaster.
8 months and $200,000 later, the project gets canceled.
DESIGN DIRECTOR’S NOTES
Consider your most-engaged, loyal customers when designing or redesigning a product. If you don’t have a product out yet, identify competitor products and talk with their superfans about those products. If you design for the “average user” most likely you will end up delivering an average product no one will use.
When designing for superfans, take the time to identify who they are, talk to them, and take notes about what they like and what they dislike. If you start a design challenge by taking into account the needs of highly-engaged individuals, they will help you convince the rest of potential customers when your product’s out. Yeah… we know, that sounds like we’re asking you to take a leap of faith. Let’s put it this way: pretending people will embrace your product just because you’re offering a completely new thing is like praying for rain. With sprinkles. And chocolate chips.
Change is hard. That’s why changing the way people behave and their habits are two of the most difficult things to accomplish. Doing something is not the problem; starting something new is what scares most people. Don’t try to change the way people do things. That’s not only difficult but incredibly pretentious. Build your product taking into account people’s habits, social norms, and the way they are used to doing things.
In time, you will have some sort of impact on their habits. If you’re very good at it and you manage to get a deep understanding of what people do with your product and why they do it, you will be able to start building new habits. That said, this is like in any human relationship. It requires trust, and building trust requires time.
The Karate Kid to the rescue
We really love 80s movies. After years working in different companies from several industries, talking with a lot of product teams, and designing many different products; we discovered that “The Karate Kid” has the answer to our questions about product design.
Mr. Miyagi was supposed to teach karate to Daniel-san. Instead, he had the kid doing chores all summer long, painting stuff, waxing his car, etc. “Wax on, wax off” was one of the stern instructions repeated at the beginning of every lesson. However, the waxing technique was secretly teaching his muscles karate moves.
Product design is exactly like that: wax on, wax off = collect insights, apply insights.
- Collect insights: Way before drawing a single box on Sketch, Photoshop, or any other design tool, identify the people who will be using what you are planning to design. Then talk to them to understand better what are their challenges, goals, and limitations. Ask questions, hear their hopes and needs, and convert that into something actionable.
- Apply insights: apply all the learnings you’ve compiled and start designing something that people who are highly engaged with your product understand, expect, and enjoy using (easier said than done). You will make a bunch of assumptions, but always try to base your decisions on evidence and not just your gut feeling.
We know that right about now you’re thinking: there’s no secret formula for product success. Most of the times there are gaps between what you observe from people, the conclusions you get to from those observations, and the end result. To know if you are moving in the right direction add another step to the Karate Kid approach: test, test, test, and test again.
Evaluate your design decisions against a representative set of people to see if you were able to translate insights into your designs in the way they expected. Usability testing, interviews, surveys, focus groups... You name it.
It takes time to become a master of anything, even karate. Don’t expect the Karate Kid approach to convert you in a black belt in a week Designer-san. You need to practice A LOT. Now take a deep breath and repeat: collect insights, apply insights, test; collect insights, apply insights, test.
- Next time someone tells you “Oh, so you’re a UX Designer. What do you do?” Take a deep breath and repeat: collect insights, apply insights, and test.
- Next time someone tells you “Users won’t understand this.” Take a deep breath and repeat: collect insights, apply insights, and test.
Use evidence, not personal beliefs
Identify and fight back any personal beliefs and gut feelings from anyone in your team, starting with yours. Every time you hear something like “I’d never do that if I was a user” challenge THAT statement.
We know personal views will make their way into your product meetings so here are some suggestions on what you can do to address them:
- First of all, stop talking about USERS and start talking about PEOPLE. Talk about specific people you’ve seen using your product. Referring to people as users change the way you perceive them, they become this undefined abstract mass instead of a set of individuals. Also, most of the times the “U word” is used to throw in personal judgments and feelings not based on facts. Next time you’re tempted to refer to people using the “U word” remember this: only 2 industries in the world dub people as “users” — tech and drug dealers.
- Second, remind the people in the meeting room that they are not the person you are all designing for. Challenge their assumptions by proposing them to follow the Karate Kid approach: collect insights, apply insights, and test.
- Third, just go for it. We know getting the buy-in from teammates and stakeholders is tough (we’ve been there too) and they will most likely go for the industry standards: “it takes too much time”, “that’s too expensive”, “we don’t need it because we already know who our customers are”, etc. If that happens, apply the Karate Kid approach yourself and get back to the team with your findings. Sometimes it works to convince your team, sometimes it just doesn’t. If it doesn’t, try again. And again. If it still doesn't work after several tries, consider moving to a different team (or company).
The Henry Ford Fallacy
If I had asked people what they wanted, they would have said faster horses. —Henry Ford
As designers, we’ve all heard this quote over and over coming from business people who are not used to talking to the people who actually use their products.
Maybe good ol’ Henry didn’t ask the right question or didn’t understand what people actually needed. Don’t get me wrong, the guy wanted to build a car, he did it, and eventually, people adopted it. He accomplished a massive feat and become a millionaire and he’s one of our heroes.
Keep this in mind: It took 40 years for the car to reach 50% of households. Taking into account the fact that the average lifespan of a company nowadays is around 18 years, you better try to understand people before technology if you want your company to survive long enough for you to become a millionaire. Just sayin’…
Final thoughts
Next time you’re facing a design challenge, remember there’s always time to understand better who are you designing for. If you don’t want to build an average product, try to avoid using aggregated behaviors from users and start being more specific about the people that will be using your product. Talk to them, learn from them, and use that as an input to start designing.
One last time Designer-san, take a deep breath and repeat: wax on, wax off = collect insights, apply insights — and always test along the way.
We recommend that you read the following articles. The authors are way smarter than we are…
- Why change is so hard: the chemistry of habits by Max Weigand
- Gather insights by Mozilla
- Words matter. Talk about people by Don Norman
- Can we stop talking about “users” by Dawn Walter
- How to stop UX research being a blocker by Ben Ralph
- Forget users; think people by Kasia Luczak
Designfeld is a comedy series about a UX Designer and his fellow UX Writer, in their struggle to find… they don’t even know what they’re struggling to find, they just want to share their views on Design and why it can get quirky sometimes.
