Generally speaking, because of time-constraints, lo-fi and hi-fi comps are the most recurring deliverables during the product design process but no -or very few- interactions are detailed or designed.

Then, the rest of the story could go like this: Prototypes are quickly built (using the highly desirable and sexy Hi-Fi comps) because Stakeholders want to see «the final result» and «cannot project themselves without the sketch file».

But eventually, the team members take a step back and imagine another solution, so the designer goes back into sketch, spends two hours modifying the latest version… and so on and so forth.

For sure. This solution has the advantage to give a final overview of the look and feel of the user interface. But it is far from ideal if the team wants to streamline the work and gain in speed and efficiency.

Moreover, designers generally hate updating the Hi-Fi screens with heavy structural changes as every modification needs to be carefully crafted, every screen needs to show the final consistency (font, colour, balance, spacing, contrast, structure, hierarchy, etc) before being re-uploaded into InVision and be ready for approval.

Let’s face it. This process is time-consuming and quite exhausting for everyone, and yes. Specifically… for product designers.

The workflow I’m about to describe ticks many boxes:

✅ Engaging the whole team in the design process;

✅ Keeping track of the interactions between screens;

✅ Ensuring better communication within the team and specifically towards software engineering;

✅ Layering different renderings of the user experience;

✅ Giving the opportunity to observe the design solution under many angles/approaches and securing the best experience possible;

✅ Crafting an improved and well thought-through experience before final delivery.

Here are the 6 steps (and types of deliverables) that are recommended before considering that the team has reached a satisfying product design solution.

In principle: This first step allows the team to design a solution as a whole entity and reduce the amount of back and forth between product ownership, users and designers.

Following an agenda and precise timing (20 minutes for sketching, 2 minutes for presenting, etc), the group is spread across multiple micro-teams (2 people minimum) and tries to have a multi-disciplinary approach to problem solving by sketching solutions using pens and paper.

The output: Several screens can be produced if necessary. The participants have to really focus on the interactions and the flow. The look and feel is secondary and needs to be roughly sketched, nothing more.

Following this framework, the team members and the users are the designers, the UX practitioners are to be considered as facilitators. It’s sometimes challenging for designers that are new to UX practises because they no longer are at the origin of the design decisions. But hey, fellow designers get yourself a cup of coffee and let these people work for you, they’re smarter than you think.

Put it more simply: Some people in the team have brand new designing powers, others (managers, designers) just need to let go and become facilitators. But in the end, everybody wins.

In principle: This flow represents a high level view of the actions that your user is going to take in order to achieve a very specific task. The user flow replaces and/or complement any written documentation by showing a very simple and logical path. This visual representation is really useful as it allows the team to take a step back and turn some specs (or a user story) into a very simple and yet exhaustive representation.

The output: This step can come before, during or after the co-design session to clarify a scenario or a use case. Just make sure this deliverable is built with the participation of the team. I personally always start with a white board session in presence of fellow designers and/or product owners, software engineers… then I switch to a clean digital version using Axure RP.

Put it more simply: The user flow gives an overview of how the story is going to be told on screen. I strongly recommend UXers to not skip this step. ??‍♂️

In principle: This relatively recent technique allows the UXers to communicate more thoroughly with the software engineering team. It’s particularly suitable for complex digital products embedding lots of interactions. I personally love this deliverable more than any other one because it encompasses many tools and deliverables in one without sucking too much of the designer’s precious time.

The output: the user flow generally works with a simplified version of the wireframes and gives a visual representation of all the interactions between the screens and the various components within the page. No need to detail the whole content here, but some notes can help the team to understand this deliverable better. The content really needs to be roughly represented on screen. Nothing too fancy, let’s keep this quick and elegant.

Put it more simply: wireflows give a more precise idea on the decor of the story – the presence and positioning of the components in the interface and the output given when these components are triggered. More details here.

In principle: Once the wireflow has been defined and has allowed the team to get a clearer vision, we need to put the actual content in wireframes to start building a lo-fi prototype.

The benefits of building a lo-fi prototype are numerous. In a nutshell, the lo-fi prototype emulates the reality of what the user will experiment with the hi-fi prototype. The huge benefit being that it’s much faster to produce and can allow the team to have a demo-able product in a few hours.

The output: The html files generated in Axure, for instance, can be shared in a matter of seconds and allow the team to play with an interface while consuming the whole content.

This step is crucial especially if the team needs to be immersed in an emulated environment before pivoting or taking decisions that could have a strong impact on the overall design. If this step is neglected and the team chooses to jump straight into hi-fi prototyping, it would actually be too overwhelming and require too much time to redesign the final comps each and every time.

Put it more simply: The equivalent of a rough/animated storyboard for a film or anime. Huge time saver. Great tool to effortlessly get an overview of the final feature. Helps to streamline the efforts and structure the design process before jumping into final rendering/ fancy eye candy stuff.

In principle: This step is necessary to give the final look of the digital product. Its goal is to craft the user interface that will solve the user problem and generate a desired output. It’s generally built using specific grids and a design system.

The output: The final comps are to be produced in a specific software like Sketch, Figma or Adobe Xd, then uploaded to InVision for usability testing and Zeplin for sharing the resource with the developers/ software engineering teams.

Put it more simply: everybody liked the studies and the rough sketches, now we’re going to paint a beautiful (and very usable) picture.

In Principle: The final step before iteration is the evaluation of the new feature that was built during the sprint.

The output: Many techniques do exist and the team should not limit their choices: Usability tests, heuristic evaluation, usability scales, cognitive walkthrough, etc. There’s literally hundreds of user experience research methods and the job of the product designer is to pick the one that’s more adapted to the context.

Put it more simply: This step is crucial, especially if KPIs have been set. The team should always rely on the evaluation to iterate and verify their initial assumption when they took a design decision. Even if users were present during the co-design session.

We’ve seen that the team should first draft the broad lines of a feature with pen and paper, crafting the experience together. The designer’s job is to take the next steps and create the various views that will progressively zoom in on the final result.

Imagine being on Google Earth and zooming progressively on a continent, a country, a city, a block of houses, to reveal an environment that we’d like to visit virtually (yeah we’ve all done that circa 2006)…

Let’s consider here that the higher view is the User flow. If we zoom in, we reveal the wireflow and a bit more details on the interface and the interactions, If we still zoom in, the wireframe appears and it’s embedded in a prototype. Let’s zoom one last time and we see colour, contrast, hierarchy and accessibility features appearing. Our final product is revealed step by step progressively instead of tele-transporting us directly into this new environment.

What’s the advantage to this? Well. It breaks down the design process into many quick steps that will allow the team to take a step back on the design solution for each and every output created.

Flows, wireframes, lo-fi prototypes must be scrutinized by the team in a limited time frame to allow the product design team to bring the necessary modifications before jumping into the fancy hi-fi comps.

It is the designer’s responsibility to provide the team with the needed deliverable(s). It is the designer’s choice to structure his•her approach to product design.

There’s also a time constraint consideration here, and this is not always challengeable. Yet this type of decision is crucial and it will greatly impact the quality of the final product.

This succession of steps is a set of recommendations and best practises. It is non exhaustive. Countless deliverables can become handy when designing a product: Personas, empathy map, user journey, scenarios, storyboarding… specifically during the user research/discovery phase. The team needs to be aware that generally speaking, directly jumping into a co-design session without these could also be risky. Good design takes time. The designer should take the time to have these deliverables ready. Producing too much material will never be a bad option. Producing too few can on the other hand, become dangerous.

If the team is comfortable jumping straight into hi-fi, it could be fine, and it could work… but problems could also occur after a couple of sprints.

Because in the end, having the designer left alone to deal with heavy iterations for long periods of time is toxic not only for her•him, but for the entire team.

Ideally, the team needs to come up with its own design strategy to optimize this whole process. A strategy that is robust, durable, adapted to the team’s needs and most importantly beneficial for the end user.