Experience design deliverables

Understanding the products experience designers produce

UX deliverables have been a source of confusion since the term “UX” was coined in 2004. In fact, the term UX (or user experience) has recently fallen out of favour in the design industry. Most UX professionals refer to themselves as design strategists, product designers, or experience designers. The field of experience design has gone through several major evolutions over the past 30 years. It started with information architects separating themselves from designers; believing they were scientists and were only tangentially related to the design field. Later, the definition of ‘design’ was expanded; thanks in part to the rise of ‘design thinking’. Thus, information architects became designers. As the field moved away from communication-design to product design, software development processes were introduced that changed how information architecture was performed. Specifically, Agile methodologies were introduced and resulted in little-or-no experience design documentation. This led to blurred-lines regarding who was responsible for experience design. Ultimately, there has been some snap-back regarding true Agile methodologies; instead, favouring a hybrid method that involves experience designers creating deliverables/documentation again.

Importance of experience design documentation

With the rise of Agile software development methodologies, we saw some software development shops completely scrap project documentation; thinking Agile means no planning and no documentation. Agile isn’t as strict as some people think. Remember it’s a methodology that needs to work for different teams, at different experience levels, with various organizational structures and maturity levels. Depending on the nature of the project, an Agile methodology can include documentation; it’ll just be more focused and will help the team successfully complete sprints. That said, many software development shops struggled to complete projects without documentation. They found two big issues with building digital products without documentation:

1. If the core team changed, it would be difficult to onboard new people without the benefit of having documentation that explains why important decisions were made.
2. When the software was handed-off to a client-team, it was difficult for the client-team to maintain, update and optimize their digital products. Even small changes could require a complete refactor of the code-base.

Experience design documentation was particularly important for product managers wanting to optimize their digital products iteratively. We saw the degradation of apps and websites due to a lack of experience design documentation. We saw issues like:

1. New pages or categories were added without adding a link to them. So, the only way a user could access the new pages are directly; by typing in the URL.
2. New imagery or icons were added that would be inconsistent or would break size-restrictions.
3. Content would be created based on corporate requirements instead of user needs. Resulting in a much greater noise vs signal ratio.
4. Content would be added without adding certain attributes, such as author name, date, meta-text, tags, keywords, and other attributes that help the system deliver relevant content to users.
5. Optimizations would be made that are counterintuitive or degrade the usability. Often, business owners put their own opinions in place of their users; resulting in components few (if any) users want.
6. Major campaigns, new features, or programs get added without fully understanding the user experience principles used throughout the app or website. This often results in inconsistencies, complicated user flows, hard to find content, and hard to comprehend content.

Most reputable software development shops, today, include some form of experience design documentation that provides guidelines for managing digital products. Even if product managers use their own “internal software development” team, having well document experience design guidelines will ensure the digital products can be optimized and can evolve without compromising a good user experience. (I should mention, some software development shops intentionally don’t provide experience design guidelines in a poor attempt to keep control of a digital product. “If our client realizes they don’t have the knowledge and skills required to optimize their website, they’ll continue to rely on us.”)

Matching your needs with experience design documents

Hostile Sheep only does two things: (1) user research and, (2) experience design. So, we always provide our clients with experience design documentation. We primarily work directly with enterprise clients who understand the importance of experience design. Our enterprise clients either have an internal software development team or don’t trust their external software development shop to handle the experience design of their products. Regardless, we provide our clients with world-class experience design documentation they can use to manage and iteratively improve their digital products.

Many of our clients don’t know what types of documentation to ask for. Instead they tend to explain what documentation they already have, what they’re used to, and how they plan on managing the product. In some cases, our clients will specifically ask for something like “a low fidelity prototype” or “a set of wireframes”, but that is usually a signal that they’re unsure of the experience design process or what various types of documents are used for. Thus, we created a categorized matrix of experience design documentation based on level of abstraction. In our matrix, our clients can ask for documentation to help define six different aspects of a products experience design:

1. User definition: documents that help define who the user is, what motivates them, and what outcomes they expect from using digital products. Including: (a) personas, (b) mental models, (c) use cases, (d) user stories.
2. Content definition: documents that help define what content should be created, how it should be created, and the nomenclature to be used. Including: (a) content models, (b) content strategy, (c) content governance, (d) copy deck.
3. Behaviour definition: documents that help define the user journey; how they move between pages and how they access features. Including: (a) journey map, (b) task flows, (c) wireflows, (d) user flows.
4. Categorization definition: documents that help define how content is categorized throughout the digital product. This is usually a hierarchical categorization or a linear (journey-based) categorization. Including: (a) concept map, (b) mind map, (c) site map, (d) taxonomy.
5. Interface definition: documents that help define the placement of interface elements. These documents often define interaction design and information design. Important interface elements such as forms, errors, navigation, buttons, promotional touts, etc. are all defined in these documents. Including: (a) conceptual prototype, (b) low fidelity prototype, (c) high fidelity prototype, (d) specifications.
6. Guideline definition: documents that help guide ongoing maintenance, optimization and the iterative evolution of the digital products. Including: (a) design language, (b) pattern library, (c) interface inventory, (d) design system.

Conclusion

Everyone knows about digital product documentation; it usually focuses on explaining how the final coded-solution functions; technical documentation. In many cases, design documentation is considered ‘work product’ and not valued as highly. In recent years, this paradigm has begun to shift. Many product managers want to know WHY important design decisions were made. They want help to ensure they aren’t doing anything that breaks the user experience. Thus, experience design documentation has never been more highly desired and valued.

At Hostile Sheep, we try to provide our clients with editable versions of our documentation whenever possible. Although interactive prototypes aren’t easy to edit, we have provided editable Axure files to our clients. If we know our clients plan to edit our low-fidelity prototypes, we may choose to create static wireframes instead of an interactive prototype. In fact, most of our documentation can be produced in a format (or using a program) our clients are familiar with. (i.e. if our clients use Visio or Omigraffle we can deliver those formats. If our clients want a Word document or an Excel sheet, we can deliver in those formats. If our clients are more familiar with Figma or Sketch we’re happy to use those programs.)

What do you think about experience design documentation? What kinds of deliverables do you find the most valuable? What deliverables do you ask for? Are there deliverables you’re not familiar with? Should I share examples?

Experience design deliverables was originally published in Answers and Outcomes on Medium, where people are continuing the conversation by highlighting and responding to this story.