4 steps to follow before wireframing to improve design quality

Wireframing is usually when I have the most fun. Churning out ideas one after the other and putting designs on paper is my kind of high. Following 4 steps (scroll down for steps) before I start wireframing has helped me consistently create high quality designs.

Note: This article is more relevant if the Product Manager does the bulk of the user research at your org and you are handed a fleshed out requirement document (PRD). Less relevant but still valuable for others, I hope.

Advantages of following the 4-step approach for wireframing:

1. Brings focus to the main friction areas for users: (warning: personal anecdote) This one time, customers were using a CallHub integration to import lists from their CRM, and only few of the lists were getting imported. The requirement for design was to take customers to their CRM settings and help them enable the permissions CallHub has access to. But by the end of the exercise, we realised that the problem was in a different area of the product and we just needed the customer to enable a checkbox. The solution was one short line of text.
2. Ideate faster: This one time, CallHub was shifting its payment model from pay as you go to a subscription based model. Too often, the conversations got sidelined to talking about adding a price calculator or other bells and whistles that would improve the UX. But, what was the problem? Prospects were having trust issues when sales team tried to nudge them to a subscription plan since CallHub had no mention of its subscription offerings on the marketing site. The goal for the 1st release was to just create transparency about the new pricing model. Not to sell a full-fledged self-serve subscription model. Having that goal clearly etched in the back of the mind helped create ideas faster.
3. Create solutions that align with outcomes that the business expects from the project: When we were migrating the CallHub website to a new server that was easier to manage and would reduce code bloat, hours were spent wireframing pretty designs before realising that the goal of the project was not to improve the visual aesthetics of the site. Going back to the core outcomes we wanted to drive from the project came from following a less refined version of the pre-wireframing process described below.
4. Approach problems with more empathy: Since PMs take care of user research at CallHub, these pre-wireframing steps are also a way for designers to put themselves into the shoes of the user and understand their pain before designing a solution.
5. Get stakeholder buy-in: By the end of the exercise, you’ll have a clear timeline in place and will be able to articulate the specifics of the project so stakeholders are not left wondering what you are up to and why its taking so long.
6. Identify and fix gaps early in the product development process: You do not want to do a design handover to the development team only for them to come back and say X screens are missing or this flow is a dead end.

These are 4 steps to follow before you start wireframing:

1. Scope the project
2. Create task flow diagrams.
3. Design research
4. Initial sketches
5. Wireframing

NOTE: Gaps in the PRD (problem areas not thought through, outcomes not clear, deadline did not account for certain complexities etc) come up every step of the way. I usually document all of them into a sheet and bring them up during the daily standup meeting.

Outside of gap areas in the PRD (Product Requirement Document), there could be important product requirements that come up during design research. These are added to a Google Sheet and marked as “TO REVIEW”. All items to be reviewed are resolved during the next sync up with the PM.

Scope the project

For big projects, a well defined design scope document comes in handy when you are answering to stakeholders and have to give estimates to the engineering team. For smaller projects, it keeps your personal planning in check and lets you plan sprints effectively.

It also helps with managing expectations during standups and sprint meetings. You do not want to appear as lazy when you’re putting in the work. I’ve written my thoughts on not appearing lazy at work.

At CallHub, the PRD covers user research, and designers focus on design research (see “explore” area in this article by NN Group). Scoping starts with a thorough review of the requirement document (PRD). Any gaps in the PRD have to the caught, reviewed, and resolved as the first step in the project. Some research happens at this stage to validate doubtful areas of the PRD and to offer insights that lead to better understanding of the problem.

During the PRD review, all the design requirements are moved into a Design Requirement Document (DRD). The DRD acts as an internal document where design decisions, insights and scope are dutifully recorded.

After that, all the tasks are broken down and recorded in an estimation template (part of the DRD) to figure out the delivery date.

Product design estimation sheet for Design research and Visual Design

Product Design estimation sheet for wireframing, meetings, testing and defining metrics

Create high-level task flow diagrams.

With all the design requirements in one place, it’s easier to visualise the journey that takes users to their goals. High-level task flows also gets everyone on the same page about how the journey will look like for a user.

Note that these are task flows and not in-depth user flows (task flow vs user flow). Wireflows are often easier to work with over user flows because their visual nature make it easier to think in systems than using just words. So unless you’re working closely with multiple designers, simple task flows will work. When you have multiple people working on a project, you might need fleshed out user flows.

Design research

Includes four parts:

• Analysing support tickets: At CallHub, the support team tags all support tickets in Zendesk and send relevant ones via a custom integration to ProductBoard. New projects would have been part of the roadmap for a while, so that would be enough time for us to have a nice categorised collection of support tickets that we can go through for user insights.
• UX Audit of the existing product: The current product is audited to find gaps in the UX that can affect areas of the flow that will be part of the new feature. Nielson’s 10 usability heuristics for usability evaluation offer a good framework to conduct the UX audit. The results of the audit are recorded and prioritised. The high priority issues are resolved as part of the current project and the rest of it is added to a design debt sheet.
• Identifying relevant design debt items: The design debt sheet is studied to identify previous recorded UX issues that are part of the user flow for the current project.
• Competitor analysis: This is mostly an effort to understand the common patterns in place to solve the problem. Relevant flows are recorded along with a brief analysis and maybe a screenshot or recording. Loom app is a big help with recordings.

Recordings of sales calls, user interviews and user sessions are also analysed based on requirement.

Initial sketches

Explore multiple ideas on paper, on an iPad, or using a wireframing tool like Excalidraw. At this point, just throw ideas on paper without getting attached to anything in particular. Only condition is that it has to do justice to the problem that has been fleshed out in the PRD. Sometimes it’ll help to draw few of the initial sketches before looking at competitors to avoid biases that inadvertently creep up.

Wireframing

Once, the flow is settled, you can start fleshing out more detailed wireframes on Excalidraw down to every tooltip and error message.

Would love to hear what your wireframing process is like (or suggestions to improve the above process.)

P.S. I’ve mentioned Excalidraw multiple times because it’s awesome and it’s open source.