When I talk to junior designers starting out in their careers, I find they struggle with “story.” They can’t walk from problem to solution and explain how they got there. They’ll get caught up in the little details but miss the big picture. They’ll focus on their individual work while not talking about the team (or vice versa).
Why is that? My theory is that it’s the UX/UI conundrum. UIs are supposed to tell our stories. But they’re also both finality and affordance. They are the final “rendering of intent,” but we’re leaving the story to be completed by the user. So we’re used to “our design,” but we’re not used to the mutual-ness of the story conversation.
And that’s the important part: the conversation, between design and user, between product owner and designer, between organization and customer. Every design is a conversation. But how do those conversations work? As a company, are you in dialogue, or are you lecturing? As a designer, are you engaging in the conversation, or are you frustrated the user can’t finish your sentences?
If design is communication, then it’s natural that the idea of story should be central to all our design work. Story is what binds the scenario to the vision. It’s what binds the design to the code. Without a story, we can overemphasize the tiny details and underemphasize the role those details have in the product.
Here’s a story: I was trying to design a 13-period calendar picker in a product driven by quarters and months. When you get into 13-period calendars, you need to throw away everything you know about divisions of time. (You’d be surprised how ingrained 12 months and 4 quarters are in analytics design.) We needed to give our customers a way to configure a plethora of financial calendar systems that didn’t conform to the standard 4 quarter, January to December systems.
After banging at a lot of different and messy ideas and using the whole team, I was out running out of useful ideas. And then I thought of Mad Libs, and I remembered the Huffduffer signup form.
Huffduffer is an application that let you manage podcasts. Its sign up form is… well, different.
“I would like to use Huffduffer. I want my username to be ___ and I want my password to be ___.”
The signup isn’t a bunch of input boxes. It’s a conversation, constructed like Mad Libs, a childhood game where you fill in the blanks of a story (“I need a noun! A verb! A city!”) and make strange, dadaist tales. And that led me to rethink the setup form as the answer to a question rather than a series of input fields.
I imagined myself in a room with our customers, and I asked them all a question: “How would you describe your organization’s financial calendar?”
“Well, we have a 13-period calendar. Our first day is always the first Monday in January.”
“We’re different. We have a traditional 12-month calendar. But our first month is November.”
“Interesting. We don’t do quarters. We do half-years. But we track our performance weekly.”
With that, I created a mockup that looked like Huffduffer, like Mad Libs:
“Our calendar is (12-month/13-period/4-4-5/4-5-4), and we use (months/quarters/half years) to measure our ongoing performance. The first day of our fiscal year is (July 1/First Tuesday in January/our founder’s birthday).”
Ultimately, after a few iterations with the developers and product managers we fell back towards a form that wasn’t about “completing a sentence” but about “filling in the blanks.” However, the spirit remained. The form phrasing and order followed the original Mad Lib idea, and it’s still a core part of the product setup.
And that’s a story, to me. We had a problem, we worked on a solution, we got results. We had happy customers and we dealt with a very messy piece of configuration in an elegant way. Most of all, we never shyed away from the problem — “I want a system that I can configure to use our financial calendar” — and also never lost sight of the values we had in design — simple, human, understandable.
I tell that story in job interviews. It’s a perfect nugget for explaining how I design — focus on the problem, look broad for inspiration, iterate to a solution, never lose sight of your values.
As a designer, can you tell a similar story, one with a beginning, a middle, and an end? One whether you can explain the problem, lay out the objectives, explain what you did (and what the team you were part of did), and illustrate the results (good and bad)?
Every design is a story, a story you’re telling in partnership with your organization and with the user. How are you enabling every person involved to tell their story? How are you hindering them? And most of all, how are you allowing the user to tell their own stories with the tools of the story you give them?
Design is story. Communication is story. Rendering intent, in the end, is nothing more than another expression of the oral-aural tradition our ancestors first used to communicate their ideas.
Tell your story. And help your users tell theirs.
