How being ruthless can make you a better Product Designer.
As a young designer, my approach to assignments resembled family planning: I conceived ideas, developed frameworks, and delivered polished interfaces to an expecting client. It was a “waterfall” approach to creative production, an artifact of agency-thinking.
While a methodical process, it was also a painful one.
So much thought and polish went into any one idea that changes were often gut-wrenching, time-consuming exercises. Creative Directors criticized the typography. Engineers balked at the technical complexity. Clients freaked over prices. Every slice of their scalpels hurt me somewhere deep inside, regardless of the rational exterior I projected. Some days, I felt like a man-boy raging against the machine, working countless hours to polish designs that rarely made it through production intact.
In retrospect, it’s obvious why everything felt so monumentally difficult:
No one taught me how to kill my babies.
Lesson 1: How babies are made
Be it a vintage car, sterling sliver flatware, or conceptual mockups for a user interface, all it takes are the right circumstances for someone to form an irrational attachment to an inanimate object. Objects become personal over time by virtue of their familiarity. Subsequent experiences may then reinforce a particular feeling of specialness. Given enough time (and emotional stimulation), the ordinary becomes extraordinary, growing into an out-sized version of reality. Finally, the victim is blinded to any suitable alternative, in spite of all the evidence suggesting otherwise.
That’s when a “baby” is born.
Lesson 2: Why babies are bad
This is fine for weekend mechanics working alone in a garage. Their babies will grow up to become timeless tributes to human invention. Avid polishers of family heirlooms shouldn’t worry too much about their behavior either. In either case, their babies do not require any other approval in order to exist.
For product designers, however, baby-making is an especially unhealthy, disruptive practice.
Creativity comes at an emotional cost for many practitioners – so even straightforward assignments can quickly become personal. In turn, creative people are prone to making babies precisely because they take their work too personally. If those attachments are tolerated or nurtured, small details will soon get in the way of stuff that truly matters, and can cost designers valuable relationships. (Oh the bridges I’ve burned by arguing about typefaces and button styles!)
Lesson 3: Prevention is key
As professionals, we are expected to separate our Self from the problems we were hired to solve. For some, maintaining a professional distance from creative work comes naturally. Personally, I’ve had to learn how to translate what I feel into more appropriate, productive responses.
For example, whenever feedback from a teammate or client triggers an emotional response, I ask myself a simple question:
Is the feedback about the details, the execution, or the idea?
- “Make the filter menu options blue” = about the details
- “I don’t think users will use those filters” = about the execution
- “Our users won’t filter” = about the idea
- “Put more product shots on the home screen” = about the details
- “Add a gallery” = about the execution
- “Our mobile app should be more product focused” = about the idea
Based on the answer, I then determine a response according to a few rules:
If it’s about the details, they’re not worth spending personal equity over. Be willing and eager to compromise. Sometimes a designer can gain helpful allies by giving up on small details early on. That trust can be used later, when it is more critical to the success of the project.
If it’s about the execution, the designer should present a stronger case through research and analysis. Nevertheless, it’s not worth a war. Perhaps further exploration is indeed warranted. Or maybe other possibilities were explored, but it was not adequately demonstrated why those options were inferior. When all else fails, basic user testing will settle almost any dispute.
If it’s about the idea, then a designer should defend their idea with authority, clarity, and in terms of how it would advance the goals of their stakeholders. The only people who care about design awards work at agencies. Everyone else cares about effectiveness, efficiency, or scale. How does the idea solve both the business and user problems? How does this idea solve those problems better than other solutions? Does it allow for future growth or refinement?
Through applied reasoning, I can identify my pet-attachments more easily – and then smother them quietly before they develop limbs! The real secret is to do this every single time. Consistent practice has lessened my sensitivity over the years, and has allowed me to develop new, automatic responses.
Still, some babies will survive – which is why I test early and often. Overwhelming negative results diffuse strong attachments better than any self-help exercise. Yet I’ve also learned (the hard way) that any testing will have its limitations.
Lesson 4: Testing is a tool, not a solution
Agencies are hired to produce a final product, so they typically reserve user testing for the end to “validate” their vision (if at all, and only if the client pays for it). By the time real users actually experience the final product, both the agency and the client have usually moved on, and how it performs matters only insomuch as it leads to another Statement of Work.
Product companies tend to do the opposite. “Big ideas” are costly, resource-hungry, and technically complex to implement. Unless the company is building something from scratch, there’s already a core product fully developed. As such, most testing is tactical by nature, pitting one variation against another to find the most “optimal” solution. Unfortunately, while classic A/B testing is great for refining details or exploring alternative executions, it is not an ideal methodology for comparing different ideas – especially big ones.
This is when moderated studies or field research become critical to fleshing out a larger story. Moderated studies can provide detailed feedback, personal anecdotes, and measurable outcomes about specific product features. In-home interviews can reveal more about how users think about the Web generally, or how it intersects with their daily experience. However, there is one notable disadvantage to “going deep” like this: Scale. Most of these include less than 12 subjects. That’s hardly representative of any single audience, let alone several.
In other words, research will point in a general direction, but rarely reveal the final destination. In fact, research may lead the researcher astray, and even reinforce babies through favorable results.
For this reason, I’ve started using a simple framework that consistently yields the most meaningful results, without injecting my personal biases into the outcome.
Lesson 5: Results depend on the strategy
There are three basic types of user tests…
- Unmoderated tests are task-oriented, and measure the success or difficulty users have completing a specific action. Most tests take only a few minutes to complete, and all inputs are measured to identify pain points or confusion. Results are available immediately.
- Self-moderated tests are those in which testers talk out loud as they perform a task or answer questions. Their inputs, voice, and activity on screen are recorded. Quantitative data is rendered as charts and graphs for instant analysis, but videos must be viewed, transcribed, and analyzed by a human. Although final results and analysis take longer to complete, the information gathered is rich with user sentiment, candid commentary, and deeper insights.
- Moderated tests require a professional researcher, real people, and often a living room environment (in-home, or recreated at a testing facility). The researcher guides testers through a set of tasks and asks open-ended questions in real time. Tests of this nature last anywhere from 45 minutes, to an hour and a half. Once all the sessions are complete, the researcher gathers those results and produces a detailed presentation – complete with background, personas, data, analysis, and recommendations. The time and money required to conduct just one moderated test with several participants is substantial, and in-home “field studies” are exponentially more expensive.
Since each methodology has inherent limitations, a designer should likewise have a strategy for what to test, when, and how. (Otherwise they consume all their resources for minimal benefit.)
Taking all this into consideration, the following is now my approach to testing:
Use moderated tests to identify new opportunities, or a common user problem. They will capture how real users feel about real products on the Web, while still leaving plenty of room for innovation. “Big ideas” should ideally spring from this well of research, or at least directly solve the user problems identified therein.
Use self-moderated tests to vet proposed executions of a particular idea. This is how I seek and destroy every baby possible. Intentionally pit competing executions against one another, measure them equally, and evaluate the results impartially. If done well, the winning execution should determine the best place to start iterating.
Use moderated tests to fine-tune the experience. Once the Big Idea has been distilled into a minimum viable product (MVP) that real users can interact with – that’s when rapid, tactical testing helps me refine the interface or simplify the experience. I fully aware that nothing is ever perfect, and even the best solution now may not be a good one later. But by testing every feature, at some point, I find it easier to spot deficiencies that warrant moderated testing. Sometimes problems resist my solutions altogether, and moderated studies become necessary for further insight.
So far, applying this formula has killed nearly every baby I brought with me to Mozilla, and has helped me abort the ones I’ve made since.
As a product designer, I will always feel a sense of “ownership” over the things I create. I may take things personally, or secretly harbor inappropriate feelings on occasion. At least now I have the tools to avoid making babies when possible, and ruthlessly weed out the ones I’ve been secretly protecting.
These days, I care more about idea babies than the design babies. Design details can be modified far easier than overarching ideas. Getting regular feedback from users enables me to let go when it’s not critical, and dig in when something is.
Of course, I’ve only learned to develop this perspective the hard way… After fighting too many of the wrong battles.
So don’t be like me. Don’t let your babies become bigger problems later on, and get in the way of work that matters.
Be ruthless from the beginning.