Are you missing out by waiting until your org is ‘ready for design’?
I’ve heard this from start-up CEOs, from volunteer programmers, and from many sizes and stages of teams, some earnest and some frustrated with their company’s stance on design.
“We’re not ready for design at this stage.”
What a terrifying statement to hear as a designer! This means we, in human-centered and planet-centric design, haven’t done our job very well. We haven’t yet helped people understand what design is, when it should come into play, and how it contributes.
So if you’re unsure about how, when, or why to employ design and designers in your organization, I’m going to try to remedy that.
What is design?
Design isn’t a phase in product development; it’s the act of intentional creation.
Design
transitive verb
to create, fashion, execute, or construct according to plan (from Merriam-Webster)
Everyone is designing all the time. If you work at a non-profit, if you deliver healthcare to patients, if you’ve started a digital company with a friend, it doesn’t matter if there’s anyone around you with the title “designer.” Someone thought about how your website would look (or at least they built a site, even if there wasn’t a lot of intention behind it), they thought about how patients want to sit down while they wait to be seen, and they thought about how your non-profit could get resources from some people and give them to others. And if you work anywhere with a business model, functional or not, reliant on donations or not, someone designed that too.
It is impossible to build anything, physical or digital or experiential, without designing it. Have you ever thrown a party? Then you’ve been a designer. You’ve settled on an occasion, a time of day, a guest list and menu. Even the worst party, thrown together at the last minute, has been designed: someone sent out a mass text, then ran to the store and grabbed beer and liquor. Oh yeah, and plastic cups! That moment where you remembered plastic cups is your designer-brain kicking in, thinking about the needs of your party guests: people want to drink out of something other than a communal bottle. You considered the experience, and you improved it.
By the way, did you remember paper towels?
When to ‘do’ design?
Design is always happening; however it is often not intentional (enough).
The definition above specifies creating according to a plan; this implies intentionality. However, the intentions are often vague and/or limited. So rather than talking about when to do design, let’s talk about how to be more intentional about design.
Good, responsible design is the union of all these things. But you’re likely to miss the boat on several nodes if you don’t build these intentionally into your product or service from the ground up.
Here’s an example of designing without real intentionality: I’m a UX designer within OpenOakland, a volunteer brigade of Code for America. In January 2020, I joined a new-ish project for the US Census. The team consisted entirely of programmers, and the task was to build an event calendar: a website where community centers could submit upcoming Census events they were hosting, and individuals could view a calendar of those events. No further specs, requirements, or research were defined; this was the extent of the plan.
I took a look at the website the team had built so far. Trying to get a sense of what I was looking at and how I could contribute, I started asking the hard questions: “How has design happened so far? Who decided how this tool should work and look?” After all, it had an interface. It did something. There were clearly one or two iotas of thought behind the placement of elements on the screen.
The engineers looked at me in confusion. “No one’s designed anything yet.”
“Well, someone thought about what was going on the page. These features. What is needed for it to function. How was that stuff figured out? Who wrote these words here?”
More blank stares. It seemed no one—or more probably, everyone acting separately—had done the part where they figure out what this tool actually was. And there had been no communication about it, and little conscious decision-making.
Building a product this way, in another context, might seem flawed:
You decide you want to bake a cake. A couple of friends and you get together, agree on chocolate cake, and with no recipe you all start to bake a cake—or your idea of it. You’ve all baked before—not always cakes, not always from scratch, and not always chocolate, but that’s okay.
There’s no communication about how the cake should turn out. One person grabs a cake pan and greases it. Another throws flour and eggs into a bowl. Someone is melting chocolate. Everyone is pitching in where needed! What an amazing team effort. Everyone is executing their own plan, and the problem is, these plans are patchy and don’t perfectly align.
The result is not going to be that great. You’ll be lucky if the ingredient proportions turn out decent, and there’s disagreement about frosting flavor. The whole thing might fail to rise or taste terrible at the end. No one thought to preheat the oven.
What can intentional design look like?
In an ideal world, design is not just executing the plan; it is also the process of developing and aligning on the plan ahead of time.
Here’s what the difference between what those two options looks like:
Execution only: Three friends approach you and say, we need to make a chocolate cake. You select an awesome recipe (or they hand you the recipe to work from) and you oversee the execution of it; a delicious cake emerges from the oven two hours later, and you cover it with delicious frosting. The cake is successful because it looks and tastes good—and exists without context. Your job is done.
Strategy and execution: Three friends approach you and say, we need to make a chocolate cake. You sit down with them to learn why. They’re going to bring it to a potluck picnic and share with all their friends! So you find out how many people this cake needs to feed. Eight? Twenty?
Will the cake sit in the sun and be served at the end of the afternoon, or is there a way to refrigerate it?
Do they have a way to transport the cake safely?
Are there any food allergies among the guests?
Is someone at the potluck bringing plates and utensils?
What will the cake sit on while it’s being served?
What time do they need to leave for the party?
How should the frosting be flavored, and what will the cake decorations look like?
Because the friends have no cooler, no cake-tray, and no desire to get up early, bake a cake, and let it cool before frosting it and bringing it to the party, you all agree instead to make chocolate cupcakes. They’ll sit overnight, the frosting will go in a container in the fridge, and they’ll frost the cupcakes at the party with a homemade piping bag that they will have practiced with ahead of time.
The dessert is a hit, and they become heroes among their friends. (Okay, maybe that’s an exaggeration.)
The recipe was not the entirety of the design strategy; it’s more like the product wireframe (where the taste is usability and the frosting UI). There was a lot of work that went into deciding on the right recipe, and how and when to follow it: party guest research, recipe prototyping, taste testing, journey mapping, aligning on goals and roles and processes and tools.
Furthermore, design doesn’t end once the plan is in place — now that everyone understands the design brief, they can make design choices constantly. The goal was the richest chocolate cake in the land! If you taste the batter and it’s just not chocolatey enough? Try adding more cocoa powder. Party time has changed? Put the cupcakes in the oven later.
(Good) design is the ideation and execution of a solution, in consideration of the context in which it will exist.
Guests, recipe, shopping, baking, transit, party, eating, and clean-up.
(Notice how the first consideration is for the people eating the cake? That’s the human-centered part of human-centered design! And notice how there’s clean-up involved? That’s planet-centric design! I’ll talk more about that in an upcoming post.)
The perils of designing without intention
If you wait till you’re ready for design, you’ll miss your opportunity.
I never did get answers from the event calendar team about how decisions had been made. My hunch is that they each thought they knew what an “event calendar tool” was, so they started creating chunks of it from memory. The date picker. The back-end database. The entry that shows a listed event.
They were all designing, but they didn’t know it. The result of this was that the tool looked like web c. 2001, wasn’t very usability-friendly, and most importantly, no one understood how it would be used and what features were required by the community centers. By the time I began to understand the design brief, the date-picker was an itty bitty 200 x 200 px calendar stuck in the corner that didn’t let you un-select a date. We couldn’t change this to a more visible and user-friendly widget because it would be too difficult to change so much code at that late point.
No amount of beautiful frosting will cover up a burnt, over-sugared cake. Design is not a veneer, a phase that happens at the end to make it look pretty. It’s not even limited to the form of the thing. You can make an amazing cake, but is it the right dessert for the party?
Without defining clear intentions, and developing a plan of execution to match, you run the risk of making a cake that’s edible, but turns out to be totally wrong for the job.
Do you need a ‘designer’?
Everyone is designing all the time. Don’t forget our original definition: to execute according to plan.
Ideally everyone in your organization understands how to do their work for the benefit of users and the planet. People with different job titles have been doing “design thinking” since long before there was a name for it; no degree is required. But realistically, it’s hard to stay focused, harder to develop a thorough practice around this, and hardest to achieve alignment across teams.
The important part is not to throw designers at your problem and expect a magically great product, but to enable everyone to do their work intentionally by designating (ooh interesting root word) people whose job it is to champion the end-users, the planet, and a sustainable systems approach. You need someone who can advise on best practices, and create tools and guides to help others incorporate design thinking into their own expert practice. A “design leader,” perhaps.
The ideal of the “design-led” company has been on the rise for several years, and now we are beginning to see some push-back to this model. Having some people with the title “designer” creates pressure on a design-led organization to be led by designers (duh?).
In fact, the job title “designer” is somewhat in conflict with the idea of “design,” because it seems to limit who can participate. But is it designers who should be leading, or the act of design?
Programmers could just as easily be called “software designers” (and sometimes are), and marketers could be “campaign designers.” There are many different kinds of “official” designers, but their specialties are not any more important than any other roles. What is important is the practice of taking into account end-users and complex systems rather than falling back on personal priorities, like appeasing a board member, or short-term thinking, like making products from cheap materials.
The truth is, it’s not that designers should be calling all the shots. It’s the practice of intentional design that should be elevated.
A organization’s design leader is useful not so much as the person who does all the designing, but as the person who shares their toolkit of intentional design practices, and helps others apply it to any challenge. They use their experience to avoid common pitfalls, while listening to the expertise everyone else brings to the kitchen.
AirBnB has tried to imbue design throughout the organization by having every team led by a project manager, whose job it is to advocate for users. Other companies scatter designers throughout teams, or have one large internal design team that acts like a consultancy. There is no single way to lead with intentional design. The needs and function of the organization will shape the most effective ways to center design.
When I first heard about the event calendar team, I asked one of the members if they could use a designer and he said, “Well, we haven’t finished building it yet, so we’re not ready for design.” My jaw dropped.
“The time to do UX is before you start to code,” I explained to him. “Lay out and test the design first to see what works and what doesn’t, build after. That way you don’t struggle to make changes after the fact.”
Before I had even finished talking, he put his hands on his head, sighing ohhhhhhhhhh. His brain was gently exploding as, presumably fresh out of a bootcamp, he suddenly though about the union of design and engineering for the very first time.
He intuitively understood the logic of this. Measure twice, cut once (or mix, in the case of our baking metaphor). It’s much harder to reverse-engineer a product to respond to research insights, to create lasting value, to work within a complex system, than it is to build those in from the start.
And after mixing the batter, you still have adjustments to make, a cake to frost, guests to get feedback from. The process is never complete.
Or did you think you were going to be finished after just one dessert?
