A print button? Mmkay. Let's explore WHY you need me to add that
Come, Morlocks, and step into the world of the design Eloi
With all our attention on the Morlocks – down there with the whirring gears of Kubernetes and steaming clouds – it's easy to lose track of the Eloi: those concierges of productivity that smooth out the rough, upper crust of The Stack to make sure your software is actually usable.
The trend now is to call this layer "design", which is just fine. "UX" always seemed a bit like an X Games sport, and even the Morlocks know that "UI" is just a part of the story. Exposed bricks and pale-wood desks only go so far in seasoning good software. There's an actual methodology there as deep and sculpted as any DevOps-cum-SRE discipline.
Let me give you, my Morlock friends, a framing that – though likely shallow and far from complete – will give you a good tour guide to the surface of The Stack.
The parable of the print button
Your first encounter with "design" tends to follow a predictable flow: "UIs, amirite – how hard can it be? I just need you to add a print button to this page. Should take, like, five minutes, right? 20 tops?"
Before you can scoot off to digging into the latest, real-life BOFH accomplishment, the designer coughs, Jeeves-like. They straighten up, and step off their standing-desk mat, running their fingers through their forest green-tipped hair to smooth it out. Armed with a fresh stack of sticky notes, your designer says: "Well, first, let's explore why you need a print button."
Fear not, ye five-minute-feature fiends, this is the process working. This is the first step on the journey of software that doesn't suck (rather, in most cases, software that sucks less).
What your frosted-tip friend is driving at is the first stage of design. As Erika Hall recently riddle-listicled: "Only after you have a goal will you know what you need to know. And you have to know your question before you can choose how to answer it." The question is: why do they need a print button? Is a print button the best way to accomplish that task? Do they even need a print out?
Answering these questions gets to the bottom of what you're actually trying to do. A sort of annoying application of the five whys (are there, really, any enjoyable applications of the five whys?).
This is a good path to go down, but it can feel just like a sysadmin longbeard who, when asked how to write an awk script to break-up a CSV file, will say: "Why would you want to do that?" instead of just answering the damn question.
The sticky notes are made of people!
The next stage, "research", is where you start to discover the answers to these questions. Of course, this means first knowing exactly who these "theys" are. Your design friend might bring in a friend – all thick-rimmed bespectacled, sporting a fresh Macklemore up top – to draw up some "personas". These are profiles of your us-... ah, pardon me, that's a term that's too easy to backslide to... people.
Sagely stroking his Maestro's buttered beard, he'll sort out what the motivations, wants, and needs of these people are. Each will be given a name, and perhaps a delightful sketch or properly bokeh'd photo of people like "Pat". Does this person even have a printer? Perhaps "print" is the wrong action needed here for poor printing Pat.
As with all great small-batch questions, we should gather some actual user studies to validate our theories, or invalidate them to then come up with new theories.
A million one-way mirrors
I don't presume to know the art our well-oiled and styled design friends practice at this stage – gazing into the daily work of your software's factotums. But there is a craft – even art – to discovering the mysteries of the print button.
In recent years, all our lower-level IT has actually contributed a great deal to design research. In previous decades, the best a designer could hope for when observing users (sorry) people was using baroque, one-way mirror rooms with dozens of cameras perched to spy on people as they moused through the UI. Now, thanks to highly network-dependent apps, designers can watch every single thing every user ever does. While that might be creepy in the hands of hucksters and black-bag millennials, it's pure gold for designers.
Way back in 2009, taking advantage of this methodology a famous Microsoft study (PDF) found that only a third of the features in their software were used as intended, or used at all. Think about all that fat in the other two-thirds that could be trimmed! We expect software to constantly evolve, better fitting what's actually useful and productive for the people using it. These millions of one-way mirrors give us a sharp knife.
Small batches rule everything around me
With all this in hand, to cut a long story short, the designers iterate, small-batch style, until they systematically figure out the why and how of that print button. Perhaps it turns out that people don't actually want to print out that form, they just want to archive it somewhere: why not email instead?
This feedback loop, done weekly or even daily, is what improves modern software and is the source of much of the business value in "digital transformations".
And then we come back to you, dear Morlocks. All that work putting a release pipeline in place, a solid cloud platform, and ensuring production resilience is a huge part of what's empowering designers to do much of this.
Improving and optimising your stack wasn't just an exercise in lean efficiency and Taylorian lead time reduction. The actual goal was to improve your organisation's software. DevOps friends, this is where you can crawl out of your warrens and take a victory lap in the sun for once. Try not to eat too many designers while you're up there. ®
We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.
Sponsored: Becoming a Pragmatic Security Leader