Welcome to the last of three articles dedicated to experience design deliverables. In first one we covered project discovery and research. The second article focused on designing actual experience deliverables essential for successful project delivery. The goal of this article is consider how to wrap everything into a nice package for handing over to the client.
As mentioned at the beginning “design is collaborative process” in which delivery does not stand alone. Before we deliver, we have to make sure we test our product. No matter if you delivering all in one piece, or in small separate deliveries, you need to test.
Depending on the project and the client, delivering in sprints makes your work slightly easier because you are building on previous foundations so delivery is more focused. Review as you go. Delivering in small pieces of work is also easier, more focused and less tiring for the client. On each sprint, explain the big picture (which refreshes memories about previous deliveries) and then focus on the actual delivery.
No one could possibly survive a 100 page TECH / XD specification presented in a one hour meeting. Always keep three things in your mind – 1/ what we delivered last time (how we could possibly improve it based on previous feedback), 2/ what we will present today (a challenge + solution), and 3/ why we did it (the rationale for a given piece and how the solution fits into the project, brand, strategy, etc.).
Imagine a site which you build from empty pages as containers. Each time you see the client you present only one page at a time. This gives you the ability to deal with all questions related to a given page and then focus on how this page will be integrated with rest of the site. All parties understand their tasks, risks and challenges. Both designers and the client focus on one single page, behaviour or solution.
Deck vs. Prototype
How many times have you spent weeks crafting a deck presentation to communicate an idea instead of building the real thing, movement, transition or interaction? We widely represent ourselves as “interaction” designers but find that we spend 70% of our day crafting static documents and wireframes (with very expensive tools such as Axure) instead of working on transitions and interactions on their own.
… think about the client
You could try to explain to the client how this amazing website works in a 20 to 50 page deck. Or you could just show them the real thing on a mobile, tablet or laptop. I guarantee you will see the difference. Things they can touch, swipe or click on become real. Something happens – a real connection, a real engagement. And most importantly, you will get real feedback.
Don’t talk about it – make it, show it …
Communication has two parts: you can either explain how it works or discuss why it works in the way you are proposing and what the rationale is behind it. Talking about the real thing is always easier than saying “imagine this… it will work this way”. Fundamentally, it will change the perception of the listener and also build trust between your team and the client.
Over the years I have learned that most decks, even those you keep for reference, are still on the server and you might have a hard time locating them. One week of work will shrink into a one hour presentation where everyone is “imagining” how this “thing” will work. Does anyone think “yes – that’s what we want” – really!?
The era of using decks to present ideas is gone. For once in the morning, instead of reading the news, try codeacademy.com and you will see what you can do.
Building a prototype is not hard. But we are still hearing that decks are faster. In some cases, perhaps. Especially if you present a strategy piece or planning with a lot of graphs then you definitely need to build a story and not a prototype.
Building a prototype will not stop you from producing a deck if you really need it. It helps you to consolidate the solution. Also, the review with the client will not be “imaginary” anymore; it will be “tangible”. Team “A” will continue prototyping while team “B” starts exploring other variations for navigation or perhaps designing another solution.
Following iteration and checking with the client, you will have already solved part of the challenge. Also, mentally, the wireframes, visuals and presentations are intended to be changed. They are not the final thing. Clients think and know they can still change things. However when it comes to the code, there is a time for you to say this is it – “final call”.
It is your business decision to deliver 10 decks over the month to get approval on project X. Or you follow the prototype route and try to build something small – a page, a campaign, or a digital brochure. Once you start using prototypes regularly your client will not expect decks anymore. They will expect a rich touch enabled experience they can rely on.
It is a natural process in which we all need to grow – designers in building and clients in understanding the dynamic process. From the client’s perspective it is just perfect. Whether you think about accessibility for or share-ability with stakeholders the prototype communicates behaviours and interactions in real environment. Also from the feedback perspective you negotiating over the real thing not a paper or slideshow presentation. A few times I have been in the situation where everyone in the meeting room just grabbed their smartphone and followed me on shared URL there the prototype was saved – a priceless moment.
We use to hear “it’s expensive“. Yes – adoption and the learning curve is as expensive as any other program or tool you need to learn.
Another real benefit of building prototypes is time efficiency. It will not happen overnight – some of us will be still faster in Photoshop or by sketching. But when you have a page and you want to change the order or list content, it is two lines of code and “Enter” instead of drawing, scanning and validating with several emails.
What if the code is not part of the delivery? Yes – in some cases the code is not part of the delivery. In such a case build a small prototype to verify your thinking and delivering the production “reference code” is above expectations. Furthermore, you secure your position in case someone else messes it up.
What if you create a page and need an annotation for the module or part of the text? Annotator could be one of the answers but there are many other tools which help you to make comments on the page.
I know I said you can reduce the number of documents regarding the delivery. Documents help us to communicate processes, short and long term decisions, and challenges and solutions. Documentation is a necessary part of the UX process.
Define the feature list, write epics, user stories or personas. All these documents have their own place and importance. Use them wisely and try to develop a system between them which allows you and your team to communicate more efficiently. That does not mean if you have a template you need to stick to it. Improve your documentation workflow as you go.
Guidelines probably deserve a separate article, but before we get to that point, let’s mention at least what type of guidelines we have and what they are good for.
“These are the key strategic statements which provide a guideline for the strategic handling of the brand by all stakeholders. The key statements concern brand relevant content, such as brand image and future expectations but also competitive advantages and brand messages, in order to face the respective challenges.” (glossary / brand guidelines)
- Branding (Entrepreneur – unknown source).
- A practical guide to branding.
- The importance of brand standards.
- Best resource for building a brand guidelines.
- logodesignlove.com – presents a list of best style-guides.
Reference Code Guidelines
Recently, with all this prototyping, developers and designers have come up with guidelines that represent pieces of front-end code showing how elements should work / behave together in different environments. This little piece of code also holds the best practices of the recommended codebase.
It give the user, designer and developer a good start in understanding the hierarchy, dependency and most importantly, brand scalability. All these rules have one single purpose – to keep the brand consistent as it grows over time.
- Starbucks – reference code.
- Brand at University of California.
- Boilerplate – basic style guide.
- android.com – OS guidelines.
- mozilla.org – styleguide.
Delivery (Wrapping Up)
What is the conclusion, then? We need decks to communicate research, vision and strategy, and we need prototypes to prove our concepts and solutions. What we need the most is to have the client involved throughout the whole project.
This might sound a little naive, especially in big companies, but the best projects that were done under best leaders and passionate contributors where the Experience Designers play major role of influencing the orchestrating their teams.
Experience design is growing rapidly. More and more we seem to be thrown in to projects that require certain methodologies, different processes and occasionally rebuilding our own strategy, balancing between digital products and services to find unique engagement solutions.
My advice for you is never stop learning because the junior design guy right in front of you knows something you do not and it might be the thing you need the most – “just another opinion”.