Designing better UX deliverables - Anna Dahlström30 May 2014 in UX, IA, camusability
This talk happened a few weeks ago now, but the topic is timeless, so there is no harm in getting my notes up a bit late. Anna Dahlstrom(@annadahlstrom) came up to Cambridge to give a talk on how to design better UX deliverables, but more broadly the talk had many lessons about how to present results to different stakeholders, not just for UX.
A litte bit about Anna
Anna had gone from only working with HMRC to working agency side - multiple clients, multiple project, different industries. Needed to go from fairly straightforward work, so a lot more creative work, needed to be more strategic, needed to sell her work - both internally and externally. (One of my favourite moments in the talk came up when someone asked her how had she managed to move from HMRC to this agency, when the type and pace of work seemed so different. Anna’s answer was that she just applied for the job. I think there can often be a feeling that we get defined by our roles, rather than by our inherent capacity or potential, and too often there can be a feeling of not having permission to go out and try something because of these boundaries that exist, but my own experience has taught me that its often worth just rolling the dice, if you roll enough times your numbers come up).
The agency where she moved to was creative and open, with less set templates. The people in the UX team felt more like designers, than IA’s. The team was really talented, and it initially left her feeling that she needed to up her game in some areas.
She needed to advance her wireframing skills - experimenting with different tools, different ways of calling out components of the wireframe. The strategic documentation came a bit harder. Had to find her own style.
One thing that really helped is they had weekly one on ones. They would talk through work in these one on ones and the mentor would show their work at the same time. Critiquing in a constructive way really helped Anna find her style. (Is sounded like that atmosphere of positive criticism was a large component is allowing Anna to rapidly improve her skills, and I think it’s a great takeaway for anyone who is in a mentoring role, or is being mentored).
Being a champion for UX and IA was a part of her role in the team. Collaborative working is not a given everywhere, and you still need to identify how to work with people.
We always need to sell our work, one way or another.
The value and role of UX
UX adds value. When it comes to convincing others of that, it’s not always easy. You need to understand where your peers are coming from, and you need to explain things to them in a way that they can understand.
She asked a few people in different disciples. what makes for good UX deliverables.
- needs to meet the audience it’s intended for
- clearly communicates its purpose, what it is trying to achieve
- its not created for the sake of it, it has to add value
- should be prototyping on wireframes (less large documentation) – spend time adding value rather than documenting process
What’s needed depends on where you work. In-house developers needs are different from where the development is out-sourced
- UX is about delivery, not deliverables. Best ones are the ones that take the least amount of time to produce, that move the project forward the most.
- Make them fucking appropriate. The truth is you need to communicate to lots of people at lots of different levels
Not every client is the same.
- … consider the whole customer journey, and looks at the business requirement in the context of the journey
- demonstrate enough for the stakeholders to understand the essential details, for developers to be able to build with minimum questions
- has a narrative and clearly tells a story
We wouldn’t have anything without content - has a close understanding of our content.
The examples are great, but I’m not going to summarise them here, however, there is great use of and attention given to layout of information, and judicious use of visual elements. Some tools that she touches on are:
- customer experience maps
- colour and iconography
- Userflows and journeys
Overall, what is going on here is that colour is being used as an almost abstract form of metadata, it’s being used as an informational extra dimension in the artefacts, and it’s not being used for it’s own sake. It’s used judiciously, so as not to overwhelm itself. (In seeing these examples, thinking back to them I’m struck again at the genius of the tube map).
- create something people want to read
- remove the fluff
- pull out the key points
- add some of the delight
- don’t waste people’s time
- ensure the reader knows that they are looking at
- include page titles, page numbers
- use visual cues
- pull out or highlight what has changed from the last time
- make it easy to follow
- a read thread is crucial & makes your work engaging
- the narrative that runs through your work
- a read thread is crucial & makes your work engaging
- mostly it won’t be you presenting your own work
Narrative is the key thing. It’s only when people tell stories that people feel engaged.
- Make things reusable between projects
- keep assets organised
- spend some time setting up elements properly
- use layers and shared canvases
- keep your documents organised
adapt to the reader
- use a mixture or colours white space and fonts
- Don’t be lazy
- check spelling
- ensure alignment
- include spacing
- alway proof
- don’t be unrealistic with wireframes
- don’t spend unneccesary time polishing
- work with simple tools
15 min exercise
We are given an exercise to design the layouts for a mobile app, and to spend the time thinking about putting into practice some of the tips presented in the talk. What is astonishing about this is that in 15 minutes, when you put things on paper, you can actually get really quite far, when you set aside the and let go of the inner censor, and just allow yourself to get the work out onto paper. I felt that the act of making visual the idea raises questions inherent to the idea, and makes you address problems as the exist, rather than as you think they may exist.