Build Design Systems With Penpot Components
Penpot's new component system for building scalable design systems, emphasizing designer-developer collaboration.

UX Power Tools – Medium | Christian Beck
You know that oft-quoted line from Antoine Saint-Exupery?
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
As it turns out…not so helpful when you’re actually designing.
At some point you get stuck in Iteration Hell, and I believe many of us have reached our emotional breaking point where all we want to do is take everything away, go Office Space on our laptops, and just move the woods like Henry David Thoreau.
Or, you find yourself going heads down on a particular feature or UI component — you enter that oft sought-after flow you’ve read about so much in Medium self-help articles, then wake up hours later realizing you have a masterpiece. But you look at your requirements and panic realizing that what you actually designed wasn’t even in this sprint, and you haven’t even addressed the important pieces.
Sad!
Understanding when to put your pencil down is a real challenge for designers. It’s an art unto itself that can take a decade to master because it requires years of repetition and patterning to help form your innate judgment. In that process, designers have to ensure they are paying attention to the right details by understanding how the design solves the right business problems, what parts are tricky to build, and when a design is, well, good enough.
How can designers make sure they are building this judgment to ensure they produce quality design work on time? Being a great designer is not just about doing good work, it’s about doing the right work.
Yep, none of us do. But “good enough” doesn’t have to mean you deliver mediocre work. It simply means you have done the correct amount of work and given the appropriate amount of effort given development time, and business, user, and customer value.
This plagues junior designers. Often it’s something that is best corrected early on, so if you’re feeling this way, address it sooner rather than later.
That said, it’s inevitable to get that feeling of dread once you’re deep into a feature from time to time. But that’s partly why agile and lean methodology exists. Even mistakes in design can and should be corrected quickly.
We all have things we have to do and things we want to do. Partly this is what keeps us designers motivated when the bulk of our production work is just “boring” design details. In the next section, we’ll dive into how to make this possible without causing you to miss deadlines.
Hell, write them down on a little note card and attach to your monitor.
These are the requirements that are driving the feature you’re working on. They are your guideposts and your North Star that will help bring you back to reality. In practice, these guidelines can get buried in JIRA or Asana.
I find that it can be helpful to copy these over into my own Trello board (or whatever to-do app you use) so that I actually see them as I work.
Typically, I’ll even translate use cases or requirements into discrete design tasks so I minimize how much I have to think about once I dive in:
An example feature from my personal Trello board
Part of the problem is that designers tend to dive into the details on a well-defined problem too soon. That’s understandable when the problem seems well-defined.
But every design problem should be treated with healthy skepticism and childlike ignorance so that you break out of your assumptions early. This will ensure that you aren’t realizing there are better ways after you’ve designed 15 screens and sent them over to development.
Secondly, ensure that you show concepts to other stakeholders to start the conversation. This will ensure that you get a better sense of what’s possible and explore any previously unimagined alternatives. Telling a PM you have an amazing idea two days before user story grooming is panic-inducing. Doing it several sprints in advance can be inspiring.
In the end, you may find there isn’t room to go nuts, but this doesn’t mean this tactic is useless. At the very worst you’ll leave with a much deeper sense of what the problem is you are actually solving (and maybe a concept you could dust off down the road).
If you know the business goals and understand what the problem truly is, then you can accurately time-box your own efforts.
As a principal, I find myself telling junior designers to do this, but there’s no reason you can’t do it yourself. I’ll walk by a designer’s screen and say something like “why are you spending so much time on that calendar, isn’t dev just using that React component?”
That said, every designer has their pet projects, both on a macro and micro-scale.
That’s fine.
But if you want to make the calendar look amazing and know that it’s effectively a self-serving activity (i.e. dev will simply be using a component), it’s helpful to time-box it. Tell yourself, “I’m going to spend 4 hours on this and whatever I end up with, I’m polishing and moving on.”
There was this self-help book I read (okay, I read the back cover) that basically said that if you eat a frog at the beginning of every day then you could more or less ensure that it’d be the worst thing you had to do (at least I imagine that’s more or less the premise).
Being aware of the details you don’t really want to do, and the things you want to do can help guide you to properly prioritizing your work.
And once you sit down to go all “Michelangelo” on that calendar UI, you can safely know that in worst-case scenario, at least you have the requirements handled. I’ll even find myself doing the “good-enough” design first as a safety net, so even if I go bold on that calendar UI, I know that I have a fail-safe.
The key is not just being a “good enough” designer but getting good at understanding your problem space so that you can scale your efforts appropriately while giving yourself room to be creative. Over time, you’ll build your judgment and good habits to help you do this sub-consciously.
When I’m not helping you present to the C-suite, I’m working on Sketch design tools at UX Power Tools to make you a better, more efficient designer.
Follow UX Power Tools on Twitter
How to Know When to Stop Designing was originally published in UX Power Tools on Medium, where people are continuing the conversation by highlighting and responding to this story.
AI-driven updates, curated by humans and hand-edited for the Prototypr community