Atomic design, sporks and existentialism

“Hmm, what shall we write about…?”

We often ask ourselves that question and come up blank. It’s not that we don’t have anything to say it’s just that after a while of regularly posting, it all starts to feel a bit forced and repetitive. Besides which, it’s not our daily job; we are UXers, not journalists.

That got us thinking “Why do we feel the need to write something in the first place?” and the scales fell from our eyes!

We write because we are excited about our profession and inspired by other people’s ideas, and we want to share our interpretation of those ideas.

We read a lot of stuff and we share some of it through conversation and via social media, so why don’t we talk about it on our website?

Over the past week, these things drew our attention and got us thinking:

Atomic design

On a recent project we were thrown back into the bad old days of  attempting sign off PSDs of screen designs that had been rendered from wireframes that we created. Worse still the designers were asked to refine the minutiae to match the wireframes, even though the UI developers had already started  building the darn thing.

We quickly realised why we outlawed this approach – because we know that wireframes and designs are not always perfect bedfellows and are never really “Finished”. They each serve a purpose at a specific stage in the process – they allow us to move our thinking forward. In our experience, truly successful projects draw on the understanding that we need to iterate and improve at ever step of the way, from conceptualisation to design and build and even after launch.

That brings us to atomic design, or at least our interpretation of it. We have found greater success in the following approach:

  • We identify the best overall user experience of something and we demonstrate what that is by delving into our usual bag of tricks (e.g. user journeys, wireframes, prototypes)
  • We work with the designers to break everything down into a series of common and repeatable components and patterns (e.g. text formatting, image layout and sizes, button styles)
  • We explain to stakeholders that we use UX methods to demonstrate how something should work ,whereas the designed components demonstrate the visual language.

All this makes the sign off process simpler and more fluid and avoids endless reworking in Photoshop.

There are still issues with this approach – if we design at component level the overall design can end up looking like a patchwork quilt – but that is something we are still pondering.

Here’s some further reading on atomic design:

Everything under one roof

We had a discussion and we agreed that we are not usually fans of things that do more than one thing. They are never as effective as the things they are combining. For example, a Spork is not better than a spoon at being a spoon and it isn’t better than fork at being a fork.

That said, Talebook has come up with something that piqued our interest – A framework that allows UXers to manage all their research in one place:

We use all manner of industry-standard tools, widgets and systems to keep track of the UX process but one tool that does the lot? We’ll see…

Life imitating bots imitating life

Finally for today, this made us smile and set us off on a bit of an existentialist philosophical journey:

Louis Theroux so impressed by a ‘Louis Theroux bot’ he recorded one for real