April 11th, 2024, posted in learning
by Adelina
This is the first article in a three-part series called “A design-first approach to writing great user stories”. In this series, we talk about why we need to approach product discovery in a more visual way and how to do that in order to write better, more useful user stories. Check out the rest of the articles in the series here:
Intro: A design-first approach to writing great user stories
Part 2: Turning your UI/UX designs into user stories
Part 3: How to estimate user stories for improved planning
If you want to read more on our development process as a whole and how we help businesses go from idea to app, also check out our MVP series.
In the intro article, we talked about why, contrary to popular belief, user stories are not a good tool for mapping out requirements. What we suggested instead, is a design-first approach to product discovery. If the hardest thing about building apps is requirements and the hardest thing about requirements is communication, then this approach addresses both. How? By using each of these tools for what they work best:
- High-fidelity mock-ups and prototypes are a better tool than user stories for gathering requirements because they are visual. Stakeholders, product owners and everyone involved can literally see the requirements they are trying to capture and they can “feel” the product. This allows for better communication within the team, less misunderstandings and something tangible to agree upon.
- User stories are a great tool for providing context, clarifying and expanding upon what the designs explicitly show. Think of user stories as the “documentation” for your designed screens. Something everyone can fall back on, including developers, when building the app.
In this article, we'll be looking at how to use high-fidelity mock-ups and prototypes to figure out requirements. We`ll also be going through some tips & tricks on how to organize your designs in order to make them easily translatable into user stories.
Start from the end
Most people don't really know what they want until they see it. That's why we work with high-fidelity mock-ups right from the start. High-fidelity mock-ups are basically how the end product will look and feel in the most minute detail. They are pixel perfect representations of the app, both in terms of looks and functionality. They are a great tool to gather feedback because they are accurate. And they also save a lot of time. Time which you would otherwise spend reviewing wireframes and low-fidelity sketches, only to reach the final design three months later and start the review process all over again.
Below is the high-fidelity mock-up and the coded end result for a real estate analytics and reporting platform we built.
After we design the screens for all the core flows, we schedule feedback meetings with the stakeholders. In some cases, when the app is particularly complex, we might focus a feedback meeting only on a particular flow, for example onboarding or inventory management.
During the feedback meetings, we generally start out with questions related to the look of the app. We aim to approve things such as color palette, iconography, fonts, page layout, as well as repeating elements like navigation. Once we establish this, any new feature or screen will follow the same design patterns and overall aesthetics.
After agreeing on the look, we use the feedback formula to discuss functionality. What is the feedback formula? It's a way to make sure you are getting useful feedback from stakeholders and that you are properly communicating the type of feedback you are looking for. The formula is: (what/who + context/problem + stage + feedback instructions) x tools. You can read more about each element of the formula in the following article.
This saves a lot of product discovery time because it allows you to address looks and functionality literally in the same meeting.
Drop the diagrams, design flows instead
We know, it's hard to imagine product discovery without diagrams. What we prefer to do instead is to take the high-fidelity mock-ups we created and organize them into flows.
Let's take a look at an example. This is an internal project we built, the back office of a tech recruitment platform called YourTopPeople. In this flow, an admin can see a list of all active and inactive positions. From this view, the admin can add a new position by filling out three sections: Basic Position Information, Client Information and Extra Details. In the “Client Information” section, the admin also has a quick add option for new clients.
Even without “zooming in” on the details, both literally and figuratively, this flow already gives us a good understanding of the general logic and hierarchy. Screens represented on the same vertical level, one above each other, are views of the same page - in this case page tabs. Everything that follows to the right are new pages, triggered by a user`s action, like clicking a button. In the example above, we have three page views (positions list view, add a position view, add a client view) and two actions represented as arrows (add a position and add a client). You can identify all this at a glance, without much effort.
Let's look at another example. Here, you have a list of pending, active and inactive clients and you can manage them and their survey answers. How many actions are there? Remember, actions are represented as arrows.
Notice how the first two actions only relate to one page. This is because the actions of “Approving” and “Rejecting” a client can only be performed on Pending clients (the first screen on the left). The actions of “viewing survey answers'' and “adding a new client” can be performed from any of the three pages on the left. These are tabs on the same page and therefore represented on the same vertical level: Pending Clients, Active Clients and Inactive Clients.
As features and flows get added, we segment them visually to keep everything organized. Below is an example of a broader view of the admin role. Each section represents a flow. The first two sections are the ones we talked about earlier, while the third section is the candidate database. We`ve named each section accordingly: Positions, Clients and Candidates.
Unlike diagrams, this approach allows you to easily switch between a macro and micro way of thinking. As you get a general idea of the flows, you can also zoom in on each individual page to review the design, layout and components of the page. You can leave individual comments for each screen or you can add supporting titles, text and images to the flows.
One thing we like to do, for example, is to add an actual image of the button the user clicks within the flow. This is particularly useful when you have multiple actions within the same page, so you can quickly identify them. This is also useful if you plan to turn the flows into a no-code clickable prototype, as we`ll see in the next section.
Replacing diagrams with flows is also a great way to keep feature creep in check. If you`re having difficulties visually organizing your screens into flows and you find that everything is turning into a mess, you might have overcomplicated your app. You can use the flows to retrace your steps and see where the flows break. You can then think of a better way to organize things or you can even take out some unnecessary features or relegate them to future iterations.
Make it clickable
Most design and prototyping tools, like Sketch or Figma (what we use), allow you to turn static screens into clickable prototypes. This is done without writing any line of code and it makes the process of gathering, discussing and refining requirements a lot more intuitive. Instead of just showing stakeholders the flows, they get to experience them, similar to how an end user would.
At this point, you already have the logical sequence of the screens mapped out and you know what the clickable elements are. Turning these into clickable prototypes is just a matter of connecting the dots. As prototyping tools are getting more advanced, you have the option to:
- define the type of interaction a user can have with an element: click, hover, drag etc.
- choose the type of transition between one screen and another: instant, dissolve, push, slide etc.
- create multiple layers of interactive content overlays, like opening a menu on click in the same page
- use animated GIFs to represent motion designs and in-page animations
In an industry where features are constantly built, tested and iterated upon, clickable prototypes are a great way to capture software requirements, discuss them and receive feedback fast.
Turning everything into user stories
We'll look into how to write good user stories at length in the next article, but there are also a few things you can do in the design phase to help with this process. Two of the most important things to consider if you want to make your designs easily translatable into user stories are naming conventions and organizing your design files. We already discussed some of these when we looked at organizing screens into flows, so we`re going to jump straight into it.
An easy way to organize your design file is to think of it as a hierarchical structure. Most design tools, like Figma, allow you to create multiple pages within the same file. We like to create a separate page for each user type. For instance, the recruitment platform back office has three user types: Admin, Client and Talent, represented as three separate pages.
Within a page, you have various sections, as we've previously seen.
Each section consists in one or more flows, where each flow is a collection of screens, the screen being the smallest unit in this hierarchy. Each screen has a name, which shows up in Figma in a navigation panel, similar to the pages. When naming individual screens, we generally use the following naming convention: [user type] screen name/action (subsection).
Let's say we are looking at the following screen, where an admin can add a position by filling out info across several tabs, in this case “Basic Position Information”. We are going to name the screen: [Admin] Add Position (Basic Position Information).
Organizing your designs under a hierarchy and using naming conventions allow you, when the time comes, to easily split them into goals, steps and ultimately user stories. It also makes it easier to reference the designs in the user stories, since you can link directly to a certain section, flow or a particular screen.
If you want to read more about how to write good user stories from a design-first perspective, be sure to check out the next article in this series.
