Design Deliverables: How To Choose The Right Ones For Your Process
UX/UI design is not defined only by the end product, actually, the process is just as important as the result. This process must be transparent and useful, and generate clear and tangible design deliverables. There are many product design processes and methodologies, and each team is different. Regardless of which method is chosen, the design process must be flexible and produce results that help the team create a product that is user-centric and meaningful to them.
In this article we will review the main ux design deliverables and their proper use in a team building process. This processes could be separated in three main areas:
Design deliverables
It is important to generate low fidelity deliverables during the early stages of design, as spending too much time on visual quality is pointless. These deliverables need to be agile, to maintain the ability to quickly iterate and make changes, after all, the final solution for the problem we’re working on is still being refined. Many of the foundations of the design should be easy to interchange and modify, avoiding wasting time on unnecessary details. Simplicity will also help to communicate the idea to the whole team.
Wireframe design has the characteristics of a creation deliverable, being low fidelity and designed to test ideas at an early stage.
Communication deliverables
Communication is a key factor for an agile team, and as UX / UI designers there is a responsibility to provide documents that constantly align the team, reminding them of the solution that is being proposed. These deliverables outline our design decisions and the reasons we made them. It will also be necessary to be able to take feedback from these deliverables in order to improve our product. Deliverables must be clear and speak the language of the team and stakeholders.
In the image we see the system for creating a prototype in Figma, which is a deliverable that communicates the solution, not only to the users within a user test, but to the entire team involved.
Validation deliverables
Validation deliverables serve to expose the research methods that have been used throughout the process. Much of this information can be qualitative or quantitative, but it is mainly focused on a real and detailed support of the solution and the problem. This category should be presented very clearly and only highlighting the important points that validate our solution. In some cases, the excess of information could discourage people from reading these deliverables and leaving them aside.
The results that measure the experience of our design could be a good example of a validation deliverable. Good practices in data visualization will be relevant for these types of deliverables.
Deliverables By Process
In late 1999, designer Jesse James Garrett began researching terms and processes in his work in order to better explain his role to his teammates. Garrett realized that when he talked to people in different roles, the definitions of his work changed:
“While doing my research, I was continually frustrated by the seemingly arbitrary and random use of different terms for basic concepts in the field. What someone called information design seemed to be the same as what someone else called information architecture. A third party combined everything under the interface design. (…) I struggled to come up with a coherent set of definitions for these terms and to find a way to express the relationships between them." –Jesse James Garret, "The Elements of User Experience".
A few months later, Garrett posted on his website a diagram with a three-dimensional matrix that shaped his ideas, and called it "The Elements of User Experience":
The objective of this model is to define a development process where we are aware of all aspects of the user experience. This means that in each stage of the process we will understand the user's expectations and what we are offering as a product. All under a transparent and well-defined method for the team. At the same time, this will help to recognize which deliverable will be the most appropriate at each stage.
We can disaggregate the deliverables under this process as follows:
Strategy: Results and insights of user research such as interviews, surveys, A/B tests, heatmap and analytics reports, etc., and documentation of the ethnographic and documentary research of the product and its possible users. Product pitch, definition of design challenge, purchase order document (ODC), project proposal document or business model canvas, among others.
Heat maps can be very useful deliverables for defining or modifying our product strategy and design.
Scope: Functional and non-functional requirements, backlog, project budget, project plan, milestones, delivery dates, user and people stories.
User stories are very useful to focus the team on the solution that is being built, as well as to detect possible pain points that we have not identified.
Structure: Information architecture models, taxonomy and content strategy, navigation models, cardsorting results, user journeys, user flows and editorial guides for content writing.
The information architecture maps define the structure of our interface, giving clarity not only to us as designers, but to the entire development team and stakeholders.
Skeleton: Sketches, wireframes and low definition prototypes, interactive product model, information maps, flow charts, texts and final microcopy, technical validations and final requirements for backend.
The flow chart is the graphical representation of an algorithm or process. This deliverable (skeleton) is usually the responsibility of the development team.
Surface: High definition visual, interactive and prototyping design, animation and micro interaction design, early stage code (alpha and beta), design criteria, manual and visual style guides, style sheets, design systems.
Deliverables such as Design Systems are a good example of a surface deliverable, as they are the final layer of the design that the end user interacts with.
Conclusions
There is no isolation in the interface design. As we see it on a daily basis, our discipline interacts with other areas and we must communicate with them in the best possible way. We also know that there is no standard design process and it is highly dependent on project and team circumstances. Most of the deliverables shown here are the result of much trial and error. In fact, more mistakes than hits. Do not forget that as much as you are clear about what you do and why, UX/UI design is still a teamwork discipline and requires constant communication.
Thanks for reading!
Sympli is a Saas company that creates tools for design collaboration, handoff, and version control. With more than 5 years on the market, we had helped thousands of designers and developers work together by providing a single source of truth and reducing back-and-forth communications, resulting in faster delivery.
