By Sam McCormick, 3 December 2019
Eight of us crowd into the lounge of our Pyrmont office in Sydney Australia - four on a sofa, three on straight backed chairs and one standing. Albert Harum-Alvarez of SmallCo occupies the hot-seat from which to dispense his wisdom. Outside the sparkling waters of the harbour suggest a serenity that’s buffeted and bullied by the sounds of the inner-city streetscape…
The imagery of Albert’s slides take us literally half a world away as his metaphors, analogies and anecdotes gently tease and cajole us away from the structured rigour of pragmatic software. He wants us to find the 'who' of the application, not just the 'what' or the 'how'. Define the character of your software and stay true to it throughout he tells us.
When someone says design we think colour theory, the rule of thirds, the golden ratio, proximity, grouping and alignment. All of these rate a mention as respected fundamentals, but there is a perspective that Albert wants us to grasp - a way of feeling, seeing and thinking about our software.
We are to ask the question –
Is my app an extension of the user?
I’m reminded of Haptic Perception, the blurring of the line between body and tool as our proprioception encompasses the tool itself. Imagine a tennis racket, it’s not our sight that assures us that it will connect with the ball - it’s our understanding of the space it occupies in the world as an extension of ourself.
Designers of smart devices acknowledge this with Haptic Touch providing sensory feedback - the artificial click in response to pressure as reassuring as the impact of the tennis ball felt through the racket grip.
Is the App a comfortable tool that fits the contours of the user’s mind as the ergonomic grip of Albert’s Makita Sander fits the contours of his hand? Is it an extension of self that expands my capacity to remember, anticipate and communicate?
Does it in fact augment my abilities to super power status as spider venom did for Peter Parker? How else can I describe summoning a vehicle to take me anywhere I should desire with a flurry of gestures over glass?
Or is it my Sidekick? A helpful friend, a Copilot, a Navigator, or a Streetwise Buddy who gives me an edge in tricky situations?
Perhaps I’m the sidekick - the App is my mentor, my teacher, my trusted adviser- guiding me towards mastery of a skill.
If we think of our apps in these terms a sense of character can emerge that we can nurture and cultivate as we develop. If we stay true to this and inhabit the app as a writer inhabits their protagonist, we can intuitively identify the jarring out of character moments.
Albert didn’t use the term, but frictionless is a notion that I inferred. Imagine tools so ergonomic to the body and mind, so effortless, you barely notice they are there.
And here’s the rub, the ego of a healthy human doesn’t gain sustenance from unnoticed achievements. We want our effort, our cleverness, our anticipation of the user’s needs to be noticed and admired.
Albert’s example was a [Compose Message…] button presenting all of the wonderful ways he and his team had achieved to send a message: “How would you like to send your message?” the app asked helpfully. But this is not the question that responds to the users immediate need. As unexciting as it is, what they need right now is an empty text field with a flashing cursor.
Another ideal Albert asked us to pursue was that of less is more. Why is that element on the screen? What is the user doing here? At this point, do they need to see that data? Then why is it there? WHY IS IT THERE?
He drove towards single purpose layouts, insisting that ONLY the data and controls required for that purpose be present. This implies carefully orchestrated workflows rather than Swiss army knife single views where everything is possible.
I’m not sure about you, but I’ve always thought of a portal as a table. It’s a way of presenting information, if the user wants to see more information there’s a helpful button that will take them to a detailed view. Albert sees them as lists. There are a number of types of lists (roster, log, ledger, punch list, cart or bunch) and a list shouldn’t try to be a type that it is not.
Hang on, let me qualify roster - I think of a work schedule for employees, but Albert uses the term as a collection of items to choose from …a roster’s sole purpose then, is to present key data points that will allow the user to recognise the record they want to view.
Albert’s got another analogy for us - “You don’t recognise a person by their elbow, so don’t show a picture of their elbow, put their face on the screen”. He’s telling us to chunk together key data-points to build a face for the record. And to give the face character, in fact make it a caricature.
If it were a human caricature it would have big eyes, but in this case exaggerate the data-points that the user will instantly recognise, often the Vernacular ID. Love that term - Albert introduced me to it, the handle by which the people in the workplace refer to that entity in their day to day conversations.
Reflect on the hierarchy of tools and techniques that we have. FileMaker gives us fields, and buttons and shapes and portals… and so on. These are the raw materials. Then we have the first layer of design abstraction: alignment, positioning, colour signifiers. At the next layer we diverge into an aesthetic stream with the rule of thirds and the golden ratio; and a usability stream with techniques such as grouping and proximity of elements. Albert’s master class extends the latter — he is teaching us to design for intent, for purpose, for use case. Fit the data and the design to the purpose of the app, and to facilitate the intent of the user.