The 4 Design Roles Needed for a Successful Product Team
Over the years, I’ve worked with established software companies as well as smaller, growing teams to help implement design and design thinking throughout the development process. One of the takeaways I’ve learned is that there’s often a lot of confusion about what design means when it comes to building great software products — most commonly among business stakeholders — but sometimes even among product teams as well.
It’s important to understand the different design roles that are needed to build a great product, minimize risk, reduce friction, and ensure that products solve customer problems and deliver value in a way that can scale.
Just as in fashion, where you can have a person who is great at designing clothes, but they don’t know much about the manufacturing process, in software, you can have designers who work extensively with some of the design roles needed, but not all of them. Many designers are equipped with knowledge of each of these roles. The important thing is to make sure that you’ve covered all of them and avoid playing hot potato as much as possible, or your product, business, and team morale might suffer.
The Design Researcher
In a nutshell, design research helps identify customer needs and narrow those needs down to the correct set of problems that require a solution.
This step is often undervalued or ignored altogether, while greater emphasis is placed on usability ‘optimizations’ (an arrow in the call-to-action button) and user flows, without thinking about the actual underlying problems that these micro-optimizations are aimed to address. Without discovering and quantifying the needs and motivations that drive user behavior, you may be solving the wrong problem, or you may not be solving the problem in a way that can actually scale.
The primary goal at the research stage is to inform the design process from the perspective of the end user, and avoid thinking from only your perspective, which can lead to bias. To design with the end user in mind, it’s research that tells us who that end user is, the context in which they’ll use our product, what they need from us, and why.
This requires learning about business and project requirements from stakeholders, gathering and synthesizing qualitative and quantitative data, and learning more about the motivations and needs of your likely users. Throughout the design process, research shifts to usability and sentiment. Researchers may use A/B tests, usability tests, interviews, and other methods that help them improve their designs.
Design researchers use a number of methodologies and tasks at this stage:
Interviews
One-on-one interviews can take different shapes, though there are a few primary types. Directed interviews are the most common, and are typical question-and-answer interviews, where the researcher asks specific questions. These are helpful when looking to compare and contrast answers from different types of users.
Non-directed interviews look and feel more like a conversation. There may be some guidelines or topics, but the researcher is mainly listening to the user. These can be helpful when working with more sensitive topics, where direct questions might make the interviewee feel uncomfortable.
Ethnographic interviews entail the researcher observing the subject as they go about their day-to-day in their natural habitat. The user demonstrates how they approach and accomplish their tasks. This is an immersive approach, which can help the researcher better understand the gap between what people say they do and what they actually do, and can shed light on where users feel more comfortable, or less so.
Observations
Design researchers become skilled at observing the world around them. This includes noticing subtleties when interviewing users, such as nervous tics that may signal that their interviewee is stressed or unsure, and also pick up on seemingly minor indicators that reflect an issue that should be further probed. Observation is complicated, since it’s affected by our unconscious biases. Design researchers are often adept at noting down their observations and determining whether there may be patterns across diverse user groups that they’re speaking with.
Surveys and Questionnaires
Surveys are a good way to collect many data points from a number of users to bolster an assumption or to help disprove it. They are also a good way to approach subjects that prefer to remain anonymous. There are some downsides, though, since the researcher isn’t interacting directly with the respondent. In addition, some questions or answers might be taken out of context.
Analysis
Research is a valuable research tool, but in order to fully use insights to drive the design process, it needs to be analyzed and presented within a larger context. It’s really useful only when shared. Through analyzing data, researchers can identify patterns, propose underlying rationales or solutions, and make recommendations.
The UI Designer
Many people group UX and UI design together. UX design is an umbrella term that I’m not personally fond of using, mainly because there isn’t a shared understanding of what it means, and that can be difficult when talking to clients. Google “UX” and you’ll see that everyone has their own definition. When you have a term and no one can agree on what it means, then it’s probably not a useful term — like “growth hacking.”
UX is a newer title that seems to have evolved to refer to a role that is neither a researcher nor a visual designer. I prefer to call this step ‘digital design.’ This is when we create a solution based on our research and the problems we have identified, and then validate that we have actually solved them in the best way for our end users. At this stage, designers are sketching, prototyping, wireframing, and validating their design solutions with users.
Usability Tests
Usability testing entails asking a current or potential user to complete a set of given tasks, and the researcher observes their behavior as they do so to determine a design’s overall usability. This can be useful for a product or website, for instance, when validating a prototype or even a wireframe.
There are more complex tests, which are held in person as a lab, or through video or screenshare. The user is asked to walk through the tasks and think aloud as he or she performs them. The researcher may probe with questions to help evaluate the effectiveness of the design while helping the interviewee feel comfortable.
More lightweight types of tests might be done in public, for instance, where a product with a potentially large user base is asked to try it out and complete basic tasks (in exchange for a cup of coffee or a $5 gift card). For more niche products or B2B, this approach generally doesn’t work.
Card Sorts
Card sorts are used as part of an interview or as a usability test. With these, the user is given a set of terms and asked to categorize them. This is useful for sites or projects where the designer is working with a lot of content and is trying to figure out how multiple people categorize it. The overall goal is to explore relationships between content and gain a better understanding of the hierarchies that a user perceives, which will inform and drive the design and content architecture.
A/B Tests
A/B tests are not used to figure out a problem, but to optimize a solution and choose between two competing elements — for instance, with two different presentations of content, buttons, or home screens. They help the designer understand what actions users take to accomplish a specific goal, and can help assess whether a new design is an improvement from the current version, or to prove (or disprove) another assumption.
The Visual Designer
Visual design is tied to UI design, as you cannot create a user interface without it. It entails the more graphical or artistic side of building a product and thinking about it from a stylistic perspective. Visual design includes thinking about branding — colors, fonts, and illustrations — everything that is visual and not functional, but visual design is also about connecting the visual aspect of a product in a way that can improve the overall user experience.
Visual design is the first impression that your user has with your product. It communicates a lot and is something that users generally find very comforting, engaging, and desirable. Research shows that users decide whether to trust the credibility of a digital product more on its visual clues than its actual content. Great content is important, but intelligent visual design is paramount.
Unfortunately, visual design is often a polarized piece of the design process, and treated by stakeholders as superfluous, “surface-y,” or ignored altogether. On the one hand, junior designers sometimes treat it as the end goal of great design, but in reality, it’s only one aspect of a well-designed product.
If you skip or try to save on the visual design, your users may be less likely to trust you, onboard, or use your product — thus, less success for your business.
The Front-end Developer
Front-end development and coding is a true craft. Let’s say you have a great designer with mockups and great designs, but then you need someone who can actually take the designs and bring them to life without losing all of the details in execution. This doesn’t need to be the same person, but it’s an incredibly important skill needed on the team. Without it, the handoff from designer to developer means many details often get lost in transition. From my experience, this happens quite often, unfortunately.
Not only do you have to think about pixels, but there are many other things to consider, such as web standards, working with different browsers and devices, responsiveness, accessibility, and making code work for people with disabilities. These craftsmen and craftswomen need to approach the digital product from an optimization perspective, making everything work smoothly, optimizing code so sites aren’t too heavy and animations work.
I have found that the best craftspeople are skilled visual designers and expert front-end developers, but they are generally rare to find. If you come across one, you should probably hire them as they’ll provide a substantial value-add to your team.
When Does Design Matter?
All the time. Design is something that needs to happen from day one of product conception to completion, with design, technical, and business stakeholders involved in the process to assess risk and offer feedback. Visual design often comes later in the process once a product starts to take on personality, but style guides and brand guidelines can (and should) be started early in the process.
Should Designers Be Generalists or Specialists?
It’s rare that a designer is equipped with all four roles that I mention, but there are designers that can perform most, if not all of them. My personal take is that it’s important that designers have experience with the first three, but often times, the visual and the research roles are two different people. In a larger company, there tends to be greater specialization, so it’s common that the roles are split up, although there are examples of larger teams that prefer hiring designers with end-to-end experience.
The most important thing is that all of these roles are accounted for on a product team — whether they are full-time members or supporting members that are also working with other teams. Having a process defined up front, thinking about how design will be implemented throughout the product development process, and maintaining ongoing communication and feedback is important to ensure that the process — and your product — are successful.
Wrapping It Up
The concept of a ‘designer’ is often lumped together as one role on a product team, but design entails many different roles and skillsets. There are different risks for skipping each one. If you don’t do the research, you risk solving the wrong problem. If you don’t think about UI, you’ve risked not fulfilling the job for the user and having to go back and do it all over. (Research shows that 50% of a developer’s salary is wasted on fixing errors that a UI/UX design process would have helped to prevent. Don’t let this be you!)
Product teams need to tick all of the boxes if they are going to build a successful product that solves the right problem for a critical mass, can gain traction, and scale.
