Back in 1971, “Diet for a Small Planet” by Frances Moore Lappé made it clear the costs of eating meat were far greater than we had assumed. If we wanted the planet to thrive, we needed to shift to a more resource-efficient way to eat. UX Design is going through its own “you cost too much” phase right now. Companies are cutting back on design teams, and LLMs appear to be threatening our jobs. Everyone (at least on LinkedIn) is yelling that something needs to change. How can we have our “Design for a Small Planet” shift?

Part of the reason for this cost aversion has nothing to do with design. It’s more of a late-stage capitalism trap where companies overly focus on short-term goals like cutting costs or cramming in incremental revenue. There is a reason companies do this, of course: it kinda works in the short term. But you can only squeeze so much blood from a stone. At some point, you’ll need to actually create some user value. But that’s a big topic, which is rather hard to fix with a blog post.

But this hasn’t stopped many designers from spouting numerous hot takes on how to fix design, and social media thrives on amplifying extreme positions. I’m aiming for a more measured, if somewhat unexciting, stance. I’m convinced that proper UX requires user research, ideation, prototyping, and user testing, yet there’s an unfortunate disconnect between design and company leadership. We appear to cost too much and some companies are taking overly drastic steps.

Design is a team sport

So, let’s start with a simple premise: how can we make design less opaque and encourage teams to make small changes more efficiently? Not every product decision needs to be a big, complicated design process. The classic “Double Diamond” that has dominated design processes is often overkill. Of course, initially, some amount of big design work is necessary to validate the customer, product and market. But once that work is done, the vast majority of your daily work often involves making small additions. My theory is that much of our classic “Big Design” process is too insular and a bit too heavy. How can we make this feel smaller, lighter, and encourage more teamwork?

When an experienced designer is asked to “make a small change” to a product, they usually go through an internal checklist to make sure they don’t forget anything important. They just do this naturally, almost subconsciously. The team has little visibility into their process. This shouldn’t be a trade secret, invisible to the entire team. Instead, everyone should be involved in this.

The reason is simple: design is a team sport. You have to get people on board with what is important, how you’re thinking about the product, and how you make the right trade-offs. The secret is to get the team working at a higher level so they “get it” and implement the feature correctly.

The GIST Checklist

This checklist, in four parts, is meant to be a simple, lightweight way for the team to get the ‘gist’ of the issue and make a shared decision quickly. It’s a starting point, a way to get the critical information in one place so the entire team can understand and discuss. The four parts are:

Gather: Bring the right info together into a single place
Impact: List the size of the problem and possible risks
Sketch: Create a preliminary sketch of a solution
Team Huddle: Get the product team to discuss and agree on a solution.

Note, not everything on this checklist is needed. You often need just a few of them depending on the ask. Checklists are just there as an aid to make sure you’re not forgetting anything. Experience is knowing what to consider, yet doing only what’s necessary.

Gather

What is the user issue being solved?
Don’t make this about the tech. Spell out the problem from the user’s point of view
What type of user needs this change?
Will only a power user notice this or it is for a first time user? If you’ve previously done personas, consider referencing them here.
How big of an impact is the change?
Is this a small edge case or something that will affect all users?
Is there any previous work we’ve already done that’s helpful here?
Lean into any of your big design work such as research or flow diagrams to ground any decision you’re making.
Does this fit with the product roadmap goals?
Is this an important problem to solve? (many aren’t!) How does this tie back to the business goals?

Impact

How does this affect the ‘flow’ of the product?
Is this a spelling change or does it cause the user to make many choices?
What is the engineering impact?
How big of a change is this going to be? Are there simpler alternatives that might be good enough? What are the risks?
Are there any product safety consequences to this?
This is usually overlooked! Be very careful this change doesn’t have ripple effects that might compromise user safety. MANY post mortems have been written about skipping this step.
What are the accessibility consequences to this?
This too is often overlooked, be sure to think about all your users impacted by this.

Sketch

Sketch out low fidelity mockups of what it could look like.
Even a rough sketch is better than nothing. Just getting ANYTHING is helpful as it’s generally easier to criticize than create. Get something people can react to.
Run these past a few key folks for a sanity check
This is the initial team outreach. Get a few people to see what you’ve got and get their early reaction. Think of this as a type of pilot study. You’ll usually find lots of obvious problems with your initial approach, saving your reviewers a lot of trouble (in the next step)

Team Huddle

Put everything into a short sharable doc
This shouldn’t be long, just 1 or 2 pages. You can’t have a team discuss something if they can’t look at something.
Show it to the team working on this issue and argue (at lot)
The magic is mostly here. As a team stress tests this document, LOOK for trouble! Then update the document to reflect what the team now understands about the problem.
Get everyone to agree
Drive a solution that everyone agrees with. This is very hard. Doing it now is much easier than arguing later! This is the primary role of a UX designer, to herd the team into a decision. By doing this, you get everyone working together on a solution instead of bickering and stonewalling. Getting agreement here is key.
Point to this doc when creating the feature request/tracker
This should be obvious. Make this part of your build process, contain this so anyone reading the issue/story/card for this feature knows what to do.

Call to action

That’s it. A simple list meant to summarize the “gist” of the issue and then encourage team communication and teamwork to get a shared decision. Much like UX design, this post is more of an alpha release. This is a complex problem and I expect I’ve missed something important. In a way, I’m one of the blind men describing the elephant, I can only address what I’ve experienced. This is my first prototype of an approach to smaller design, to be user tested by you as a reader. I’m joining others, like Pavel Samsonov (who inspired this post) in taking an incremental approach to discussing one way to make things better. I hope by collecting lots of these, a collective whole will start to appear.