As Designers, We’re Responsible for Telling the Right Stories.

Here’s how to get it right. Lessons learned from XOXO.

A while back, I went to XOXO — an experimental festival that celebrates both art and technology. It’s taken me a good few weeks to distill the talks from the conference into some sort of actionable insight. But I think that this is a good thing — the talks weren’t of the direct and practical kind. They forced attendees to think, to understand the story that the presenter was telling and then apply it to their own life and practice. It’s not easy, but incredibly useful, as long as we take the time to stop and think. In today’s fast-paced tech world, it’s important to slow down and reflect on what we’ve made, why, and how we can improve it in the future. This is especially true if ‘user advocate’ is somewhere in our job description.

The talks varied widely in scope and discipline, but one that resonated immediately for me in my day-to-day work was that of Kathy Sierra, programmer and game developer. I experienced several ‘eureka’ moments during the talk, and it encouraged me to think about interdisciplinary design, communication, and dealing with clients — not just users. Agency work is often a tricky balance, designing for a user who might be vastly different from a stakeholder sitting in the boardroom. As Sierra says:

“You’re creating a context in which something is going to happen for someone, they will be transformed in some way.”

Sierra is a writer (among many other things), so while her talk was framed by the practice of writing a book, it wasn’t confined to it. Initially, she spoke about readers before transitioning to ‘users,’ in the software sense, highlighting that there are few differences between writing a great book and creating a piece of software that’s a joy to use. I’m going to try to continue that theme here, in attempting to use stories to bring together client, designer, and user.

In whatever web-based thing we happen to be building, never is there a moment in isolation. There is always a journey to be considered, a goal to be achieved, and a logical way to achieve that goal.

For example, when reading, we do not open up a book and start reading from a random page in the middle. If we do, we don’t understand what’s going on, and shouldn’t expect to. A web-based interface is the same. How we get from point A to point B might be unconventional, but we get there — and hopefully, we’re all the better for doing so. There is always a journey involved, told by words or affordances or a combination of both. Along the way, our content and our design create the context that the user finds themselves in. It is the responsibility of the designer to — at every step of the way — provide this context to the user: how they got there, where they’re going, and why.

But this has been talked about before. The importance of context and place in user experience. Sierra’s talk also got me thinking about the intricacies of agency work; we design for the user, yes, but also for a client. The needs and desires of the client vs. that of the user can sometimes oppose, and we’re left balancing them. We advocate for the user, but also need to balance the needs and constraints of the business and its stakeholders. Presentation and storytelling are key to making sure that new, innovative ideas make their way into these products, and this is how it broke down for me:


When we present our ideas to a client, we’re showing them how we’re going to solve their users’ goals, but if the client’s goals aren’t aligned with that user, they’re just looking at a picture on a screen. This is a mistake. Presenting is an essential skill for designers and developers. We may have great ideas, but if we can’t articulate them, communicate their value and gain meaningful feedback, they’ll never see the light of day. And skillful presenting doesn’t just mean charisma or a flashy slide deck, either — that’s where a good story comes in.


Quite often, during the client process, we create deliverables in the form of design screens and key archetypes. These can take the form of high-fidelity comps, or medium-fidelity wireframes, but one thing is key — they are often flat. They come to the client without the story to frame them, and fail to communicate the user goal that’s satisfied, or it can get lost in an e-mail or phone call somewhere, or miscommunicated somewhere along the line.

When the individual client looks at the output and doesn’t see a story, they form their own, and this may not be the story we intend for them to read. The stakeholder goal may be different to the user goal, and therefore they build a different story to frame what they see. However, we’re far more likely to ensure buy-in to our great idea if we can sell them not just on the aesthetics but on the story around those aesthetics — the story that we want to tell, the story that centres and creates empathy around the user goal. After all, what’s a bunch of pretty words without a compelling story to connect them?


When we create these deliverables and design screens, single images and snapshots of a product, we forget that we as designers already have context — we’ve built it in our heads around that image. As I mentioned above, a story builds around that screen: how the user got there, what they’re hoping to do, and where they’re going. But the client has not. So give them context. Don’t send a slide deck or present a single screen, but give them a story to explore on their own, with a bit of hand-holding where necessary. If confusion results, then ask — what kind of confusion is it?

“Don’t require memory from people. When they’re learning Java or code or whatever, they don’t stop because they struggle. They stop because they don’t know they’re supposed to struggle.” — Kathy Sierra

Struggle is okay. Sometimes stakeholders and clients don’t understand that they (or the user) should struggle at certain points in an interface and that it’s ok to do so. It’s part of learning, and (in theory) makes that learning worthwhile, as long as they know that at the end of that struggle will be a payoff that justifies it. Communicating that struggle or confusion is okay, but ensuring that the software is always there to catch them (or the designer has incorporated the struggle as part of a means to an end), is imperative.

To continue with the literary example, when we’re in the middle of a book, we may sometimes find ourselves confused or unsure about what will happen next, but we have faith in the author that they will eventually get us to the end and tie up all those loose threads, if we give them our attention. Users and clients are taking a leap of faith with us, and it’s our job to justify any confusion along the way with the promise that our interface will take care of them. If a client is confused during a presentation of screens because they don’t understand the story, they won’t buy into the great idea, no matter how beautiful the new typeface is. Whatever we send has to stand alone as its own story, with clarity and purpose.


A potential way to tell a story is to build a prototype that the client can play with, and explore as they would a book. This way, we can actively engage them in them the story, to simulate the story of the user and offer that valuable context. We also don’t need to explain or justify our choices each time. This way they can see exactly how the user’s problem is solved, and (if they’re a user of the product themselves) buy into it.

Oftentimes, we at Myplanet push for an interactive prototype of what we propose to build. We do that prototyping using Invision, HTML/CSS/Javascript, or even paper — choosing a particular tool depends entirely upon how much context it provides, what kind of story we want to tell, and what kind of feedback we want to come away with.

This isn’t meant to be a treatise for prototyping, but a reminder that as designers we have a responsibility to both client and user to remember their context. We also have to remember to place ourselves in that context, and a great way to do that is with prototyping. Of course, prototyping is just one method; I would be very interested to hear other ways in which people build these stories, to bridge gaps between client, user, and designer.

We’re responsible for telling the right stories:

I’ll end the article with another quote from Sierra’s talk, a reminder that we all need from time to time, to keep our focus firmly where it should be:

“Don’t make a better ______. Make a better user of _____.”

We shouldn’t focus on making applications great — if they make better users, that greatness will take care of itself. We just need to tell the right stories around them. However we choose to do that, be it with a prototype or something else entirely, makes them empathize with the user that much better, and helps them connect stakeholder goals to user goals. It may not ensure that all of our avant-garde ideas make it into products, but it gets us one step closer.

Written by

Ivana McConnell

Ivana McConnell

Sign up for our newsletter