Designing with screenshots. Are you an idiot for not doing it?
A quick take on a controversial UI design practice.
Now that we are past the clickbait, yes, you're an idiot for not designing with screenshots.
But before I say why first let me explain two things. One, what's "designing with screenshots," and two, why should you be listening to me.
So first, designing with screenshots is this idea that when designing software, you can screenshot existing areas of the application and use them in your designs to create the final composition of a mockup—this instead of drawing every UI element from scratch.
And before you say, "what about designing an app UI from scratch?"...Well, sure, but let me give everyone a reality check here and say that that is almost always not the case. Also, if that’s your case, you’re a martyr because that’s a brutal daily job.
Now, who am I? I'm just a designer trying to have fun working in tech. That has taken me through many companies directly and indirectly. Some of those companies are Facebook, Amazon, Gitlab, Procore, and a handful of startups and mid-sized tech companies.
So all this to say, I've been around trying to grow my tech career. And for better or for worse, I think that I have developed a good sense of what works and what doesn't. Or, in other words, I'm showing you my credentials, so you don't think I'm another idiot.
Ok, now that that's out of the way, let's return to what I wanted to share today, which is that you're an idiot for drawing all those shapes or using your company's broken component system in Figma.
So in classic BuzzFeed fashion, here are five reasons why you're an idiot for not designing with screenshots:
1) Because it makes you faster
Ok, so this one is obvious, but I don't think people understand how much faster you can be if you design with screenshots. Let's assume that you are designing a web app, and you need to create a view with a sidebar. Your component library has it, but you need to customize a bunch of shit to make it look the way you need it to look.
But there's also an implemented sidebar in the actual browser app that looks the exact way, and it's in the same state you need it.
So what do you do? You drop the component, detach it and change all the stuff you need to change? Or you screenshot the real one and drop it on your frame?
If you're doing the first one, then you're clearly an idiot. Both mechanisms will give you the exact visual representation of what you need. Only that one is way faster than the other one.
2) Because nobody cares about images in your designs
Ok. So you're a design purist, and you want to satiate your OCD tendencies with perfect designs drawn 100% from shapes. Well, you're an idiot. You're just working harder, not smarter.
The reality is that nobody cares about images in designs because nobody cares about hand-off practices—only designers and developers working on design systems, working on refining already high-caliber consumer experiences, or companies with outsourced teams. The rest of us are just trying to ship some shit.
Also, if you know what you're doing, your designs will be as pixel-perfect, if not more, than your hand-drawn and dragged designs.
I must confess that I used to worry about how it will reflect on my work if someone decided to inspect all my mocks and found many stitched images and shitty mockup makeup. But I grew on my career and found out that people were not even remotely concerned about this. It's far more critical to have the ability to create visions and set strategic directions through your designs than it is to have tidy Figma files.
3) Because it helps you understand and keep design precedent in your designs.
Your app is not perfect. Just admit it. There's more tiny nuance in the products we help design than we like to admit. This impacts the way you design any app, from growing particular areas of the UI to adding new features in existing views.
Designing from screenshots allows you to understand UI nuances that are only clear when working with a screenshot as a starter. It enables you to make design decisions that are based on the existing implementation.
But more importantly, it helps you focus on precisely the areas of the UI you're trying to change—no need to redesign what's already implemented when you have no plans to touch it at all. If you're doing that, you don't value your time.
4) Because it's another tool under your belt
Look, before I give the wrong impression and make you think I'm just a guy screenshotting UIs and cropping screenshots all day, let me say that I spend a lot of time designing UIs with actual library components and shapes.
Sometimes I do have existing designs using components that are better starters than a screenshot.
Other times I need to design a completely new view, or sometimes there are no decent design precedents to use as a starter.
There are also rare occasions where I need to design something that requires a formal design hand-off with specs and a pixel-perfect design.
What I'm trying to say is that just because you're good at composing new UIs from screenshots doesn't mean that you're not good at designing from scratch. It's just intelligent to use each tool for different needs.
5) Because being a great designer has nothing to do with being great at drawing shapes
Many junior designers and industry newcomers fail to understand that creating UI mockups and UX narratives is just a tool of the job. Not the job. Your job is to collaborate with cross-functional partners to develop a product that fulfills your customers' needs. Your job is to set a strategic direction of what should matter for your product's user experience to be successful. Your job is to enable alignment and discussion by creating artifacts that allow people to imagine a future.
Of course, you need to be a great hands-on designer to be successful at your job. Just because you can produce a design artifact faster using screenshots doesn't mean that you can't let go of your intentionality and design excellence. The idea is that you can achieve those things with fewer steps and less effort.
Designing from a screenshot can sometimes help you deliver more value at a faster rate. High output designers are very valuable, and it's surprisingly easy to become one if you work intelligently.
There you have it. Now you can tell me why I am wrong.
But jokes aside, please let me know what you think on Twitter @whoisjuan.
I have had the opportunity to build a career by integrating this tool into my repertoire of design tools. My sincere take is that many people should consider it if they work in highly iterative, fast-paced, and collaborative environments. Of course, there are situations in which this tool is not a good approach, but part of being good at designing with screenshots is to identify when it is a good idea and when it is not.
What happens when there is a significant change to the components? IE: The header is now blue vs white. Then you're going to need to go back and update every screenshot to reflect that change rather than a simple update through the library. I have experienced designers who work with screenshots and the files are large, theres inconsistencies, and it makes it a pain to update any new UI standards.
Designing with screenshots might be an obvious choice for some but you really drove the point home :D