Columns

XXXI.6 November - December 2024
Page: 16
Digital Citation

Is It Normal for a Design Project to Go off the Rails?


Authors:
Jon Kolko

back to top 

I've been working with a young designer, who is in the early stages of his career. We've been collaborating on a complex software design project, which includes new capabilities, legacy systems, multiple stakeholders, and many business units. It's progressing exactly as you might imagine: very slowly.

The other day we were discussing the project. He identified things that weren't going well, and recognizing his inexperience, asked me if that was normal.

It's a wonderfully self-aware question. In school, and in smaller and more contained design projects, projects run smoothly and creativity reigns. This builds a sense of idealism around the process of product design and development. It's typically a shock to designers when they encounter a mess for the first time.

Here's how some of the mess shows up in a creative project, and ways you can manage it.

back to top  Last Week I Really Liked It. Now, I Don't

When people see and experience new things, they form opinions, and they do it quickly. These opinions are built on their life experiences and taste and the way they feel at a given moment. But those experiences, opinions, and emotions change. In a business context, I've observed that people change their minds when they see how other people respond to something. A political business context has a way of generating groupthink, particularly around something subjective, such as aesthetics or interactions.

The impact of this back-and-forth is a delay in decision making, which ripples through a project plan. Design and development then experience the brunt of that churn, as a deadline will rarely change, but the amount of time to work toward that deadline shrinks.

ins01.gif

Additionally, a small creative change can have a large impact on a design system. That kind of impact on an entire system isn't clear to people who aren't actually doing the work. Wavering on a product decision about navigation can change every screen a user encounters. A simple change in one color demands rethinking all other colors to ensure a cohesive aesthetic. And sometimes a change in one product can affect other, tangential products, which may be completely outside the control of the team.


It's typically a shock to designers when they encounter a mess for the first time.


It's normal for people to change their minds, to make small changes that have a huge impact, and to contradict themselves. Here's how we can compensate for that behavior.

Build the indecisiveness into the project plan. Early in my career, if I thought my design work would take two weeks, I would estimate two weeks for the work. Now, after 25 years, I've learned to double or triple that estimate based on the size of the working team and the political nature of the work environment. Most people don't actually know how long creative work takes, and they rarely push back on an estimate provided with confidence.

Show how a small change has a big impact. As design tools become more collaborative, it's easier to let teammates peek under the curtain and see the process in action. I've found that making a suggested change in real time, and showing how that change will force a rethinking of the rest of the system, can help educate others in the challenges of a seemingly simple suggestion. If people act rationally, they'll begin to understand, and to adapt their suggestions.

Say no. (But do it nicely.) People want to be team players, but trying to accommodate indecisiveness may do more harm than good. Individual practitioners often seem reluctant to simply reject decisions, as if their own expertise and opinion somehow don't matter. Often, when people proclaim decisions, they really want them to be used as suggestions. When the spotlight isn't on any individual design element, they don't care too much. You may view a change in opinion as a catastrophe, while they think you're just having an engaging conversation.

back to top  Something Doesn't Feel Right, But I Don't Know What It Is

When a design isn't working, there's rarely a single reason why. Designers have learned to consider (and talk through) a design system, rather than a single element, in order to uncover a problem. Non-designers don't have that skill. They sense something is wrong, but don't have the ability to discern what it is, and don't have the language to communicate their concern to you. It's normal for people to provide vague feedback. Here's how to manage criticism that has little actionable substance.

Move the discussion off the computer. Digital design tools have made it extraordinarily easy to make quick changes and show alternatives. Real-time exploration often leads to the Magic 8 Ball, where you try things over and over as a response to vague input, until someone feels more comfortable with what you're showing. You've become just a set of hands, and you will quickly lose the ability to take a systematic, thoughtful approach to design decisions. Take the discussion off the computer and onto a whiteboard or a piece of paper to slow the speed of the rapid-fire solutioning. This will provide a more thoughtful and reasonable forum for discussion, and give you a way to extract structured feedback.

Shift the conversation to what is working, rather than what isn't. Incomplete feedback doesn't feel uncomfortable just to you. It also sits poorly with the person providing it. To resolve that discomfort, they may fixate on that one element, and that fixation can then make something small turn into something big. Help them move on by focusing on things that are positive. This will unlock the discussion.

Ask them to do their homework. Design patterns often emerge to deal with the complexity of technological changes. This means that other companies have worked through design challenges to establish a strong precedent. When you encounter vague, incomplete feedback from a teammate, ask them to instead find examples of those precedents.

back to top  Let's Make It Really Big and Red and Bold and Blinking in the Middle of the Screen and Above the Fold

Design is subjective. There is no right answer, and that makes a conversation about creativity complicated. But while there's no correct solution, there are good and bad ones. Most people don't know anything about that, because they aren't designers. They don't spend their time looking at products through a lens of aesthetics, usability, brand consistency, and content clarity. They haven't attended school for design; they probably don't read the same design articles or attend the same design conferences; and they haven't developed a design pattern language.

That doesn't stop people from having opinions. In the context of a collaborative project, it's reasonable, and often expected, for people to communicate those opinions. That's not specific to the field of design. Have you ever offered unsolicited opinions about the business strategy of your company, or the way marketing is communicating the value of your products and services, or the way the company spends its money? You have an opinion. It's not as informed or educated as the opinion of someone in charge of that part of the business, but you're still often encouraged to describe that opinion. Often, your opinion is ignored entirely, and that's probably for the best. It's normal for people to make objectively poor suggestions and decisions. Here's how to respond.

Provide a venue for others to communicate their feedback, and make the rules clear. Rules can include needing to offer suggestions in addition to complaints or coming to meetings with examples from other industries that support the point you want to make. That kind of guidance focuses these sessions into something productive, rather than a pile-on.

Find out the intent of the suggestion; it may hold merit. When someone recommends that you make buttons giant, red, and in the middle of the page, they're voicing an underlying concern. They think people won't see the button on the screen. The design recommendation is poor, but their concern probably is not. Why do they feel that way? Do they have evidence to support their opinion? Are their KPIs tied to that button being clicked? Poke and prod to uncover the reason for the suggestion, and then focus the design exploration on how to support that underlying need (or, shift the conversation to a critique of the need itself).

Educate the team. When people provide poor feedback, it's a perfect opportunity to help them learn why their suggestions aren't good. Quietly disregarding their comments tells them that you didn't consider their input. But engaging in a discussion that is educational—through theory, activities, and examples—shows that creativity isn't an ivory tower of exclusivity, and that you have a reason for your decisions.

Remind people that you're an expert. There's a reason you've been hired to do a job. It's entirely reasonable to remind people that, while they are welcome to their opinion, you have years of experience building up a skill set that's recognized as valuable. Push gently, but with confidence.

It's normal for a design project to feel like it's not going smoothly, for the simple reason that other people are involved. These other people don't have the domain experience that, as a designer, you've honed into a tacit skill set. Or they simply have alternative, and often valid, perspectives. If you were working entirely on your own, your project would be as streamlined as you could make it. But often, we call that art: creativity for you first, and maybe for you only. Design is a service profession. Recognize that your job is not just to make great things but to manage the context and experience of making things, too.

back to top  Author

Jon Kolko is a partner at Narrative and the founder of Modernist Studio, acquired in 2021, and the Austin Center for Design. He has written several books, including Well-Designed: How to Use Empathy to Create Products People Love (Harvard Business Review Press). [email protected]

back to top 

Copyright held by owner/author

The Digital Library is published by the Association for Computing Machinery. Copyright © 2024 ACM, Inc.

Post Comment


No Comments Found