Content-driven design — love it or hate it?
Too often in the design world, once Lorem Ipsum has done its’ job, mock-ups are chucked over the wall into content-creation land. But is this really the best way for designers or content writers to work?
Having worked in a few IBM teams and recently graduated in Product Design, one of the most varied qualities I’ve seen at work so far is the management of content. While I’ve sometimes been able to work with talented writers, and have access to fantastic voice and tone guidelines, some of our designers won’t touch actual words unless they really really have to.
I think they’re missing out — every time I draft a sentence at work I learn a HUGE amount. So I thought I’d share some of the benefits you designers of the world might enjoy from using a content-driven design strategy.
Information hierarchy takes control — keeping us low fidelity for longer. Too often, with the growing influence of Design Systems, we wireframe in components. I do worry that gone are the golden days of whiteboard-drawn boxes and labels, but wireframing with information is a great way to return to these basics. Take using flowchart prototypes — this massively familiar way to present information and decisions is perfect for articulating the primary, secondary and subconscious mind-journeys users have through experiences. Next time you’re working a problem, take your team’s content ideas into a tree jack or card sort. This way you’ll really tackle your assumptions around navigation, hierarchy, calls to action and actual content. You’ll also be amazed that a simple title and tagline can so accurately represent your page/article/widget/action/feature.
You’ll impress with domain knowledge. It’s not easy to build a good domain knowledge (especially when you’re working in a complex space like Hybrid DevOps and Management 😉) and sticking with Lorem Ipsum (or suitable cat-related alternative) can mean passing up a valuable learning opportunity. Whatever complex industry you work in, approaching design with more than empty boxes and placeholders is your ticket to go beyond design expertise… this is your chance to add cloud architecture expertise or healthcare writing expertise or something equally sophisticated to your resumé.
So, gather up your team of techie geniuses/academics/Dr Frankensteins, step through your user’s journey, and get into the nitty gritty. Why does the user want to launch that application? What does the spike in that graph tell them? Sure, it sounds like the questions you should be asking anyway, but this content-focus can push you into more detail than usual.
You argue better. How many times have your stakeholders told you “That call to action should be this word”? And chances are, you said “Okay, we’ll get that changed”.
But why should anything really be any word? Often it’s because of what’s going on behind the scenes. For example, if I delete a message queue in IBM’s MQ services, it might stop, aquiesce, pause, and then shut down. That’s what MQ administrators have known and loved for the last 20-odd years. 20 years ago, just a delete button wouldn’t have sufficed; 1990s people expected to know about the stopping, aquiescing, pausing, and shutting down.
In modern offerings a trash-can icon would be fine. Why is this? Because society’s expectations change with time, as influenced by design. When Apple started used t-shirt sizing to categorise macbooks, they were deciding that users just didn’t need to know about RAM, storage, refresh rate etc. When you’ve got all the facts, you can challenge the classicists in your product team, and you’re empowered to make brave (innovative) decisions.
You might have noticed that everything I’ve said so far hinges on you (the designer) learning a lot. But this doesn’t need to be done fast.
I’ve mentioned using titles and taglines as identifiers for your content — this is a great place to start, and a good way to carry out many design activities. If you’re mapping a site hierarchy, consider whether images or screens make more sense, or a quick 1-line description?
A great activity is Desired Outcomes. In charting a new scenario to explore, we write down every hypothetical aim we thought our persona might have day-to-day. There were hundreds. What we’ll now do, is rate, sort, and validate with users, until we reach a definition. That’s typical of where words really work — in quantity, and in group work.
Similar approaches can be used in planning website content — bring in your mutli-disciplinary team and get them to compete for largest quantity of (for example) website content ideas. You’ll inadvertently cover all your edge-case users, and the most and least technical options. Then, while they’re all in the room, have these experts agree a tagline to explain any that are confusing or unfamiliar. Creating a tagline for every idea can be a great activity to align people — it’s amazing how often we misunderstand each other.
When we need to co-write a tagline, our team turns to the trusty sticky note — charting alternative terms word by word through the sentence. In the room, we speak to each other through analogy, and rearrange post-its until we meet the length and the tone we want to go for.
This is a great time for you to slide-in complex technical words you think might fit there, but you’re not really sure. Post “aquiesce” on your sticky-note and have the people in the room explain why that’s not the right answer. Of course, you’re the designer, you own the prototype, and can conveniently discard plenty of this detail at your discretion — but your team don’t need to know that.
Pictures (infographics, animation, videos) are worth a thousand words. We all love them. But sometimes, you just need one word, and getting the right one changes your user’s whole world-view. Don’t underestimate the power of words — and to get your team started, write down three words you’d describe your brand with today. Debate.
Good luck!
Chloe Poulter is a Designer at IBM based in London. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
