For most users, interface IS the product
Alas, designers are no exception.
What you see is all there is
When you approach the coast of Long Beach, California, from the water, four small islands rise from the harbour. The scene looks like from a postcard - palm trees, waterfalls, pastel towers that glow at night. A resort, maybe. Or a private retreat.
They are, in fact, oil wells. Hundreds of them. Beneath the waterfalls and facades, drilling rigs pump thousands of barrels every day. The THUMS islands are the only decorated oil islands in the USA, taking the scale of such camouflage to the next level[1].
What you see is all there is.[2].
We judge objects and scenes by their appearance. We jump to conclusions on the basis of limited evidence. Just as the uninformed observer would perceive the Thums islands, the same applies for digital products.
Out of sight, out of mind
We overestimate our ability to percept things. Our perception is limited, especially under high cognitive load, stress or fatigue.
What we percieve is what we think it's important. What we don't percieve, we forget very soon[3]. This heuristic is easier to remember as "Out of sight, out of mind". It is a simple yet powerful and often neglected design principle.
Consider the hamburger menu: it emerged in the dawn of the mobile era. Once users became familiar with the three-line icon, the designers began adding more and more items into it. The assumption was that users would find everything they needed in the menu while saving valuable screen space. But the big downside to this approach was increased complexity due to users' limited memory: this new interface element raised interaction cost while hurting discoverability.
Soon after the hamburger menu became mainstream, the follow-up studies proved that it damaged the user experience. Users struggled to find categories hidden inside navigation[4] and task completion slowed and discoverability dropped significantly[5]. The simple rule "Obvious always wins" [6] proved itself once again.
How interface became the product
Users don't know that Nintendo is a computer. They don't need to know and don't want to know[7].
Users perceive the product primarily by its appearance. What is there, it's there. The average user do not think about our scalable cloud computing, fancy neural networks, terabytes of storage or number of cores. They care about what they see. They want results and convenience and the perception that the task is easily accomplished. So the product should deliver the perception they easily accomplished the task.
For the user, interface IS the product.[8]. Users assess the product by its aesthetics and responsiveness. They also compare it to what they saw in competitors' products.
The average user want to get things done as quickly as possible and move on with their life. They do not want to mess with interfaces, buttons, settings, cables, screens, clutches. They are not interested what is under the hood.
For all these reasons, being a good designer was long synonymous with creating good-looking interfaces that abstracted away the inner workings of the system.
Like putting an Armani suit on Attila the Hun, interface design only tells how to dress up an existing behavior [9].
Many aspiring designers focus on output when designing, instead of understanding. They put less effort on analyzing the business, questioning the assumptions, investigating the problem they are solving, or learning about the target audience. Go, go, go, turn to your favorite design tool or code generator. Start making, draw rectangles - this is what they do. Designers love the romance of the medium.
Why designing only the interface isn't enough
Unfortunately, designing nice-looking, highly-polished interfaces does not guarantee successful product. Here is a real-life story:
In a product team, the designers worked meticulously on a perfect-looking interface. They put up a gorgeous façade on the product, announced that they were done and handed it over to the development team. The developers shipped the demo. A client liked it and decided to buy the software.
Soon after the initial excitement, the client's needs and expectations evolved; they started doing "real work" and dive into more complex flows. But when faced with the complexity, the product got messy, difficult to understand, confusing, acting inadequately and in unexpected ways.
As the users knew only the interface, they could not intervene. Limited to interacting with the surface only, they could not do much beyond clicking the various options and changing settings. The product did not exposed its inner state, leaving users uninformed.
Finally, users gave up, disappointed and frustrated. To make the matter worse, they blamed themselves for being incompetent, for not knowing how to operate the product. The client soon canceled the contract because the vendor failed to fulfill the required items.
The repeating issue demonstrated here is: designers were focused on the superficial, rather than on sense-making. The product that offers only good-looking interface may initially delight users. That is good enough for casual games, entertainment apps and other low-profile digital products. But complex products such as banking apps, healthcare platforms and engineering tools require deliberate design process, that goes beyond appearance.
Shipping is easy; learning is hard.
And why are designers so fixated on producing artifacts? Combine the "always ship" mantra popularized by trendy design frameworks with generative technologies that can produce any design from a single prompt, and here we are: in a world where the interface is the product, but with questionable value.
This is one of the reasons why today we have so many failed products. They are shipped without understanding of users' mental models, their intentions, their goals, their contexts of use, their workflows. The user is stuck with a half-baked artefact.
A typical dialogue between business person and the product designer goes like this:
-Can you produce [X] for [Y]? And when we will have a deliverable, please...? -Yes! ...(typing the prompt into a generative tool)... Here it is!
So the business stakeholders, who actually dictate the product pipeline, rationalize like this: The more deliverables -> The more value -> The better ROI. An output goal is easier to measure than a value goal.
What is visible is appreciated; what is invisible gets neglected. As making visible stuff got easier using generative tools, the focus switched from understanding to making; from hard-to-measure, non-commoditised research to familiar output-focused workflows and pipelines. All of this under the excuse of "making the design process more efficient". Output conquers understanding[10].
The problem with iceberg analogy
An iceberg is often used as a metaphor for digital products. Below the surface lies the invisible work, such as preparation and research, representing majority of the work; above the surface are the artefacts - the product manifestation.
Unfortunately, in the modern design process the iceberg has been inverted. Too little time is invested preparing and understanding the needs and benefits of the user and the business; most of the time designer spend polishing the artefacts. The overarching premise from the designers side is "we will get the value from the feedback".
But once users lose confidence in the product they will just leave, making the feedback loop disappear. The opportunity is wasted, and there is no second chance.
Design begins with questions; artefacts emerge from answers
Without proper preparation designers lack insights for problems to solve; they design impulsively and by their gut instinct. They speculate about how the product should work.
Design without understanding is guessing.
After learning the hard way that the interface is not the product, designers need to update their design process. So the main change is to revert from compulsive making to understanding.
But business stakeholders see the preparation for design as "excess work". It's often underrated and neglected, as we saw earlier. Designers need to create room to prove its value.
To make the transition smoother, lets' begin with two simple questions[11]:
- What are we trying to achieve? Defining the opportunity and discussing user and business benefit
- How will the artefact help us reach that? Measure ideas against it, in a candid way[12]
Every stakeholder should answer those questions. This will start the inquiry about real user needs and business concerns[13]. Once the team collected the responses, the designers can start their work, prioritizing what to work on first and making design decisions.
The end result is an artifact - a document of design decisions[14]. It is derived from "invisible work". The artefact is the product interface; it can be not only visual, but also auditory, tactile or gestural.
Conceptual fidelity
Traditional design process advocates to start with low-fidelity wireframes, to produce many testable iterations and to end with high-fidelity prototypes. But neither one of those fidelities is complete; they do not capture the thinking behind the artifact. This is because they are visual.
There is another type of non-visual fidelity that complements them: conceptual fidelity. It represents how honestly a solution matches the understanding of the problem, including where that understanding stops. When conceptual fidelity is high, the artefact faithfully represents all design decisions, even the ones that are rejected.
A product with high visual fidelity but poor conceptual fidelity is badly designed. It is a high-polished artefact without proper understanding of the user needs and business opportunity, that documents decisions that were never made. It will most likely fail. And it's hard to predict when. The polish hides the emptiness.
Delivering value beyond the surface
The users will not change; they will continue to judge products by its surface. But the real test comes with long-term, everyday use. When the initial hype is gone, will they keep using it or abandon it?
We might need to take a little step back and reflect on what we need and what we want and how we want it to be. Delivering value is not easy. Delivering value securely is harder. Delivering value user friendly and securely is even harder. Let’s take time to plan, architect and deliver value.[15]
Good research finds out about user needs, behaviors and pain points before anything else. This is not easy. It's time-consuming, and expensive. To inexperienced observer, it's "inefficient". Designers try to replace it with automated "summary" as a "draft research" that they will "comeback later" when they "have time". Guess what? That never happen. The research is replaced by machine-generated guessing.
Get the foundations right. Get the "why" behind design by doing just enough research[16]. Don't guess. When you achieve the desired level of clarity, all of the sudden the interface will become self-explainable, natural, obvious. Even boring, but high-quality. Then it's easy to produce first-class, highly-polished interface.
So, as a designer, don’t stop at making your product look like the THUMS Islands. Surface-level design will only get you so far.
The 99% invisible city, Roman Mars ↩︎
Thinking Fast and slow, Kanehman and Tversky. This punchline has been very influential. ↩︎
Humans can remember 5 to 7 items in short term memory ↩︎
https://baymard.com/mcommerce-usability/benchmark/mobile-page-types/navigation-menu ↩︎
Don Norman, Why interfaces don't work ↩︎
The original quote: "As far as the customer is concerned, the interface is the product" - Jef Raskin, The humane interface ↩︎
Alan Cooper, The Inmates Are Running the Asylum ↩︎
Focusing on design outputs without understanding is a wrong way to design and leads to bad outcomes ↩︎
The other variant was proposed by Nathan Beck: Design is the conscious coupling of how and why, two childlike interrogatives so seemingly simple when written down, yet so seldom asked. So shallowly explored. ↩︎
In an ideal world, product does not exist - only desirable outcomes exist ↩︎
Or: business consequences. ↩︎
Articulating design decisions is a key skill when working with ALL stakeholders ↩︎
I highly recommend the book by Erica Hall ↩︎