Probing requirements for design clarity
Demystifying how designers, product managers, clients, and stakeholders can get to design deliverables faster.
In my journey as a Product Designer, I have had to work on projects of varying intensities (Android + iOS, user dashboard + admin dashboard + email templates e.t.c), in different sectors (health, finance, cryptocurrency, data, travel e.t.c), of varying team sizes (me+cofounder, 5+, 50+), and something common to them all is requirements. How requirements are communicated to a Product Designer affects how the problem gets solved.
Take a look this scenario
Imagine you just had a long phone call with a client where he has outlined a big list of requirements for the next big app (e.g Uber for laundry). What’s next? Where do you go from here? How do you get from these verbal requirements to design clarity?
What you need is a requirements expression.
While requirements elicitation is the act of teasing out the needs from the wants, requirements expression is the act of getting those needs into some usable form.
Most projects a designer works on can be generally classified as either a new design (of a feature or a product from a blank state) or a redesign (of an existing feature or product). And while the project type, timeline, team size e.t.c all affect the way requirements are elicited and ultimately expressed, I have found these 3 methods to always be better than verbal requirements, a BA doc or some project contract:
User Stories
User stories are meant to keep all of your requirements in a consistent format. They are easy to write, easy to read, and easy to evaluate. A good user story is that which clearly outlines a specific software requirement in the product.
The general template is:
As a “user/admin”, I want to be able to do this “action” so that I can achieve this “outcome”.
Please find examples below:
- As a user of this restaurant app, I want to see the menu, so that I can see what meals are available.
- As a user of the restaurant app, I want to see the bill with all the items in order, so that I can see how much my order will cost.
- As a user of the restaurant app, I want to be able to select a “Pay Now” option when I view my bill, so that I can pay the bill.
User Flows
User flows are used to determine the interactions with a product in more detail. It is a useful technique for making sure the entire development team is aware of the functionality and flow of a product. While this acts as a UX guideline for a designer, it still provides abundant creative freedom
User flows excel well in their attempt to provide a clearer approach to interpreting requirements into design deliverables rather than just depending on natural language descriptions.
There is really no general agreed template for this. But they can be created with pretty much any design tool, since they are just bunch of shapes, texts and arrows. I recommend Balsamiq, Paper Sketch, Drawing on a board e.t.c
Below is an example of what a user flow looks like.
General tips you could use:
- A rectangle shape can represent an action, a view or a content node.
- The page stack is indicated with three overlapping rectangles. You will use a page stack to account for multiple pages of similar content. Think about product detail pages, news items, or blog posts.
- Horizontal arrows tell us which pages are connected or how we get from one flow to another.
- Vertical arrows can indicate a sequence of flows that must be completed in order e.g. a 3 step form
- You can use a dotted line to indicate that a connection is based on a specific condition.
Wireframes
Wireframes are basic visual representations of a product. They focus on basic functions and end user tasks to be supported. They are like architectural blueprints as they help you think about where you are going to put buttons, text fields, and images.They show what goes where without getting hung up on final design details.
Higher level concerns such as which typefaces, images or colours to use are not addressed here at all. Some designing is okay, but you need to be careful that you’re not prematurely developing a solution. Wireframes can be user- tested to detect wrong design assumptions.
There are many different tools out there for developing wireframes but I personally use Balsamiq. You can draw them digitally or on paper and scan them. Either way, you’ll want to allow paper and digital versions for easier communication and discussion.
An example of wireframe is:
Conclusion
Requirements do not have to specifically come from the client. There are many ways to elicit additional requirements. For example, you can interview end-users to see how they work, what they want, and what they like.
But while there are several techniques to elicit requirements, expressing these requirements in forms where we can start having progressive design conversations has always been challenging. Requirements expression are particularly important to designers since: A problem can only be solved within the limits of what is understood to be the problem. Expressing requirements in these forms can help the team have healthier discussions with the aim to solving the intended problems.
These methods have helped me in my work, and I am open to other methods
