Published on | Prototyping: From UX to Front End — Medium Laura Martini Photo by rawpixel.com

I have a friend who was a developer working at a tech startup. Let’s call him Chris. You know the type: pasty skin from too many hours spent indoors in front of a computer along with the hunched posture to match, most of his wardrobe consisting of free t-shirts handed out by companies trying to woo ‘talent.’

Chris invited me to coffee a few years ago and asked for advice on transitioning from a developer to a designer. You see, he’d spent many hours in meetings with designers at the tech company where he worked, and saw how people listened to their opinions on strategic matters: what features to build, and why it was important to build them. He had many ideas, too, and felt that his role writing software meant people weren’t listening when he talked about anything but code. Chris had decided that he wanted to become a designer, and had already found a startup willing to let him do a free project in order for him to get his feet wet. He was wondering if I might be able to guide him in the process.

One of the things I love about design is that the field is open to people from all backgrounds and pedigrees. Each person brings a unique blend of skills — fine art, engineering, anthropology, video production, English literature, etc. — and together diverse teams can help solve even the toughest of wicked problems. However, the fact that anyone can learn to be a designer also means anyone can call themself a designer. Unlike titles requiring a credential, like Doctor, Lawyer, or Professional Engineer, anyone who who can wield a Sharpie and a Post-it or download a free trial of Balsamiq can take the title of Designer and run with it. However, that doesn’t mean everyone has the skills to be a good designer. I told my friend that I was happy to support and mentor him as he tried out the role, but warned him that the transition may be trickier than he realized.

We met again a couple of weeks later. Chris told me that the project was going well, which I was happy to hear. He had dozens of great ideas for the startup, and was sure one of them was the right solution for the problem they’d asked him to work on. But he was stuck, and needed my help once again. Chris wanted to know: Of all of his ideas, which one should he tell the startup to build? After a moment to reflect on what I would do in that situation, I told him that the only way to really know was to start mocking up the different designs and testing them with users. He wouldn’t need to build every single idea, but he could only start to know what would work by trial and error. Chris was not happy with this response, having expected that I could help him narrow down the list of ideas just by talking through them in an abstract way.

Photo by William Iven

When I informed Chris that he’d have to roll up his sleeves and start producing, he informed me that he did not want to be that kind of designer. He did not want to messy his hands with making: sketching, building, and doing user research. He was more interested in being the ideas person. It was at this moment that I realized that Chris had some glaring misconceptions about the role of designers. It was like he had decided to be a movie star because he wanted to attend the Oscars, but didn’t want to bother with going to auditions, memorizing lines, or spending long days on set. He just wanted to dress up and attend the ceremony at the end. Or, in this case, make the big reveal presentation to the client at the end of the project without slogging through the interim steps.

I don’t blame Chris, since he’d mainly worked with designers in meetings, and had never looked behind the curtain to understand the work that went into forming design opinions. Like most things, it looks a lot easier from a distance.

If you’re in the same place Chris was, and aspiring to become a designer, here are things you might find helpful to know about the field that might not be obvious when you’re looking at sites like Dribbble or Behance.

1. Defining the problem is often harder than designing the answer

Photo by Mike Tinnion

Every time I start a new project, I’m itching to jump right into sketching out ideas. It’s satisfying to see your imagination come to life on a piece of paper or pixels on a screen. And in an environment where everyone is in a hurry, there’s often a lot of pressure on designers to just hack something together. But I have learned that jumping right into mocks is a mistake, because the solution I’m designing might not fix the heart of the problem.

A simple example of this came up once when I was working on a medical product for a startup. There is a part of the software where doctors can see all of the patients who have left the hospital during the past two weeks. One doctor asked if we could show all patients from the last month instead. On the surface, this seems like a straightforward problem, and one that would just take a few minutes to sketch it up and hand off to an engineer. All they had to do was change the code so 30 days’ worth of people showed up on a list instead of 14 days’ worth.

However, I asked why she specifically wanted 30 days instead of 60, 90, etc. With this single question, I learned that the doctor had a monthly meeting where she presented interesting patient cases to other doctors. She wanted to use the tool to look up those few patients before her meeting — a tedious task, since she could usually just remember the symptoms the patient had and didn’t always know their name. Her current process involved reading through a list of hundreds of people just to find the handful she wanted. It turns out that showing a month’s worth of patients would solve her problem by filtering out patients who had been discharged from the hospital before her previous monthly meeting, making her task shorter. However, the shorter list wouldn’t solve the problem very elegantly.

Photo by Negative Space

What the doctor was asking for was a specific solution. What I needed to do as a designer was step back to understand the underlying need she was expressing, then propose the right solution to address that need.

Ultimately, the team designed a way to tag patients who have interesting stories and make it possible to search for those patients you’ve tagged. We would not have come up with this solution if we’d been in a hurry to just start building her request for a list showing a month’s worth of patients.

Before beginning any design task, no matter how small, I try to answer the following questions:

What is the problem?

Example: Users want to find specific patients who have left the hospital

Who has this problem?

Doctors preparing for a monthly meeting where they present interesting cases

What evidence do we have that this is a problem?

Phone call with Dr. Nick on 03/06/2017 and repeated requests from business team working with this hospital

Why are we working on this right now?

Related to Company-wide OKR to do XYZ this quarter

What does success look like?

5% of users at this hospital use this feature on a monthly basis

You don’t always have to answer every question, and for small features success is often just “it’s now possible to accomplish this task” rather than a trackable metric. But if you can’t succinctly state what the problem is and who has it, then chances are you don’t have the clarity to start building.

2. Guess-and-check is the only method for solving tough design problems

Photo by Brad Neathery

When my engineering friend Chris asked me about the first step to choosing the right idea, I told him to start making mocks to see which ones worked the best. You can’t know if something is the right answer until you try it. This “guess-and-check” method is not unique to design; it’s just the only way that truly complex systems can be solved.

As an undergrad taking a class in differential equations, I remember going to the TA and confessing that I needed help learning one of the skills we were working on. Essentially, there were four possible forms a solution could take, and the only way I knew how to solve a math problem was by randomly picking one, then trying it out to see if it worked. If the first one didn’t work, I’d try the second one, repeating this until I found the right one of the four. The TA reassured me that guessing and checking was the only way to solve the problem. Eventually, he said, people who solved a lot of differential equations started to build up an intuition about which of the four forms a solution might take, so their guesses start to be correct the first time. But the only way to build that intuition was to practice a lot of math problems. The same holds true for design.

Just like with the math problems, the only way to know if something would work is to try it out. Should you use a dropdown menu or radio buttons? Left-align that text or center-align it? Use a sketch or a photo on that web page? A bar graph or a line chart for that data viz? The quickest way to get to an answer is to mock up as many directions as you can in a low-fidelity way (hand sketches or black-and-white wireframes, for example) and see which ones make the most sense when you actually see them.

Even designers who’ve been practicing for decades often need to see something before they are convinced it’s the right answer. And unless you’re just making something for yourself, I can guarantee that your client or other stakeholders will need to see a few different options before they are ready to choose the best one.

3. Expertise takes a long time to achieve, and practice is the only way to get there.

Chris the engineer had 100 ideas, but didn’t know which one to pick. He didn’t like my recommendation to get his hands dirty and start prototyping; he wanted to be in charge of the strategic work, not the “grunt work.”

Photo by Barn Images

This is like saying you want to be the conductor of the orchestra without ever having played a musical instrument yourself. While conducting and playing are different skills, and a person can conduct people who are more talented musicians than they are, you still need to understand the nuances of the craft before you instruct other people on how to execute. And understanding your craft requires practice.

Making mocks and testing them isn’t the “dirty work” of design, it forms the core of what designers do. Anyone can have a lot of ideas. The value comes from knowing which one is likely to be the right idea to execute on. And knowing which one is the right idea comes from having tried a whole lot of wrong ones first.

As Apple eloquently puts it in this video about design (which is absolutely worth 90 seconds of your life to watch):

there are a thousand no’s

for every yes.

— Apple

<a href="https://medium.com/media/3d649a49399b310a1f9e0221580b80c4/href">https://medium.com/media/3d649a49399b310a1f9e0221580b80c4/href</a>

It’s oddly similar to the game of chess: Anyone can have an idea for what piece to move, but the value comes from knowing which move is most likely to be the winning one.

In the book Moonwalking with Einstein, a fascinating read on how memory works, the author explains how expert chess players literally see the chess board differently than novices: Their brains do not see individual pieces so much as they see the story of what is happening.

Photo by Crown Agency

It was as if the chess experts weren’t thinking so much as reacting… they described their thoughts in different language than less experienced chess players. They talked about configurations of pieces like “pawn structures” and immediately noticed things that were out of sorts, like exposed rooks. They weren’t seeing the board as thirty-two pieces. They were seeing it as chunks of pieces, and systems of tensions.

How do they train their brains to do this? Many years of practice, and playing countless games of chess. What might look like innate talent to a casual observer is actually intuition built up from the memories of thousands of past games. The author points out that “Even Bobby Fischer, perhaps the greatest chess prodigy of all time, had been playing intensely for nine years before he was recognized as a grand master at age fifteen.”

Anyone can have a lot of ideas. The value comes from knowing which one is likely to be the right idea to execute on.

When my friend Chris was sitting in the meetings watching designers give their opinions, it felt like their ideas were no more valid than the ones he was coming up with. He wanted to move a rook, they wanted to move a knight. Who was to say which play was more valid?

What was invisible to him was the countless hours of practice that those designers had. Even if they couldn’t always articulate why theirs was the winning move, the designers’ intuition, honed from many years of playing the game, made it statistically likely that their idea was the correct one. If Chris wanted his opinion to carry the same weight, he would need to have more projects under his belt so his brain could start to see patterns and themes instead of individual data points.

4. You need to be good at storytelling to help people understand the right answer

Let’s say that you’ve gone through the work to hone your design skills. You’ve rolled up your sleeves, put in thousands of hours of practice, and can now feel confident in calling yourself a Designer with a capital ‘D’. Congratulations!

Photo by Climate KIC

But now you’re in a meeting with a bunch of other people — engineers, product managers, marketers, and other smart folks you’re working with to make a product. You might think that your ideas are the best, because you’re the one who “owns” responsibility for design and has spent the most time thinking about the problem from that angle. And, let’s be honest, if you’re good at your job, your opinions are probably correct.

That doesn’t mean that your idea is perfect, however. The best designs, judged by impact to the company, are ones that balance requirements from all of the teams involved. If you design a beautiful product that only works on desktop, but your marketing team is focusing on selling your mobile app this year, is that really a good design for the company to build? What about a feature that could increase your revenue by $1000 a month, but would take 80 hours of extra engineering time to build — is that the right tradeoff?

In order to answer these questions, you will need to work with non-designers. Doing this effectively requires a completely different set of skills than the ones needed to sketch or prototype. You’ll need to know how to tell the story of your design so you can “sell” it to your colleagues or clients, while keeping an open mind to their valid and constructive feedback.

Photo by Jonathan Velasquez

This section could easily be its own blog post, but for now I’ll just share some highlights:

Hold a work session where you use “dot-mocracy” for people to give feedback on what they like and don’t like about the current design. While design and product will ultimately select a direction, it’s invaluable to have people from customer service highlight designs that might confuse people, engineers weigh in on which directions are most feasible to build, and marketers pointing out which features will help align the product with the brand you’re selling to users.
Make sure collaborators are trying to solve the same problem you are. You’d be surprised how often people argue about a solution to something because they don’t agree on the problem they’re solving. For instance, let’s say you’re working on a project to show lab information to doctors, and they complain that they have a hard time knowing if a patient has any new test results. If the underlying problem is that they aren’t getting alerted, then a solution could be to send them a text message. But if the problem is that data looks the same whether it came in 10 minutes ago or 10 days ago, then a solution could be to highlight results from the last 24 hours so it’s easier for doctors to see what’s new when they log into the product. These are two very different solutions to the same customer complaint of “It’s hard to know if my patient has any new lab results.” If you and the rest of the team disagree about the problem, it will be difficult to agree on the solution.
Don’t be territorial. Engineers will often have great ideas that solve the same core problem, but are much faster to build. Legal teams can be helpful, too, in coming up with creative ideas that work for customers while keeping the company compliant with the law. As long as you’ve put time into articulating the correct problem and communicating it, I’ve found that nearly every team at the company can give you useful input.
Use data and stories to support design decisions. Filter out the noise until a clear story starts to emerge from interviews, analytics, and other ways you can get qualitative or quantitative feedback on your product. While you may have your own opinions of what story the data is telling, it’s also important to share this information in a neutral way that allows the other team members to form their own opinions. For example, communicate raw user quotes from interviews, rather than just saying “we spoke with 10 users and all of them want feature X.”
Be visual. Show a few options and discuss the pros and cons of each one. The ability to create mocks and prototypes is a powerful tool that few non-designers have at their disposal. Having any type of visual, even if it’s just something you sketch on a whiteboard during a meeting, facilitates communication and ensures you’re truly aligned with your cross-functional partners at the end of a conversation.

5. You’re going to be bad at first

You know that phenomenon of watching something on TV and thinking it looks easy? Like when olympic figure skaters make triple jumps look like a breeze, then you go to the ice rink and find out how hard it is just to stand on skates?

If you’re not embarrassed looking back at work you’ve done in the past, then you’re probably not growing quickly enough. If I showed you the t-shirt I designed for my high school swim team, or the stuffed animal / clock hybrid I made in college, you would probably advise me to pack my bags and look for a new career. It’s only by going through the phase of being bad that I was able to push through and become decent.

All designers are their own harshest critic, and I doubt you can find a single one who isn’t constantly practicing and trying to make themselves better. I was on a train recently and ran into a design professor of mine from Stanford who was on his way to take a drawing class. This man has been teaching others how to design for longer than many professional designers have been alive, and yet he was still excited enough to keep honing his own skills that he would rush off to take a class after a long day of advising and teaching others. It’s that passion for continual improvement that fuels young designers past the painful early stages, and keeps older designers engaged in their work.

Ira Glass, host of This American Life, describes it perfectly:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

If you’re an aspiring designer, I hope you find this glimpse behind the scenes to be more inspiring than it intimidating. There are many roads that can take you the end destination — university, boot camps, online videos, apprenticeship, and more — and each one of those paths can teach you how to be a bonafide designer. My goal with this article is to give you perspective on the challenges you’ll encounter along the way, and what the destination actually looks like when you get there.

P.S. My friend Chris recently jettisoned the title of Product Designer, ultimately deciding to found a startup.

Tips for an aspiring designer was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tips for an aspiring designer

Cool stuff, every week

More Articles