“Is the Design Done?”: Integrating UX and Agile Intentionally
A sketchy article on how understanding our differences can help us communicate across borders in development and design.
(This article is adapted from a lightning talk I did at IDEO Tokyo for Code Chrysalis’ MiniConf #8: Design Edition.)
Hello, I’m Chelsea. I work as a UX coach and designer at yamaneco, an agile coaching firm in Tokyo, Japan.
Over the years I’ve had many roles—as a cartoonist for indie zines, a design researcher/interaction designer for design agencies, and a UX coach and designer for product development teams.
In agency, I worked with international clients researching, strategizing and prototyping digital and physical systems. I moved from agency to product development two years ago. When I did, I came to a world that was mostly unknown to me: agile development. I was used to working in a design-led, design thinking environment, and the switch was a significant culture shock.
For those of you unfamiliar with either agile development, Amanda Stockwell summarizes agile well:
Agile is a software development approach. It was born out of frustration with traditional “waterfall” software practices [which struggled with] the ability to understand or respond to changing needs.
Software developers started experimenting with new ways to build, and came up with a set of shared values and principles to guide teams to do better work.
And from IDEO’s website on design thinking:
There’s no single definition for design thinking. It’s an idea, a strategy, a method, and a way of seeing the world. It’s grown beyond the confines of any individual person, organization or website. And as it matures, its history deepens and its impact evolves.
For IDEO, design thinking is a way to solve problems through creativity.
On the surface, both of these systems help people solve problems and build better products. There are many similarities between agile and design thinking. However, while they may appear similar today, they have completely separate histories.
The separate histories of agile and design
Before agile was waterfall. Waterfall was made to support the creation of industrial products. If a company shipped out hardware, it was very difficult to change after production, so everything had to be decided beforehand. Enter digital software and code, which completely changed the way the world thought about what a “product” was.
Software can be constantly improved even after its release, so many began proposing ideas, some taken from rugby’s chaotic energy (hence, scrum) to extreme programming, to find a better way to build these new products. These processes shaped what we know as agile and lean thinking today.
Similarly, design thinking started from industrial design’s need to think about systems outside of the product, such as environmentalism or sustainability. From there it joined forces with human computer interaction and became the study of both physical and digital systems. When blended with the fields of behavioral psychology and ethnography, modern design thinking and human-centered design were born.
For the past fifty years these ways of thinking have grown up independently of each other. They have developed their own lingo and way of thinking from different sources.
The problem with modern agile and UX integration
Many smart people have already been thinking about and adopting agile and UX integration. There’s Lean UX, Design Sprints and some product teams have even adopted brainstorming and user testing within their sprints. I’m excited with how we’ve progressed.
But all too often I see the teams we coach integrate design processes (workshops, personas, customer feedback, etc.) without applying the mindset of design thinking. This results in the output from these processes becoming either a separate track from the development sprint or something that languishes in the backlog forever. Meanwhile, the team continues producing features that they’re not 100% sure are needed.
The main problem is this: it is very hard to integrate agile and UX if we do not understand we are speaking two different languages and thinking in two different mindsets.
Language is the words and expressions we use, and what these words mean to us. Think of a dog. You and I may agree on the concept of a dog (four legs, wagging tail) but will differ greatly on what we are picturing based on what the word means to us.
Mindset is what we believe is true, our actions and behaviors and our attitudes. These take a long time to build, and a long time to tear down as they are ingrained.
First, let’s look at the language disconnect in the phrase, “Is the design done?”
The word “design” could mean one or more of these three things:
- A thing we made, like wireframes, prototypes or customer journey maps
- How the thing connects to other things, like the architecture or the user’s journey
- Why the thing exists, like our design rationale or the problem we are trying to solve
The word “done” could mean these as well:
- “Did you make a thing?” — Anything, even something work in progress to share with designers and non-designers.
- “Will this thing change?” — Is it “final” for this sprint? Next month? Next year?
- “Is this thing implementable in code?” — Can I make it in code now, or do I have to wait?
There are far more definitions than this. But even taking these simple definitions means the question “Is the design done?” has many different hidden complexities in a simple question.
So which definition is the right one?
When I explore deeper with my teammates as to what they mean when they ask, “is the design done?” what emerges is this simple question.
“Will I have to rebuild this?”
For my teammates, they worry that if the design isn’t done it means that there will be inevitable rework and rebuilding, which takes extra time and energy.
As a designer, my reaction to this is:
“Maybe…but is it that bad to rebuild it?”
And herein lies the second difficulty of intentional integration—mindset.
Introducing flexible and inflexible mediums
Let me step back and speak as one of my past roles—an illustrator and cartoonist. In art, the tools we use to create art are called mediums. There are two different types of mediums—flexible and inflexible. In this context, flexible and inflexible do not mean good or bad—they are simply categories. Each medium is suited to a certain presentation or style.
So how does one differentiate between flexible and inflexible mediums? By asking the question, “how easy is it for me recover if I fuck up?”
A flexible medium is something like pencil or digital canvases. Pencils can be erased. Digital canvas layers can be hidden, adjusted or deleted entirely. When a mistake is made it will usually take you less than five seconds to recover—just erase and continue drawing. The paper or digital canvas can be reused over and over.
An inflexible medium is something like ink or watercolor. Once ink is put on a piece of paper, it soaks the fibers of the paper permanently. You can recover from a mistake in pen, but you may have to use Wite-out or other kinds of tricks to cover up the ink. Or you can throw the paper away and start over.
Let’s take a look at some examples.
Another example of a flexible medium is digital. I did this drawing in Procreate on the iPad. As you can see from the animation above, I’m constantly erasing, redrawing and adjusting. I draw the hand splayed out, but ultimately it doesn’t look right in context, so I erase and start over. I do this throughout the entire process. I’m constantly experimenting.
Erase, adjust. Erase. If someone were to ask me at any point during this process, “is this drawing done?” I wouldn’t be able to articulate clearly yes or no. I would be able to say if I was in the middle of an experiment or if the experiment worked or not. The drawing became done when it felt done.
The logical definition of done in this case is based on if the drawing has correct proportions and weight, the right color balance and other measurable metrics. However, I don’t just use logic.
Design is equal parts logic and emotion. This is the emotional part. The design is done when we are satisfied or when looking at it gives us a sense of union and harmony. We have a vision, we do experiments to meet that vision and change the vision based on the results of our experiments.
Flexible mediums support this kind of experimental thinking, and creatives use flexible mediums all the time—pencils and paper, pens and post-its, Sketch and Illustrator.
Compare this with the way I approach traditional comic-making in ink. I love ink because it has a strong impact and looks incredible. However, as soon as ink touches the paper, it dyes it through completely and cannot be magically lifted. Because of this, I do planning beforehand. I draw a small thumbnail of a comic to understand layout and flow, then an underlying sketch. Finally, I layer a clean sheet of paper atop that sketch and trace in ink.
Every layer has a purpose to prepare for the final result. When I draw traditional comics, I may not know at the beginning what the page will look like, but once I complete the underlying sketch I have a good idea of what the inked result will be.
Here, if someone were to ask me at any point during this process, “is this drawing done?” I could tell you easily because in inflexible mediums I’m thinking in stages and layers. If the thumbnails have been completed, the drawing is obviously not done because I have not layered the paper on top of the sketch yet. Once all the layers and processes have been completed, then it is done.
Of course here I still rely on my emotion to tell me if something is done or not, but I’ve added some extra processes in to give me a benchmark of when the piece may be done.
Inflexible mediums support this kind of layered thinking. There may be experiments that happen on each layer, but there is a clear delineation between each step in the process.
Code is an inflexible medium
I’m sorry to break this to you, but code is an inflexible medium.
It may be more easy to update than the past hardware of the 1970’s, but it has a layered pattern to creation—first, build the underlying architecture, then the structure, then the polish. Remember, an inflexible medium doesn’t mean that it is impossible to change once set up. I can recover from a mistake in ink, it’s just harder to do than pencil.
There are parts of code that are more flexible and experimental, like CSS, sometimes. There are other things that are far more inflexible and difficult to change like databases or architecture.
Because code is inflexible, one must think in layers to implement it. And designers, creatives, those who use flexible mediums are not always thinking in layers. We’re thinking in experiments.
You might be thinking at this point, “No, code can (and should) be more experimental.”
And you’re right. I want code to be more experimental, too. There are technologists like Alan Kay, Bret Victor and Brendan Dawes who have pushed the boundaries of code to find ways of interacting more flexible and experimental. These folks are the reason why I became an interaction designer in the first place—because I wanted to see code become more experimental and artistic.
However, the languages we use for building large-scale software are still inflexible mediums.
What should we do now?
So, what should we do? Have designers adopt a layered way of thinking to adapt to inflexible mediums or have engineers adopt an experimental way of thinking to adapt to flexible mediums? The artist in me favors balance.
We should be able to simultaneously think both ways based on context. For instance, for painting I prefer flexible mediums because I believe color is experimental, but with black and white, I highly prefer inflexible mediums because the impact is strong. I switch mediums based on what I am trying to create.
So for balance I have two pieces of advice—one for development, and one for design.
Developers, kill your darlings.
This is easy to say, but hard to do.
When I was in art school, I never spent longer than four hours on an art piece. I prioritized fast drawing over contemplative drawing because I wanted to be a cartoonist. After hearing my boasting, my teacher gave me an assignment.
“For your next piece, I would like you to spend four hours or more making art. The subject doesn’t matter, just the time.”
I followed his instructions and spent hours and hours on an art piece — more than I’d ever in my life. I remember feeling so proud as I showed him the art I’d so painstakingly created.
Without saying a word, he took a handful of charcoal dust from a nearby jar and smeared it all over my beautiful piece. I was in complete shock and despair. All that time, wasted.
“Do it again,” he said.
I was seething with anger when I went back to my desk to redo what he’d ruined. He graciously approached me and said, “those four hours you spent on this feel lost now, but they’re not. You spent them learning. Now you are more skilled than you were when you started and I’m confident you can create an even better piece.” And you know what?
He was absolutely right.
What I learned from that incredibly wise art teacher was that the time we spend on making something is never a loss. Making things helps us think, help us communicate our ideas and every time we make something and redo it, we get closer to the solution. We should never expect our first idea to work well. Only through constant iteration and making does an idea become great.
So often I see in our agile teams a fear of throwing things away. Even in asking if the design is done I feel this fear. Because if it’s not done, the team will have to rework. In an iterative process like both agile and design that is trying to encourage experimentation and iteration this fear will kill the team’s velocity and ultimately slow them down to a crawl.
I get it. Code is inflexible; some parts will take days to set up again. But even if it is our darling we painstakingly created, sometimes we have to kill it. Killing your darlings is infinitely hard. Killing them joyfully is even harder.
But I promise that the more you do it, the better you’ll get at it, and the better you get at it, the better developer you’ll become.
Designers, keep the team and yourself honest.
No one wants to think about what happens if users don’t like your thing. Many teams I’ve observed are experimental by nature but receive a lot of pressure from the business side to deliver to fail fast, which in theory is great but in practice usually means it’s okay to fail once, and only once.
You must be the advocate for experimentation and failure and constantly be asking the question,
“What if the thing we’re building doesn’t turn out like we expect? We may have to throw it all away.”
Keeping the team honest and humble is the trick to integrating this mindset of experimentation. And you may have to fight.
There is an assumption that the designer should know what the user thinks and if their ideas fail, they are not a good designer. But the measure of a good designer is 15% in the idea, 5% luck and 80% tenacity. Be tenacious.
Tenacity is hard to achieve alone, so you’ll have to rely on and support your team so that you, together can be strong. Take responsibility for stupid decisions when you make them, but remember that you, the development team and business are in it together to build something that people love. Use that base as a reminder when you find yourself in a heated discussion.
Looking for a way forward
Both agile development and design thinking have grown up in different environments, fed with different ideas and grown in different ways. They are similar on the surface, but in terms of language and mindset, very different. By understanding the history of both, I hope you understand the difficulty of fully integrating both as well as the start to a path forward. There is no silver bullet.
We at yamaneco have been testing ways of integration with our teams for about a year and they vary wildly based on team size, remote/non-remote and team personalities. Some aspects of Lean UX work very well; sometimes not. We’re experimenting daily with new ways of framing information to help with language and mindset disconnect.
However, I do know this: only by stepping into the mindset of the other will we be able to truly empathize, and empathy is the best way to start a beautiful union between two fantastic, different individuals.
Thank you.
If you’d like more resources by smart folks on agile and UX integration, I wrote an article called “Want to integrate Agile & UX intentionally? Start with these reads.”
If you’d like to work with yamaneco on bilingual (Japanese and English) design thinking and agile integration in your organization in Tokyo, get in touch via email or Twitter.
