The industry is in flux.
Designers are out of work for months, desperately trying to understand why their applications for jobs are ghosted, maintaining databases of applications just to keep tabs on the volume of rejections, being put through rounds and rounds and rounds of interviews, and yet we’re still seeing companies continue to hire at pace.
What keeps surfacing in my industry observations, and conversations I’ve had with hiring managers, is the need for designers to demonstrate craft in their applications and portfolios.
This is great! Something actionable and at least within grasp as a learning opportunity. What trips me up though, is that I don’t think we have a collective understanding of what this actually means.
There seems to be an unwritten rule that you either “get it”, or you don’t, and there little advice from senior figures in the industry on how to develop this mysterious skill other than to just keep trying.
As someone who was previously stuck in design jobs because I couldn’t demonstrate my ability in an application – I once applied for jobs for approximately 12 months without a single interview – I feel this pain, and I think something needs to change so that others can be given a chance to demonstrate their quality.
Let’s take a look into some aspects of craft that I think are worth paying attention to.
Riff culture
Something that does come up a lot when talking to people about craft, is the importance of “riffing”. In its purest form, this means doing more designs to find a solution, but again there is no true method or science we can apply to this as a designer.
Companies often revert to activities such as Crazy 8s to try and generate more ideas on a topic, and this is all part of the design thinking™️ process, but I still don’t know whether it’s actually a useful replacement for something else – obsession and instinct.
After all, design thinking is dead isn't it?
What I believe is a risk in thinking exercises is bikeshedding – spending too much time on details that aren’t important. Are we ideating here because:
-
We are stuck
-
We have been told to
-
We don’t really know what we’re building
-
It’s actually useful for unlocking solutions
Each of points 1-3 present different challenges, but centrally we cannot replace a firm understanding of the problem with endless ideation.
I believe that this can also be trumped by an obsession for your profession and a hunger for constantly and consistently paying attention. I wrote more about this in my post Portfolios: Prioritise pixels over presentation.
I digress.
Riffing is where your artboards or canvases stretch far and wide with potential ideas on a design. This, I believe, is table stakes in how we should work. Therefore, I can’t really pull this out as a key component of craft because it’s just how it should happen.
Where riff culture does come into play, is in the presentation of our ideas and work. Onto the next section.
Presentations
Apple are (in)famous for internal presentations. Ideas require presentations, and to build great products, you need to present them. It’s worth having a look over this article for more information: This is how we make slides at Apple.
Despite this being a semi-common known, I have been surprised over the years at the correlation between well-respected software and presentation culture within design teams. For example at Figma, designers frequently attend critique sessions with their (often rough) design work presented in slide format. These slides aren’t ugly either, they are designed. This may be surprising, but in order to get your ideas shipped you must be good at communicating them.
Often the common path to this is through a presentation. I’m a big fan of Looms (my favourite tool is Tella, but at Figma we use Loom) – apparently in June I eliminated 130 meetings. A 2 minute walkthrough of something you’re thinking through can help unlock way more empathy in your ideas than a 300 word essay dropped into Slack, or worse no comms at all about what you’d like to build.
Designers want to be taken more seriously at a strategic level within an organisation, and without a strong foundation in clear and concise communication about why something is important, we will forever struggle.
Additionally, I spoke to Artom from Craft who shared a similar approach to their ways of working. Craft are known for their exceptional attention to detail, and putting a lot of effort into the communication of ideas internally is clearly paying off. I remember him distinctly mentioning that they like to "feel" designs in their hands on devices. You really cannot replicate the end product in a static mockup.
At its core, this is about telling people what they need to know in a way that enables buy in for your own plans. Dropping people into an enormous Figma file to show off your work in progress ideas will not only slow down comprehension but start everybody off from a point of incoherence. This advice applies to portfolios too!
Lastly, writing is incredibly important for buy in. Spend more time writing down your thinking in a doc before jumping right into a design tool and fleshing out your ideas. A firm brief and “here’s my thinking” doc will elevate your seniority before you’ve even presented a pixel.
Takeaways: present your ideas concisely and coherently.
What is difference, truly?
It wouldn’t be an article without a little existential crisis, would it?
What I struggle most with the craft argument is that, honestly, I believe we’re all kind of designing the same things. Aren’t we all striving to make white boxes on white boxes, some with grey borders and mostly wrapped in an 8px corner radii?
With the proliferation of common frameworks like Tailwind and shadcn, we’re saving an enormous amount of engineering time at the sacrifice of visual flair.
You know what, that might be fine?
I am challenged because any seasoned designer knows that the engineers truly have the power to decide what does or doesn’t get built, and our dreams of crafting something unique can often be squashed at the first sign of a story point higher than 5.
As a result, I feel that the dance we do around iterations and visual artistry to land a job are often left to the wayside when we are actually in seat. The popularity of design systems aids the argument of “this already exists, why make something slightly different just because you can?”. "Where's the data to support the need for this custom element?".
Mentioning same-same designs, the below image from Jem Gold in (I believe) 2017 is still true today. The original caption – unfortunately Jem deactivated their Twitter account – was “which one of the two possible websites are you currently designing?”. I don’t know about you, but this still makes me laugh 7 years later.
What exactly are we crafting as the industry merges into a cohesive blob of sameness? Am I being cynical, even for me? I do believe that flair and brand differentiation is the truest lever we can find in a world drowning in software, which actually places me in a position to believe that design systems are at risk. In a good way, trust me.
We must flex our brand and be more graphical in our approaches to design, made all the easier by the hyper powered computers we type on at the desk or carry around in our pocket – the processing power is there to try new things, not just to make more white boxes.
The hiring dance
If you read almost any job posting for a designer, you’re guaranteed to read something along the lines of “must have an appreciation and flair for typography”. This sounds lovely! We want designers to know design foundations and appreciate a balance or fonts, weights, and sizes.
What is funny here though is that in your job designing software, at almost no point in your entire software career will you be balancing multiple typefaces, sizes, and doing graphic design work. You might for promotional material outside of the software, but there's just no way you're going to introduce a new typeface for a specific flow of a design.
The likelihood is that you will be joining a team with an established set of brand fonts, in set sizes, with pre-composed styles or text components that you apply in your designs. It’s quite hard to get this wrong, so why are we placing so much emphasis on a designer’s ability to prove they are the next Erik Spiekermann?
If it’s not your first job, you’re also probably coming from the exact same situation – a design system setup with typography properties agreed on with the brand team. This feels like pseudo science to me.
What we are being judged on is our ability to organise typographic elements. Again though, if your system is setup in a logical way, it’s almost harder to get this wrong than right. A Heading style is used for headings, Body for…you guessed it.
Again, perhaps this is a me thing, but visual design in software should be dony by someone who is defining the look and interpreting the brand into a delightful experience. This is indeed craft. However, most designers are not in this position, but are benchmarked on the same qualities. Most designers are excellent thinkers, doing the Lego thing with pre-built systems that the crafty visual designers are better at working on. Is organising benchmarked at the same level of craft as the visual nuance?
Perhaps we just need to split job titles again?
Is it process?
Hello double diamond my old friend, I’ve come to hate on you again.
What I naturally look to when I hear the word craft is process. But process is a fuzzy word. What’s more, the best designers I talk to don’t read method books or stick to a rigid flow when producing great work, they just do it.
This widens into a challenging statement about what design actually is, which we may need to spend more time hovering over, but centrally great designers don’t start or stop with a job description. They contribute wider than their scope to figure out the best solution to the problem, regardless of whether it’s using paper, a canvas, some HTML, or a written document.
I don’t believe this can be process-ified, and no that’s not a word. What I do believe is that the riffing on riff is endlessly useful, but only at the point where you are clear on your goals as a team, collaborate to find the answer, and work from the point of view of a busy user just trying to get their job done.
As a slight anecdote, a few weeks ago I was working alongside the Figma dev mode team on a set of “jobs to be done” and it was hard. What’s worth noting is that this wasn’t designing per se, it was designing at large, in a cross functional team of design, engineering, data science, and advocacy.
Perhaps, yes, that does mean that we’re all designers, and we should celebrate that.