Before getting to my process, I feel it’s important to understand my role as a product designer. I think Eric Eriksson, a fellow product designer, puts it best when he says:
So with that explanation, I think it’s easier to understand all the different stages of my process and approach when solving problems.
Define the Problem
Review & Iterate
Define the Problem
Regardless of whether it’s a new feature or updates to an existing feature, I feel it best to begin with a kickoff meeting. During this meeting we discuss requirements, timeframe and deliverables but my main focus is around answering these three questions:
What problem are we solving?
Who has the problem?
What do we want to achieve?
After gaining clarity on the initial project definition, I then start doing my research (which includes user and market research).
If possible, I like gathering information through user interviews from those who regularly use the product. This technique helps me to assess user needs and feelings before a product is designed. I find it the best way to get answers quickly and allows us to dive deeper to identify key insights from our users.
If speaking directly to users is not possible, then online surveys is another great tactic to use. While you are not able to get fully detailed in your questions, they are perfect for quantitative data—and fast and inexpensive to put together.
To be competitive in any new product or feature, you need to know what’s already out there and how they perform. That’s why market research is a crucial step in my product design process. The way I go about it is to actually use the different products that are similar in concept or idea and analyze them. This allows me to compare different ideas and strategies and also helps me to identify opportunities where I might be able to do a better job.
This stage of the process is all about getting ideas out. It’s usually when the team gets together to have brainstorming sessions to start thinking about a number of different things. There is no judgement in these meetings, we actually encourage people to say whatever they may be thinking—even something that might sound crazy could trigger a really great idea. During these sessions, we also storyboard out scenarios to better understand how people could interact and use the product in real life situations.
By this time I usually have a pretty good understanding of what problem we’re trying to solve and how we should go about it. It’s pretty much the perfect time to start mapping things out. I begin with creating a user flow. User flow’s help visualize the complete path that users follow across the whole solution. Once that’s done, I wireframe all the different pages and elements that came from the user flow. Wireframes are created to start thinking about content hierarchy and to articulate what kind of UI elements we should use and where.
The major goal of this step is to offer a visual understanding of the design to get the approval from the stakeholders. This check-in with the team is critical and allows us to adjust the design early so we’re not wasting time down the road.
Now time for my favorite part of the process, creating mockups and building out a functional prototype. Using the wireframes as a blueprint, I start creating realistic representations of the product. I bring in all aspects such as the brand colors, fonts and icons and start designing in Sketch. After that, I usually move to either Invision or Principle to build a prototype. I feel a prototype is one of the most important deliverables for the following reasons:
it acts as an experimental model which enables us to test it with users before building the final solution
it is also is a great resource for developers to use when implementing the design as it shows not only the visuals, but also what the different interactions and transitions should look like
Time to test and validate our solution. Since we have dedicated UX designers at Netspend, they are usually the ones that take the lead here. We bring in actual Netspend customers to our usability lab and run them through the prototype. While I’m typically not the one that gives the interview, I’m always there to observe from another room and take notes.
I also help the designers by pointing out anything that users might struggle with or provide questions I’d like to have answered during the session beforehand.
Review & Iterate
We review the feedback gained from our testing sessions and discuss any hurdles that we may have noticed. From there, we make decisions about anything we want to fix or adjust. If it’s something major we may even do some more testing to see how the new design performs.
As for digital products, there really is no such thing as a “finished design” but at this point we’re ready to get this thing built. That means it’s time to transfer all of my ideas to developers for implementation. I do three main things here to makes sure everything is clearly communicated:
Deliver design specs (colors, type styles and measurements)
Deliver the working prototype (flows, behaviors and functionality)
Explain everything throughly and make sure to answer any questions during the handoff meeting
I also make sure to leave the door open for communication and do regular check-ins to make sure the design is looking and behaving as expected.
It’s important to note that in almost all circumstances the design process has a lot of overlap—it’s not as linear as it might look or seem. There are numerous meetings throughout, a lot of back and forth, and sometimes we need to jump from step to step in a different order than shown above. At the end of the day, it’s all about learning as much as possible about the problem and solving it the best we can.