Things

Uncle Moneybags

2020-01-27T20:47:42Z

If you spot one, it's probably because rent in Dublin is too damn high.

Is it a design system if you haven't written about it?

2020-06-13T15:20:58Z

Imagine two separate experiences – say, native mobile and web – for one product. Web leading the way, mobile playing catch-up. With a leaner feature set, a smaller user base and no legacy decisions hanging over it, this mobile experience is a playground for more focused product design, and evolved functional and perceptual patterns.

Now, imagine the process of retrofitting a mobile pattern into the web experience. It feels low effort, it's shortly before deployment and, for the purpose of this post, the form factor difference is irrelevant. It's a good idea and our customers' behaviour told us so.

I doubt this pattern would end up being archived as high fidelity pixels. I am not redrawing these rectangles unless it's with a sharpie.

A system that makes designers produce high-fidelity outputs for the sake of consistency with production is a hamster wheel. A system that prioritises consistency over evolution of approaches is probably too rigid for a small organisation with limited resources. If it's not in production, it's not the source of truth

We could down tools and count the instances of buttons. Or we could look at date pickers and wonder how the hell do we have 6 of them. Then, converge on the "new" official component to fulfil a given purpose and begin another cycle of pixel entropy.

I drew a primary and a secondary button and realised that – while their purpose made them look different – their low-level properties were in tune with properties of other elements of the interface. I defined a border colour as an rgba value and could use it again on a variety of elements to ensure visual consistency. But stopping there would be a wasted opportunity.

Once this value is defined – as border-colour-strong, perhaps? – I could treat its opacity as a point on an imaginary scale. Next, consider the hsl values of its colour and define how they change when an element was interacted with – forming a scale around :hover, :active and :disabled pseudo-classes and how an element might respond to those.

Documenting such relationships in a straightforward manner is a difficult task for today's interface design tools. Keeping the results in sync across multiple elements a lot less so, but still requiring curation. Using the underlying relationships successfully to our advantage is bound to be difficult if designers and engineers are forced to study existing pixel artefacts to find them. Building scales and constraints rather than artefacts is design work. Crafting yet another passive-aggressive message for #frontend-eng is not.

Some design companies' marketing budgets elevated "design systems" as the number one thing to do – and designers followed. Systems became passion projects for some, strategic investments for others. I'm curious how many systems are treated as internal-use products rather than static libraries. How often has a design system project been a box-ticking dopamine binge rather than an exercise in researching and addressing the system users' needs?

Is the system adopted by multi-disciplinary product teams? If not, why not? Has the time spent on UI design and build dropped significantly since adopting the system? Have the core UX metrics of our product improved where the system has been in use? How should we measure consistency of the interface? How often has a component been modified or added and has in turn impacted those metrics? How can we tell if changes to rules or components are being propagated as efficiently as possible to other parts of the system? Monitoring its performance is the difference between a design system being a passion project or a product.

When things get hectic at work, I tend to think about drawing less and designing more, and automating away the repetitive parts of my job to focus on problems larger than a pixel.

Last thing I want to deal with on a busy day is a component I need to detach from its master instance for the umpteenth time just to make it work for a particular use case and somehow still fit into the front-end puzzle.

If at its lowest level, a system is composed of individual elements rather than their basic properties, small style changes can render the entire system brittle. If those elements are archived as static pixels and treated as a source of truth, implementing such changes comes with overheads harder to prioritise or justify.

None of the issues I'm grappling with are fully solved by today's design tools, if in that category we only include the likes of Sketch, Figma or Adobe XD. But the problems we face today, imperfect tooling and a maturing discipline inform the best practices of tomorrow.

As Robin Rendle put it in his essay, Systems, Mistakes, and the Sea:

The ugly truth is that design systems work is not easy. And what works for one company does not work for another. In most cases, copying the big tech company of the week will not make a design system better at all.

Dan Eden's "Subatomic Design Systems" is a great overview of how elements within a system are compositions of low-level properties, and how the consistency of the system largely depends on those properties.

Finally, Alla Kholmatova's "Design Systems" is an amazingly accessible and thorough guide to embarking on a design system project, chock-full of both theory and practice. Reading it once is definitely not enough.

Setting up for Figma plugin development

2020-07-08T13:27:57Z

Unless you're well versed in 2020s front-end development, namely:

dealing with abandoned plugins
deciphering strange-looking, non-descriptive errors
working with dependencies you don't fully understand the purpose of

The official guide to bundling might cause some frustration.

If you are, like me, familiar with some basic Terminal commands and package installation but have always steered clear of more advanced infrastructure tasks, do yourself a favour and use the Figma Plugin React Template.

It installed and ran without errors on first try. Which, as far as my adventures with front-end engineering go, is a win that keeps me going.

🙌🏻

When Progress Feels Like Success

2020-10-01T22:55:15Z

There's a question I always liked asking other designers when talking about work.

How did you know you were making progress?

The answer was usually a description of some flavour of a design process—the difference in approaches within our field can be quite interesting. There's always something to learn or, better yet, steal to make my execution of the Unsexy Middle Bits more effective.

Then there was my favourite follow-up.

How did you know you were successful?

There was a look, a pause, and the answer, tinged with disbelief.

"We launched?"

Earlier this year, I spent a large chunk of my time interviewing product designer candidates. Screening calls feel like ticking off a checklist during an awkward first dance, so why not just chat design instead?

I asked my questions and, almost without fail, the success definition for a lot of the projects I heard about was "the launch". And a few seconds of awkward silence afterwards.

One last difficult conversation, a final round of revisions, a handover to engineering makes progress look and feel like success. Time and budgets make milestones matter more than solved problems.

I wrote the opening paragraph of this note when the lockdown first started. I stopped when I realised how much of my work doesn't have a success metric—its only outcome is a concluded contract or a closed ticket. And I realised the question I so liked isn't fair.

"What did you want to know from the customers who'd used it?"

I hope to be a user persona for a knowledge organisation tool once

2021-04-29T18:17:37Z

A colleague asked me what's my trick to collecting information I find online. Nothing he's tried so far – bookmarks, read-later services, Roam, the guilt-inducing "leave tab open so I finish" – worked. I managed to impress him for on two occasions, having had just the right bookmark to share over Slack.

That made me think about my learning methods, and how fleeting interest and distractions get in the way of exploring concepts fully. What I mean by "fully". And how none of the tools I tried, worked.

Quitting some and limiting other social networks helped with distractions.

Ring-fencing time to read every evening helped with discipline.

But I still don't know how to effectively organise my bookmarks list, or what web of connections should replace my google searches when asked about a concept I vaguely remember being interested in – consumed by – for a couple of hours a while back.

Fear-driven design

2021-11-30T23:11:35Z

Before I ever worked embedded on an Agile team with a distinctly backend focus, or served, dejected, on a product team in a sales-led org, I had the chance to practice what has to be the worst design methodology out there.

"I won't get it done on time"

Whenever I feel the pace picking up, I think through what might happen when the thing I'm working on doesn't get delivered. Jot down each piece that makes up the thing. Prioritise those pieces.

"Looks like I have enough here"

Fear-driven design tricks us into believing that all the work has to be done at the same time. It tricks us into believing that there is such a thing as "done". It strips us of the opportunity to improve.