The Product Design Process: a guide for beginners

Product

How can you make an app or a product the most intuitive for people to use? Good design is not just intuitive but also memorable .

This is some text inside of a div block.

Qasim Zafar

CEO

‍

Introduction

You have an idea in mind. You want to build it. What form should it take?

How can you make an app or a product the most intuitive for people to use? Good design is not just intuitive but also memorable – it does not blend into the background, yet using it should come naturally.

Leaving a (good) lasting impression on users is important.

This is the noob’s guide to the product design process. If you have no idea of how to design a product, (but have a fairly good idea of the problem you want to solve) start here.

‍

Product Design Process – Step by Step Guide

‍

The entire design exercise, however, should only come secondary to market needs and opportunities. Once you have scoped out your market opportunity, defined user needs, and combined that feedback, you should have a rough idea in mind of what possible forms the final product may take.

Using this as a framework, you should dive deeper into what the product looks like and why. While this document focuses primarily on user-facing software, the core principles can be applied to any generic product.

‍

Initial Conception

This phase primarily focuses on concretizing user needs and putting down a defined form for the product. Does a website make the most sense? If perhaps the use case is geared towards on-the-go utility then is a mobile app a better fit? These are questions that need to be answered.

Your answer does not have to be absolutely correct at this stage, but it should be a well-thought-out starting point from where to iterate and improve your understanding of what you should build.

‍

Customer Interviews

It’s always a good idea to do multiple sets of user interviews, and at least two.

With a product in mind (or on a piece of paper), go out and start interviewing people who you think might use your application (your target persona – more on that here).

Make sure that the initial set of interview questions is verifying your product hypothesis and customer need. At this stage, it might be helpful to show customers competitor apps or use other what-if scenarios, to more clearly build the story around your product and help you understand whether you should really build what you’re building.

At AppRocket, we use Google Forms for customer interviews, which allow you to easily view all of your form responses in a spreadsheet.

‍

Wireframing and Prototyping of Mock-Ups

Based on preliminary interviews with your target user personas, you have a clearer idea of what your customer needs are and what the product should look like.

It’s time to start putting pen to paper and creating a rough prototype of what the app should look like. This is basically a set of screens that show the functionality of your app, and can be made digitally or even drawn with pencil and paper.

Essentially, an initial (or low-fidelity) prototype should focus on the overall structure and flow of the application, in particular:

‍

Mapping user flows and journeys
Navigation
Page structure and layouts
Content information and hierarchy

‍

This should be kept deliberately rough (with all the features & functionality depicted) for quick feedback and rapid iteration.

Easily available wireframing tools like Balsamiq Mockups or Sketch allow you to put together wireframes quickly, and Invision makes the process of sharing your work and getting feedback a lot easier. Many people draw things out on paper with paper prototypes.

However, I personally feel that paper prototypes are very slow and not worth the time and effort people gradually begin investing in paper prototypes.

If you’re working with teammates on this stage, you should be able to answer what is where and why, with findings gleaned from your customer interviews incorporated into the low-fidelity mockup.

I cannot emphasize this enough, the goal once again is to create a rough outline, a low-fidelity mockup of your product that clearly shows what the main user interactions and flows are, and to use this as the basis for creating a high-fidelity design and then the final product.

What Is the Difference Between Wireframe, Mockup and Prototype?

‍

User Testing with Wireframes

Here, paper prototypes have an advantage over digital prototypes made by e.g. Balsamiq Mockups, but then you can always print your digital prototypes.

The people providing feedback on your product should ideally be the people using it and if that’s not possible, then a small sample set of people from the same demographic.

Put your wireframes into an intuitive and easy-to-use form and share them with your users. Be there when they have a look. Note down the aspects of the product the testers understand, and what they don’t.

Make sure your design and product teams are both present in these sessions if possible, as it will give them food for thought on how to address any shortcomings that come up.

Every user testing session should be focused, with concrete questions you would like to answer. If you are making a food delivery app, does this app help testers seamlessly get food delivered to where they want to? Are the processes happening behind the scenes optimized towards this?

Ask specific, directed questions around different use cases of the app, and observe whether the task is easy or hard e.g.

‍

If you were to change your profile picture, how would you do it?
If you wanted to add a post, what would you have to do?

‍

And then add follow-on questions built around that particular use case e.g. how to rollback a user action or unlike something you previously liked. Note down:

‍

Any points of friction or confusion (“I was expecting do to something else”, or “I don’t know why you’ve done X this way”)
Any general comments on the UI (“this feature was nice”, or “I couldn’t find this button”)
Feature requests (“I would really like to also be able to do this”, or “If you could also add this that would be really cool”)

‍

Now using these findings, it’s your job to determine what feedback is actually worth listening to and what feedback is just noise. At the end of the day, people’s opinions are just their opinions. Incorporate relevant feedback into your wireframes.

Repeat this process until you’ve honed down what you want.

‍

Final UI Designs and High-Fidelity Mockups

At last, you’re almost there and the final product is within sight. Now it’s over to the designer, to convert the low-fidelity mockups into high-fidelity pixel-precise UI designs. Following standard design patterns here is a double-edged sword – it can lead to brilliance, or crash spectacularly.

A general rule of thumb is to follow accepted norms unless there’s a very strong reason not to. Design patterns are ingrained in most people’s psyche and easy and intuitive to understand.

Material design guidelines, for example, are highly popular and for a reason – they work. Incorporating them into your application immediately brings a familiarity to the product, and helps onboard users easily. Apps that have their own design theme such as the X-plore file manager (which is one of the oldest mobile file managers still running) often have a much steeper on-boarding curve. Something to avoid.

This is approximately the point where high-fidelity wireframes should be made before the final ‘paint’. These are very close to the final design of the product, but still primarily focused on the interactions and user experience. The idea is to depict a user experience as close to the finished product as possible, to iterate on further and improve.

However, these are often time-consuming and may be skipped if the final UI design can be iterated on and brought to perfection.

Post high-fi wireframes, the design team needs to bring the whole product together with the final splash of color, the animations and interactions, and the icons and artwork, and build the product in final form visually for the development team to bring to life. Final pixel-perfect designs are to be delivered at this point.

If you’re working with an independent or offshore design team, make sure that at this point they deliver to you at this stage:

‍

Initial high-fidelity wireframes (if that’s a step of the design process you want to include)
Full and final UI design documents (a lot of designers use Sketch these days, but Sketch is Mac-only and you will probably need the flexibility. Require Adobe Photoshop Documents (PSDs)
All the assets & design elements used in the design including any icons and any artwork or other UI elements, in PNG format (this is a process called ‘slicing’ – slicing the image into its components so that the development team can pick and place them at the appropriate points throughout the app. If you don’t get this done, you will have to export the images yourself, which will require that you have the time and the requisite software (Adobe Photoshop / Sketch / whatever).

‍

Which Is But to Say…

Designing a product is more complex than the standard ‘just as someone to put together what looks good’. Of course, you can do that, but for your product to actually be any good, there is a clearcut path to success, at least from usability.

‍

The Lean Startup methodology advocates developing a no-frills minimum viable product (MVP) and launching it as quickly and efficiently as possible. However, ‘minimally-viable product’ has lost its meaning.

‍

Which, of course, involves more time and effort than the average notion of designing a product. However, if you can incorporate the above process even partially into your design process, you should be able to come up with a much more robustly-designed product.

Want your Product to be designed by Professionals? Get in touch with us at AppRocket!

‍

Introduction

Table of Contents