Apr 2023
At the beginning of 2017 I said I’d share so-called ‘nuggets of wisdom’ on Twitter if people faved the tweet, and then people went and faved the dang tweet and I had to think of smart things to say. Six years later(!!!), do these wisdom nuggets hold up to scrutiny (and six more years of experience)? Let’s find out together.
1. It’s easy to say “learn the concepts, not the tools”, but tools (esp. for beginners!) are a gateway to concepts. Important to learn both.
This still seems reasonable to me. Telling would-be designers “Learn about grids!” (or whatever) is reasonable in the abstract, but if you don’t know what to do with that information (or how grids even work in your software of choice) knowing about them isn’t super helpful. Basic software literacy is a requisite to do the job.
2. That said, design concepts are timeless. Learn grids, hierarchy, typography and you’re 90% of the way there.
Design rules are design rules because they work. Like most things, you can break them when you know what you’re doing, and even then, you’re probably not the next David Carson. (Note: also learn design history! If you don’t know who David Carson is, you’re about to learn something and/or get really mad at David Carson.) Counterpoint: a lot of design advice that pertains specifically to software design is, like, the unfounded opinion of some dude who worked at Facebook in the early 2000s and we all just ran with it. Read up, but be thoughtful.
3. Desktop, mobile, tablet, native, (VR?) are all their own animals. Designing across multiple platforms: think design language and ‘brand cues’.
Still good advice in broad strokes, but honestly every platform has its idiosyncrasies. If I were to rephrase this nugget for my current level of wisdom, I might say “Desktop, mobile, tablet et cetera are all similar until they suddenly aren’t. Learn which patterns work universally and which are unique to their own ecosystem.” Bottom line: if you’re delivering software to a specific channel, make sure you’re well-versed in the niceties of that channel.
4. Product design allows the luxury of ongoing, iterative launches. That’s no excuse to ship stuff that’s not as good as you can make it.
Hmmm. Ask a product designer when they last launched a v2 of any feature. The answer is often “never”, so while iterative design is a thing, the latter half of this piece of advice is more critical than ever. You may never have the chance to revisit your work, so make sure you’re shipping stuff that you’re proud of.
5. If your releases aren’t as good as you’d like, maybe your bites are too big. Slow down, be more considerate. Ship smaller, better stuff.
True. Go slow to go fast. Thoughtful product orgs understand this, but also (especially as you attain seniority) you should help to guide your colleagues/team toward making better, smaller things. A truly polished experience that does one thing well will (generally) beat the pants off a sloppy do-more-things experience.
6. Roadmaps are great, but totally invisible to the end user. Users/clients can only respond to what you actually shipped.
Extremely true. In fact, lots of roadmaps are invisible even to the people shipping the stuff on the damn roadmap. They’re educated guesses about what you’re going to build, at best. Startups move sufficiently quickly that planning more than a couple quarters ahead is kinda just gambling on what you think you’ll need two quarters from now.
7. Sometimes you just need to make something to work creative muscles or escape a rut. It doesn’t need to be good, or smart, or public.
Yes! Make weird stuff and show it to people. (Or, and this is a valid option too: make weird stuff that’s just for you.)
8. Share early/often, enthusiastically incorporate new ideas. There’s no such thing as a perfect design or a designer who’s always right.
FACTS.
9. Sometimes you’ll be inclined to include something funny/fun, even in the most staid business apps. Sometimes you should actually do it.
Emphatically yes, can we get more apps that have little jokes and easter eggs in them? Design for almost everything you’ll interact with day to day is so, SO dry and tedious. When I worked at Wealthsimple we included a little coin you could spin with your finger in the mobile app. Why? Because: spinny coin goes whrrrrrrrrrr.
10. Sketch is good. Photoshop is good. _____ is good. As long as your design solves the problem, it doesn’t matter how you got there.
I mean okay this is true in theory, but honestly everyone’s on Figma now and you should be too. It does matter how you got there if you’re throwing up roadblocks for everyone else trying to get there too. Also: lol that apparently I thought it was acceptable to be using Photoshop for product design in twenty-goshdarn-seventeen.
11. Language is UI. Writing more expressively → communicating more clearly → better designer.
This is one of my core beliefs about the true job of design, which is communicating. Writing clearly and succinctly is more important than ever, especially as our products are increasingly saturated with LLM-type interactions. People using the things you designed need to understand what they can do and what they should do.
12. Ask for help. At any stage of your career there are willing and available advisors – find them. You don’t have to do it all by yourself.
This is actually hard and gets harder the more senior you are. I have people whose opinions I trust, but I call them ‘friends’ more than ‘advisors’. Maybe advisors are just friends that you pay? Anyway: while it’s true that you don’t have to do it all by yourself (far from it – building stuff is by necessity a team sport), an addendum: if you are asking for help, make specific asks.
“Can you be my mentor” – I dunno dude, can I? What does this even mean to you?
“Can you give me 30 minutes for specific feedback on some work I’m doing on a fintech product?” – Yes, of course.
13. Being a designer is essentially getting paid to be opinionated. Cultivate good opinions by absorbing current and historical design.
See my note about David Carson above; but also broaden your horizons. Broader! BROADER! The most interesting product design is happening in video games (imo) and if you’re just looking at quote-unquote products, you’re missing out.
Also: I think it’s a mischaracterization to say that designers are paid to be opinionated. Designers are paid to be predictable, which is a function of having strong opinions about how software should work, but isn’t the only factor. Suffice to say: learn why the things you like are likeable, understand the decisions that went into “good” design.
14. Be curious about every form of design. You’ll (probably) never need to engineer a bridge, but you can still appreciate the principles.
I just said that video games rule. Lots of other things rule, too. Be voraciously curious.
15. There are almost always constraints on the work you’re doing (time, budget, tech, etc.). Learn them and work gracefully within them.
Correct, this is part of being a professional designer. Design without constraints isn't design.
16. Don’t waste time reinventing the wheel, especially when the existing wheel works perfectly well.
I jokingly linked to my tweet about Javascript scrolling (hot tip: DON’T YOU DARE) but you know what? Go right ahead and reinvent the wheel. Sometimes the Wheel Classic™ we all know and love isn’t actually that great. If nobody reinvented the wheel we’d never have fun stuff like pull-to-refresh. It’s impossible to know if the wheel is actually good without reinventing it.
Counterpoint: the wheel slaps. Don’t reinvent for the sake of reinventing.
17. It’s fine to just be really good at basically one thing. Both you and the jack-of-all-trades designer have a role.
Yes, but this is less true than it was six years ago. Design output is being commodified, and the number of things where you can be good at one thing is diminishing. Being very good at, say, 3D work or motion graphics is still a singular pursuit. If you’re doing anything else, maybe you should be worried.
18. Always name your layers.
If I see one more Rectangle 1571 I’m going to lose it. NAME. YOUR. LAYERS.
19. Design isn’t art. Don’t pour yourself into the end product – it’s not *for you*.
This point is in tension with #9 above. The older more experienced I get, the more I think it’s impossible not to leave your fingerprints all over your work, intentionally or otherwise.
I don’t have a style but I do have an approach, which probably yields pretty consistently Tom-flavoured artifacts. While the end product isn’t for you, know that it’ll be shaped by your thinking and either guard against that or lean into it. Sometimes stamping yourself into the work is what people are paying for.
20. A lot of the job isn’t ‘making stuff’, it’s ‘making sure you’re making the right stuff’.
I don’t think we can always know if we’re making the right stuff until it’s out there in the world. Can we have a well-informed opinion on the general shape of the right stuff? Absolutely. (This is often the job of researchers, the unsung heroes of product.) Can we know with 100% certainty that we are making the right stuff? In my experience: never.
21. It’s valuable to learn enough about development to understand where the tripwires are.
Yes, but also: no. Quite possibly more ‘no’ than in 2017. Development has come a long way even in six years. There’s very little that you might design that can’t be built, somehow. More often it’s the budget or bandwidth constraints that dictate what you can do, rather than the tech.
I haven’t used my meager development skills in a professional capacity in more than 10 years and I doubt I will for the rest of my career. Even back in the mists of time (2017) when I wrote this, folks who were both great designers and great developers were rare unicorns. I honestly don’t think it’s worthwhile to try to be both. (Open to being wrong here.)
22. We talk about ‘content strategy’ but not ’emotional strategy’. Are we making work that feels approachable? Trustworthy? Friendly?
I have no idea what I was trying to say here, content strategy encompasses ’emotional strategy’. I dare you to write content without emotion. Impossible.
23. Having a defined brand / design system still allows for a lot of exploration and evolution. E.g.: Lamborghini over the past 30 years.
You’re not Lamborghini. You don’t have 30 years of history to pull from. Everybody knows what a Lamborghini looks like (very fast triangle), there is no objectively correct take on what an app should look like. I think my point here stands (use design systems! Please!) but I could have picked a better example.
24. Screens are 2D, but you can use spatial organization and ‘depth’ to signal context, relationships, function.
Yeah dude that’s called design
25. UI elements with different psychological weight (e.g. link vs. button) indicate not just what a user can do, but what they should do.
Yes, and the trick here is to use these context cues consistently. I’ll reiterate this because I think it’s important: if everything has the same weight, there are no guideposts to help users understand what they are supposed to be doing – you need to build a path for them.
26. Designing for a specific device? Look at your work on the device (because otherwise you’re going to make scale mistakes).
True. But also: there are like three iPhones and about six trillion Android devices. Test your work on the most popular ones and call it a day.
27. If a UI can’t be explained with a shitty marker sketch, it likely won’t be so hot at high fidelity, either.
Yes! But/and! Your shitty marker sketch captures only the big shape. There’s still a lot of work to do.
28. Reality is where mockups go to die. Strive for flexible good looks everywhere, not 1:1 pixel perfection at an exact size.
I submit that ‘pixel perfection’ was already dead in 2017. Everybody here in 2023 has high-DPI screens and everything looks pretty good everywhere. I mean, sweat the small stuff (polish matters) but pixel fitting is not really something you need to worry about any more.
29. You can’t ever, ever design without bias. Try, at least, to acknowledge the assumptions you’re making.
This is as true now as it’s ever been. Probably quite a bit more, given that, as an industry, we’re just going right ahead and encoding our biases into software and distributing those biases in new and interesting ways.
Acknowledging your assumptions is one thing, strongly considering the possible harm your work could do is the new bar. Tbh we’d be in a better spot if building software required the same pledge that Canadian engineers take.
30. We were all newbies once. Even if it’s just grabbing a coffee with a student, that access and advice is more valuable than you know.
Still true. Feels like the industry is more fractured and significantly harder to get into than it was when I started. If you’re a newb reading this and would like some of my time, get at me.