It's common during the handoff process to provide screens to our engineering teammates by "throwing designs over the fence"
We've all been there!
This puts pressure on devs to play a game of spot the difference, finding minor changes between screens 🔎
We can simplify this 📣
The red circles are the true differences, sooooo why are we duplicating *everything* from each screen?
This is inefficient from both sides:
– Designer must track identical screens, with changes doubled* every time there's a modification
– Developer is playing spot the difference
Let's remove duplicate screens!
Instead, we can show *component* differences alongside the main screen
Then group them with a section & use component labels to describe the differences
The developers then just need to look at one template, and read the component differences 🪄
Let's look for a practical example
Here's the Target product listing page, sliced up to show the delivery toggle options
The more I talk to hiring managers and senior designers about what they are looking for in designers, the more I back up the theory that portfolios shouldn't be X, Y, Z case studies, but explorations of your obsession with details
Showing deep, deep examinations of your solutions AND what you didn't deliver is a really great way to show how you approach solving a problem
A slideshow of solutions doesn't show anything below the surface, just a public-facing polished mockup
But jumping incredibly deep into your rough work can show that you really do take the end to end product process into consideration when solving a problem
"this didn't work, because..." is a fascinating discussion that I know would be way more interesting than "here's a flow"
Been asked a lot over the past few days about how to get started with colour variables, so here are some pointers 🖍️
Hope this is useful!
As usual, before we get started here are some T&Cs:
• These are my opinions, take with a grain of salt!
• You will need more or less of these options, adjust to your team's workflow
• Tokens are opinionated, bring your microphone
• Tokens are angry, enter with care
The types I'll discuss are:
1️⃣ Bg = Background
2️⃣ Text = Text!
3️⃣ Border = Also known as strokes
4️⃣ Icon = This is a layer I'm personally adding on, will explain why
Let's take a look at the four types of colour styles you might build / encounter in your systems 🎨
• Raw values e.g. #CC8700
• Base tokens e.g. Yellow/400
• Global tokens e.g. Warning/Primary
• Component tokens e.g. Alert/Warning/Text
The last layer (component tokens) may be overkill for your needs, and you might not need to get that specific!
The "levels of abstraction" are down to how sophisticated your system might be, and you may not even need...any of the last three if you're okay with raw values😄
The way I have structured this, with the arrow inheritance, should indicate that you follow a path down from abstract raw value down to specific component token value
Each level introduces control – providing the systems team with a much stricter way of managing styles