2

UX deliverables are dead*, long live collaboration

 2 years ago
source link: http://www.uxforthemasses.com/ux-deliverables-are-dead/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
27 September 2021

UX deliverables are dead*, long live collaboration

Agile UX, UX design, UX documents

2 minutes read

A little over 10 years ago I wrote what is still one of my most widely read, and judging by the comments, one of my most divisive articles: Wireframes are dead, long live rapid prototyping.

Sometimes you look back at things you’ve done in the past and wonder, what the hell was I thinking? I could certainly fill a large number of scrap books with my own sorry examples. However, on re-reading the article I’ve come to realise that it wasn’t wireframes I was rallying against, but a particular use of Wireframes. Wireframes were and continue to be a great way to capture the spark of a design idea, especially when used as part of a storyboard or user journey. What I was really rallying against was the use of wireframes as UX deliverables to document designs. You see 10 years ago the typical UX design process used to look like this:

Sketches > Wireframes > Mock-ups > Prototype > CodeThe UX design process of old

A UX designer would create some sketches (also known as scamps) for the basic page flow. He or she would then create Wireframes detailing the content, UI elements and interactions for each page, sometimes in excruciating detail. The wireframes would be handed over to a graphic designer who would then create mock-ups from them, showing how each page should look, pixel by pixel. The mock-ups would then be handed over to a front-end developer to be made into working front-end code, such as HTML and CSS. Finally, the prototype would be handed over to a developer to be made into production ready code.

As you can see, there tended to be an awful lot of hand offs and therefore an awful lot of UX deliverables to document a design and to ensure that an idea made it all the way from sketch to production code.

The world has changed a lot in the last 10 years, including of course the world of UX. With design systems in place many teams have now ditched wireframes as a UX deliverable, going directly from sketches to mock-ups and prototypes using tools such Sketch and Figma.

However, whilst many teams have reduced the number of UX deliverables they create, they haven’t ditched them entirely. This is a shame because every minute a designer spends documenting a design is a minute they don’t spend working on a design.

In my experience creating UX deliverables to document a design can not only be a waste of time, it can also be detrimental to the design process. Teams that create lots of UX deliverables tend to take the ‘lob it over the fence’ approach to collaboration. Package up a design in a nice little box and then lob it over to the poor developers to figure out.

Ditching UX deliverables

Weaning a team off their UX deliverables comfort blanket can take time, but is certainly time well spent. Ultimately it comes down to two things:

  1. Collaborate more
  2. Hand-over less

Cross-functional teams that work together, that see design as something that the whole team does, rather than just the designer (although be wary of the ‘We are all designers’ fallacy, as outlined by my article Sorry, but we are not all designers) tend to have fewer UX deliverables. Why? Because they don’t need them. Designs are communicated through chats, through discussions, pairing sessions and workshops rather than through deliverables.

During the design process teams should aim for a minimum viable design, the form of a design which allows a team to learn and move forward with the least effort. A minimum viable design might be some sketches, it might be some low fidelity mock-ups or even a prototype for testing with users. The key is to capture just enough of a design to be able to learn and to move forward.

Minimum-viable design > CodeTeams should aim for a minimum-viable design, the form of a design which allows a team to learn and move forward with the least effort

The most important thing is that a team acknowledges that a UX deliverable is not the goal, it’s merely a steppingstone towards the desired goal of driving positive outcomes through a digital product or service.

By collaborating, by designing as a team and by ask themselves, ‘What is the minimum form of a design required to learn and move forward?’ teams can ditch (or at least minimise) UX deliverables and get to their desired goal sooner, and perhaps even a little happier.

* I realise that sometimes UX deliverables are required, such as for agencies and internal stakeholders. However, even these should be minimum-viable designs where possible.

See also

Image credits


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK