Make sure your team doesn’t jump on ‘good enough’ solutions
“How much time does UX need?” Unfortunately, that’s a question I had to learn to answer to become a Senior UX Designer.
One of the cool things about being a designer is that you’re the first person to take a crack at creating something visual. The mockups, wireframes, and prototypes you design are often the blueprints the rest of the team follows in building the front end, thinking about database design and specific content and marketing.
As a result, you’ll often encounter time pressure in several ways. Whether it’s Developers itching to get started, Product managers thinking about budgets, or Agile coaches planning a sprint, the rest of the team may nudge you to finish as quickly as possible.
Learning how to respond to these time pressures was a crucial skill to become a Senior UX Designer, as I needed to not only speak for myself: I needed to plan for those I was mentoring as well.
So here’s how I’ve learned to respond to that question and avoid the consequences.
Time pressures and ‘good enough’ designs
Let’s get this out of the way: it’s very rare for a team to cut off the design process prematurely. So you won’t be handing off unfinished designs unless something goes wrong.
However, what often happens is that time pressures force Designers to settle for ‘good enough’ designs: these are less-than-ideal solutions that teams jump on, even if they’re not great.
Part of this is due to a psychological phenomenon illustrated by the candle problem. Users were given a box of tacks, matches, and a candle and told to secure a lit candle to a wall. Unfortunately, those that were first influenced by negative factors failed to consider creative solutions for the materials, such as using the box to create a platform on a wall.
Negative factors, like time pressure, can cause your team’s focus to narrow and jump on the first solution someone suggests, which may be a ‘good enough solution. They’ll justify a tooltip being incredibly long or instructional text being incredibly confusing by saying, “we’ll make it better in the next version.”
At that point, you have two possible options:
- Come up with amazingly creative design solutions in a short amount of time (that are easy to implement)
- Try to negotiate for the best ‘good enough’ solution and plan better next time
I’ve pulled off the first option sometimes, but it’s hard to do that consistently (especially when you’re feeling time pressure). As a result, I’ve had to do the second option enough that I know how to plan better and avoid these situations.
To do that, we need to think of the three time periods we encounter in each project and what to do in them.
The typical design project is broken down into three phases
These are by no means formal phases of a design project: instead, these are meant to be rough phases of the typical project and the different types of work UX Designers usually do in each.
Project planning, requirements, and user drafts
Discovery seems like an odd time to start thinking about time constraints. Businesses might be working out their requirements, features, and product vision, while UX Designers and Researchers and learning about their users, the problems to be solved, and what the business wants to achieve.
However, three things are typically helpful to uncover at this stage:
- Understanding users, stakeholders, and more through exploratory research, workshops, and other methods
- Identifying and framing problems to understand you might solve them
- Understanding how projects will be broken down and planning a rough timeline estimate.
The first two points should be familiar to anyone who’s done User discovery before. However, the third point will be essential in ensuring you don’t face any time pressures later.
For example, I might have a project that should be completed by September 2023. Of course, it’s too far for me to plan that far in advance in great detail, but teams typically break things down by saying, “We’ll start by working on X page, then do Y page, Z page, etc.”
Understanding the scope of each section will help you think about how much time you have to iterate on your designs. For example, if the first page is straightforward, while the next page is very complicated, you might plan to spend more design iterations on the second page instead of the first.
This is only made more apparent as we begin to design solutions.
Plan to iterate your designs
When you have a rough idea of how much time you have for a particular piece of the project, you’ll be likely to avoid the most common time-constraint trap: facing resistance to doing another round of user testing.
Teams often understand that user testing is essential but may not understand that you need to user test often after making substantial design changes.
So with those rough estimates of work in mind, you should begin to plan how many rounds of user testing you want to aim for with each section of work. However, one important thing is not to nail down an exact number too early: you don’t want to be out of ‘user testing rounds’ if you need to get feedback.
There are two rules of thumb that I like to follow when planning out design iterations:
- Adapt a round user testing/iteration to fit your Agile sprint
- Planning potential expedited user testing after significant changes
For the first rule, I tend to plan for user testing and design iteration to be complete at the end of an Agile sprint. This means:
- User testing (I recruit ahead of the sprint if possible)
- Gathering and analyzing feedback
- Coming up with design recommendations and scheduling a presentation
- Iterating on the design based on approvals
I’ve usually worked in two-week sprints, but have adapted this to fit 1-week and 3–week sprints as well. This rule of thumb helps you understand how many rounds of user testing you can typically fit into a project. For example, if a project is projected to last 5–6 sprints, then you can fit 2–3 rounds of user testing into it.
However, it’s essential to remain flexible as well. As a result, if any significant changes are asked about or implemented, you should clarify that you need user feedback. As a result, you should plan what you might do for an expedited round of user feedback so that your team won’t have to wait for an entire sprint to implement a change.
For example, rather than full-out user testing that would take a sprint to complete, you might plan to expedite your user testing in the following ways:
- Have a quick conversation (15–30 minutes) with new testing participants about a specific change
- Send out a one-question survey e-mail to your previous test participants
- Seek out the analytics from things like A/B testing
- etc.
These things should be able to be completed significantly faster and help to safeguard you for the next and trickiest phase of the project: when your prototypes start looking close to completion.
Budgeting time from ‘almost finished’ to complete
As soon as designs look at least somewhat visually polished, sometimes your team will be itching to get started on the subsequent phases of the project.
I’ve encountered pushback from Developers, Project managers, Product Owners, and more as to “Why is Design taking so long” at this stage.
It’s then when you have a plan of action for pushing back. For example, perhaps there was bad user feedback for the design solution that requires additional thought, or you’re still iterating based on a recent user test (with a set timeline).
By establishing these patterns and work periods, you can ensure that you have enough time to come up with the best possible solutions in your allotted time.
Budgeting time is an essential skill for Designers to learn
Product Managers are the ones that typically handle time and budget constraints, so it seems weird for me to say that Designers need to learn how to manage their time correctly.
However, it comes with the territory of being a designer. You’re often the head of a ‘pipeline’ of work, leading the way to ensure that a website or application is designed with the user’s needs in mind. This means that you need to be able to give solid and definitive timelines as to how long things will take rather than people eyeballing based on the visual fidelity of work.
Doing so will ensure you have enough time to create your best designs and avoid ‘good enough solutions.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.
