Five years ago, it was all about UX, but we saw through that. At the time, we were pretty stoked about figuring out the best way to get to answers in product design (still are!). However, we realized that there aren't a lot of designers out there that understand what it actually means to be a product designer.
UX is one part of it, but what are the rest of the pieces? This is the story of how you too can become a product designer. So stop being a UX/UI guru or prophet or whatever and start solving problems.
The Values of a Product Designer
Product designers not only need to have a core set of skills, but a few key values as well. Embodying these values is just as important as being able to solve an interaction design problem or code up a page.
Balancing customer needs and business goals
This is the bread and butter of a product designer — the baseline requirement. If a designer isn't able to do this, they're not a product designer. Why? Because product designers should aim to find that sweet spot between customer needs, business goals and technical feasibility. These three areas are what blur the lines between a designer and a developer in the "traditional sense," and the reason why we've done away with those tired concepts at ZURB.
Keeping an open mind
Product designers get excited about new ideas, and doesn't always shoot things down. In turn, they aren't afraid to question their decisions, or let other people build off their ideas.
Knowing when to say no
Conversely, a product designer also knows when to say "no." More importantly, she'll know how to say no — backing up her decisions with data, customer feedback or her own past experience. Because she understands the customer needs, business goals and technology, she's able to justify her design decisions and move the product forward rather than run around in circles.
These values are a riff of our own ZURBian values. We consider everyone on our team a product designer, including engineers. So if skills are only one part of being an awesome designer, how do you turn these three values into practice?
Breaking News! You're Now a Customer Advocate!
You'll hear a lot of UXers talk about empathy, which sounds really warm and fuzzy, until you realize that you don't really know what that means in the context of a product. Here's what it really means: when a feature breaks in your product, you will do everything in your power to fix it for your users.
Which goes to say, if you don't know what the problems are … you certainly won't figure out what future ones. Product designers need to invest themselves in customer problems to anticipate future problems that might come up.
No one on the team is exempt from customer advocacy. Simply put, everyone involved in the product is a customer advocate, including designers, engineers and marketers. Typically, a designer won't interact directly with customers, and that can be incredibly detrimental to the design process, whether the designer is working on a client project or an internal one with a team. You can't think of customer advocacy as just a 'customer support problem" or an "engineering problem." It's your problem too!
Engineers Are Product Designers Too
Product design happens when decisions are made, and everyone should be decision-makers, including engineers. While designers should write their own code, engineers should likewise be trained in the same product design process.
A small team with a designer/engineer pairing is one of the most effective way to build a product. The designer should be constantly asking the engineer for her feedback on implementation and technical feasibility, while also trying to stay in front of problems. In other words, they need to be continually collaborating. But in order to have a nimble team like this, you need to have a few things in place:
- Clear Communication: This goes without saying, but seamless communication with few barriers as possible is essential. The barrier could be really simple. Laura likes to send her deliverables over email and Bill only checks his inbox once a day. In this case both peeps need to figure out a communication method that works well for both of them. In other cases, the communication problems could be deeper, and the earlier you identify and work on them the better your process will be.
- Blurred Lines: Don't overdefine the roles. Designers should code their own design work, so they can continue to work through the interaction nuance that only really comes up once a design is in code. Engineers should also contribute to the interactions by giving feedback and sketching out ideas. After all, there's no room to get territorial in product design.
- Detailed Spec and Testing: Designers should clearly spec out their static code before they hand it off to an engineer. A typical designer-to-engineer handoff at ZURB contains two things:
- Static Code: This is the complete static code for the feature in all its different variations and error states. This is delivered in a shared Git repo.
- Annotated Set: The feature spec is created by the designer in an annotated Notable set that highlights all the functionality that needs to be implemented.
These are the absolutely necessary pieces to a functional collaboration. We'll also usually create an issue in the Github repo to track discussions and updates around the feature, and use it to handle assignments.
Of course, the designer's work isn't done with the handoff. That communication needs to be maintained during and after the feature is built, when it's up to the designer to comprehensively test every interaction in the feature. We use a spreadsheet for every major feature, and document every single interaction and state in that spreadsheet. We then test those interactions, and if an interaction is A-OK we mark it as green. Otherwise we highlight it in eye-bleedy red and create an issue in Github for the bug.
It's so satisfying when this…
turns into this…
Those Who Don't Know History Are Doomed to Repeat It
Effective product designers need to stay ahead of the rest of the team, which means that they'll often have to be the first person to spot a bug or come up with an idea. The best way to stay ahead is to know your own history. Efficiency is crucial to staying out in front, so designers have to be careful and not reinvent the wheel. For designers new on a product team that has existed for a while, this means doing a lot of homework to learn why certain design decisions were made, and why the product functions the way it does.
As we build the new Notable, we were working on getting rid of the Organize feature because, through our own use and customer interviews, we found that people were mostly confused by the feature and never used it. Our design problem was: how do we maintain the existing functionality of the Organize feature, without tossing all that functionality into a separate confusing page? After a few iterations, we realized that we'd just reinvented the same feature and called it a different name. We ended up completely rethinking the functionality and its purpose, coming up with a much simpler solution.
You Can't Solve Problems in Photoshop
Studies show that 90% of designers will jump into Photoshop/Sketch to solve problems1. Product Designers will ask why five times before implementing any feature. They'll create prototypes, run tests, check analytics data, talk to customers, and discuss ideas with their team. Notice how Photoshop isn't required for any of these things. Drop Photoshop and start designing products. Unless you're working towards a deadline, in which case what are you doing reading this article?
Designers shouldn't be using their tools as crutches in product design, because most of product design happens outside the computer.
1. Not a real study
The Rise of the Gut Thinkers!
So where does a product designer fit into a progressive design process? A product designer should be the person driving decisions, even if they're not directly making the actual decision. The product designer has the experience and guts that allow them to influence informed decision-making among the team. We've learned two things about product design from working on our new Notable release:
- You need a really convincing reason for why you should add or remove a feature
- Getting those convincing reasons involves a lot of work that a typical designer isn't typically trained to do
Take for example the next version of Notable. We wanted to make sure that we were maintaining all the existing features. Bryan sent the team a list of features that were in the old version that were missing from the new version. While working with the customer advocate through the list, we noticed the Nudge feature was on there, and our gut reaction was, "who even uses that?" When we built the first pass of the new Notable, our first instinct was not to build the feature, and focus on features that were more valuable. We needed a good reason to convince Bryan that this feature wasn't necessary, so we turned to our analytics. We tracked the Nudge feature in the existing app for two weeks, and the results we found will shock you!
Turns out, our gut was right! A mere 0.1% of our users used the Nudge feature in those two weeks. We were able to push back on the feature and focus on other more frequently used features.
That's No Moon…
You might be asking yourself why anyone would want to become a product designer at this point. Well, because it's amazing. You get a feeling of certainty that you wouldn't get with say, a purely visual design role. Practicing product design trains you to think with your gut but not rely on it. Product design allows you to empathize with your users and make sure you're solving business problems too. Figuring out a great flow for your team is how you can get everybody on the same path, whether they speak Photoshop, Rails or Wookie.
Product design is about teamwork, because it's really hard to learn to do all this stuff by yourself. Product design problems are kind of like the Death Star — they're big and intimidating, and can seem almost invincible. By identifying the problem, getting the right team, then getting that team to work together seamlessly you can take on any Death Star.
Notable, our product design platform, is now in private release! Get access today!