Evergreen Design

Humans slowly change, and that is our chance

2026-11-06T00:00:00Z

Returning to human universals as a primary source of truth in design.

How ergonomics came to be

A doctor performs delicate surgery on a patient with a serious head wound. He sits with his feet elevated, elbows resting on his knees, calm and focused on a demanding task. His apparatus in the operating room is arranged in an orderly manner; all assistants move in a choreographed way, following written rules.

The year is 380BC^[1]; the doctor in question is no other than Hippocrates himself - the physician best known for the Hippocratic Oath.

Hippocrates was the most famous physician of the ancient world. He observed and analyzed surgical procedures and set out his findings in a treatise: how the surgeon should sit, where the light should fall, how the instruments should be arranged and how the attendants should behave during the operation^[2].

Hippocrates' "On Surgery" is one of the earliest documented examples of what we now call ergonomics. It recognizes enduring patterns in human behaviour, laying the foundation for evergreen design principles that stand the test of time.

Human universals in contrast with technology

The treatise sets out practical rules for how a surgeon should work; those rules that rest on the needs of the human body. When you read it today, it’s surprisingly accurate and logical: “the part that is operated upon should be opposite the light” is as relevant now as it was 2,500 years ago. This is because Hippocrates and his followers unknowingly relied on fixed human universals. It takes humans thousands of generations to evolve a new cognitive trait. Humans evolve slowly.

But modern technology changes at a completely different pace. Within a single human generation, it evolves to unprecedented levels while existing systems age fast and become obsolete within a short period of time. For the reason of longevity and usability, contemporary design discipline advises technology to adjust to people; yet in practice it is usually people who adapt to technology.

The main reasons for this imbalance are conflicting incentives. It's easier and cheaper to design generic products with mediocre interfaces while relying on users' ability to learn and adapt. The cost of bad design falls on the users; they pay with their time and frustration. In a business world where speed beats usability, customers are left with subpar products.

Evergreen design is here to stay - time to put humans first

Despite this destructive trend in modern design, evergreen products still exist: as objects (the chair, the bicycle, the violin), as methods (writing, double-entry bookkeeping), and as software (the spreadsheet, Unix operating system).

What they all have in common is that they are tech-agnostic (not tied to a particular technology) and human-oriented (inspired by human universals, then modeled on permanent human activities).

This motto was written at the time when humans were euphoric about technological progress:

Science Finds,
Industry Applies
Man Conforms

Motto of the 1933 Chicago World's Fair

We can do better as a society that understands the value of putting people before technology. In a world where products are designed around technology, treating humans as a 2nd class citizen, it's time to reconsider the first principles.

Here is a contemporary design motto, rewritten by design doyen Donald Norman, which brings us back to the fundamentals for human-centered design:

People Propose,
Science Studies,
Technology Conforms

A person-centered motto for the twenty-first century^[3]

If Hippocrates recognized 2,500 years ago that human qualities would stand the test of time, why should we forget it today?

This is a fictional story, however based on real historical facts and documents ↩︎
Source: The history of ergonomics ↩︎
Don Norman, "Things that make us smart" ↩︎

Just in time help: often neglected, always useful

2026-10-28T00:00:00Z

On tractors and software: how one tiny UI element connects them

The unexpected occurrence of JIT help

You can see a tractor in almost every village yard in Central Serbia. It was a universal vehicle and a part of ordinary life while I was growing up. I learned to drive it when I was still a kid. What always gave me trouble, though, was the cold-start procedure: this odd, finicky ritual I could never seem to remember when I needed it. It is so awkwardly different from the standard ignition routine that I thought there might be some hidden computer inside the machine, sabotaging me every time when I tried to do a cold start.

Detail of tractor plate

Thankfully, some clever designer of the tractor interface noticed this problem and offered an elegant solution: a small plate next to the keyhole where step-by-step ignition instructions are written. It was simple yet ingenious: the driver did not need to carry the tractor manual and scroll through it (usually under hard working conditions) - only to recall this complicated procedure. Just to remember, this was designed more than 50 years ago.

This kind of aid is called "Just in time help". It is revealed exactly when it's needed, at the right place^[1]. In the tractor example, the instruction plate is tucked away so it doesn't obstruct, yet it's there to remind the driver when needed.

JIT in software

Software designers recognized the potential of JIT help in the early days of computing and quickly adopted it. With the computer screen as a dynamic medium, it is easy to program the system to show helpful messages exactly where and when needed. The users loved this novel form of aid: the software became more user-friendly, offering contextual help only when relevant and disappearing otherwise.

The first JIT help interface that I remember was from DOS word processors and IDE^[2] compilers in the 90s. It was designed as a bar in the footer menu, showing available commands that could be recalled using function keys. Another practical example of JIT help was manifested when using main menu commands: one letter in each menu label was rendered differently, indicating that the command could be quickly invoked by pressing that key.

My first compiler; notice the JIT help labels and colored letters that assist in keyboard shortcuts

In contemporary interfaces, JIT help is the most commonly presented through tooltips and form validation messages. Another useful interface pattern, originally invented in bookkeeping software and popularized by search engines - is autosuggest: while the user is typing a question, the system suggests related entries, enabling them better formulate what they want to ask, or to simply choose one of the entries from the list.

JIT reduces cognitive load

Why users love JIT help? One of the answers comes from Don Norman, a prominent expert in the area of user experience design:

The power of unaided mind is highly overrated (...) The real powers come from devising external aids that enhance cognitive abilities.^[3]

JIT help almost screams to user: "Look here, I will help you; you don't need a manual". It is demonstrated through user research that JIT help improves task performance and overall user satisfaction. Help that arrives at the moment of need fits how people actually behave.

This novel interface paradigm reduces users' cognitive load by helping them recall information when necessary. When using this kind of interface, users' confidence in the system increases. They perceive the system as responsive, and as one that "understands" their intent well; all of that while keeping the user in control. When JIT help is adequately designed, the product becomes self-explanatory.

Apart from the digital world, we can find many well-designed examples of JIT help around us. Some airports, for example, feature panels that reveal additional information as you approach them - just in time:

Check-in zone numbers are visible from far away; as you are approaching, all related flights for the target zone become visible

Have you ever found yourself in trouble when connecting cables to the back of an audio device, not knowing where each cable goes? Fortunately, the designers of this amplifier prevented a headache by writing labels for connectors upside-down:

Simple yet brilliant JIT help

JIT help does not necessarily need to be written - it may consist solely of icons:

Help symbols seen from far away

...and when entered the scene

Finally, JIT help does not need to be visual at all. GPS navigation is a common example, where the voice tells the driver in advance on when to steer. Some ATM devices offer proactive auditory help when a person approaches them. Museum audio guides tell a story related to the nearby exhibit using a sophisticated location-based system. Public transportation system announcements like "The next stop is.." help riders stay oriented. Smartwatches vibrate to signal that the exercise interval is over, prompting the user to stop for a break or to switch to the next exercise.

Can JIT help explain complex topics?

JIT help can only do so much; this is by design, because it offers brief, thus limited information. It is useful for clarifying simple interface concepts but insufficient for explaining more complex subjects. Try to explain cloud computing, cybersecurity or machine learning in a paragraph or less; it's too complex, and needs depth, deeper learning, more material and understanding on multiple levels.

Why JIT help is so effective? This is because users generally don't read online documentation and manuals. And terribly conceived, non-contextual and inaccessible help documents only contributed to that.

"Most help doesn't really help you, it's just waste of time"

J.Nielsen

Designers should be aware of JIT help downsides. For example, placeholders in form fields can actually ruin the usability because they disappear when the form field is in focus. Thus they are considered anti-patterns.

Placeholder that gets hidden when the form field gets the focus

It's important to note that asking an LLM or search engine is not considered just in time help. By design, JIT help recognizes user intent and is presented contextually and automatically; by contrast, having users actively search for information elsewhere represents a different pattern.

An evergreen design pattern

JIT help is one of the evergreen user interface patterns that have stood the test of time. But use it sparingly; do not overload interface with unneeded labels, tooltips and other extravagant dynamic assistance (anyone remember Clippy?). Assume that users already know most of the interface patterns, so overusing the JIT help may be counterproductive.

Remember to ask yourself those three basic questions when designing JIT help^[4]:

Is it timely?
Is it relevant?
Is it useful?

Those questions can assist in evaluating the effectiveness of JIT help during user testing.

Don't forget: JIT help has its place in physical objects, too. We noticed it on hi-fi devices, London street crossings, inscriptions on fuel doors, highway rumble strips and of course - tractors.

However, its name says "when" the help appears, not "where". If we want to be technically strict, it should be called "Just in time and place" - but the JIT abbreviation is common and works well in this case. ↩︎
Integrated development environment is an application that provides all necessary tools for writing, testing, editing and compiling the code. It became standard in the 80s. ↩︎
Don Norman, "Things that make us smart" ↩︎
https://uxdesign.cc/building-proper-communication-between-a-product-and-its-users-69b1ffd13a6a ↩︎

Users Don’t Hate Change, They Hate Losing Habits

2026-10-20T00:00:00Z

I have been asked many times to "do a complete redesign of the product". An ordinary task, one would say, every product should be redesigned from time to time, then why not? Especially if there are known issues and obvious constraints dictated by current design. "The product is crying out for a redesign", I've been said; let's do that!

Except for a small detail: the product in question has a big user base and works very well for its users. Product testimonials are all positive, praising its usefulness and practicality. Business metrics are growing quarter by quarter. In a word, it's successful.

But the business stakeholders are nevertheless asking for a redesign. Why?

Rationales for an (un)reasonable change

To find out about the reasons for the everlasting need for product change, we should analyze those who request a redesign - decision makers. In my experience, many of the business stakeholders and product managers are change-driven and impulsive. Understandably so, because it is their job to manage other people and projects. They easily get bored with the existing version of the product because they spend most of the time looking at it, working on updates. They also analyse competitive products; trying to catch-up with others could create the illusion of falling behind.

But boredom or panic is not a design strategy. Those are two real human emotions that are hard to control, and product stakeholders frequently resort to default command mode: let designers do the redesign! Let them propose "new version", update the aesthetics, make it more glamorous, apply popular design trends to our product; it will get us out from boredom, it will be more like other successful competitive products, it will sell better!

Well, this is not true. A redesign without a real need, done for its own sake and focused on surface only - is doomed from the start. Let's see its classical case.

One catastrophic redesign failure

Windows 8 launch in 2012. is a typical case of a redesign fail. The Microsoft executive team decided to remove its iconic "Start" button and menu.

This design decision hit hard on loyal users. Their response was predictably negative; the new version required users to change their long-established habit for the essential software they use every day: the operating system.

Also, some core functions like Search, Share, Settings, Devices - once at obvious place, were hidden; therefore users lost the way to access them instantly, as they were doing before. There were no affordances, nor discoverability for those crucial features.

The feature used every day - "Shutdown" - was moved to a different part of the interface. "How do I turn off Windows 8" become the most frequent search query back in the day.

And why the change? Microsoft noted that Start button usage was declining and used it as a rationale for the change. But "low usage" didn't mean "low value". They wrongly concluded that Start button was becoming redundant.

There was one stronger reason for the change: Microsoft was not catching up in mobile market. By redesigning Windows to prioritize mobile users, Microsoft hoped that developers would extend app development from desktops towards mobile devices - tablets and phones. They wanted to use desktop users as a leverage towards mobile market. This didn't happen.

Some of those changes were reverted back in next Windows 8.1 update, after a year of a user backclash. Until then, users downloaded the extensions that brought their loved "Start" button 10s of milions of times.

There are many reasons for failures of redesign project. Here are the ones that do the most damage.

Weak criterion - or absence of it

When a design team has no goal beyond "making it new by redesigning," it has no clear definition of "done". It has no clear success criteria for the project, either^[1]. And if there is no stated problem in the redesign project then the surface change becomes the single measure of progress. Consequently, opinions and preferences of decisions-makers take precedence over the real business metrics.

So we are then left with the single criteria: how well the product looks. This is because people believe that visually attractive products are easier to use. It is a well-documented human universal, called the aesthetic-usability effect. Because of this bias, focusing on appearance over substance can easily hide usability issues. If there is no real criterion for redesign, the product people easily slip into this bias.

The surface redesign changes a perception. If done properly, the product that looks fresh can attract new user base and expand to new markets. But after a first test, the product made only to be visually beautiful quickly reveals its structural and usability flaws.

Despite its large potential, it might be a trap for design teams if "to make it look new" is the only reason for redesign. And there lies the next common cause for unreasonable redesign.

"New is better" paradox

"Make it new" is not a design criterion - unless you work in the fashion industry. People mistake "new" for "better" - hence the confusion. Honestly, "Make it better" is a sensible goal, meaning that the product team is about to deliver value.

But "new" is not the same as "better". New is new, and better is better. This important distinction is forgotten, more often than not. And from there, somehow, developed "new tech is better than old tech" - a popular yet shallow mantra of technological progress. "Throw out the old, bring in the new!" - add some features, polish the visuals or rebrand, stamp "UPDATED RELEASE" on it and sell it!

Actually, "make it new" was a motto for modernism in 30s', persuading the clientele that novelty is a value in itself. Then the public perception took over, and sculpted a mental model of "better" around novelty. This automatically put "old" in an inferior position.

Modern digital products often treat familiarity as a problem to solve, directly sabotaging the evergreen principle of familiarity. Especially for consumer technology, novelty can be part of the appeal^[2].

So: new - good; old - bad. Then "make it new", disguised as "make it better", came to mean: just do a redesign and the product will automatically get better. Which brings us to the next temptation - possibly the most dangerous of all: doing for doing's sake.

Doism

To the man with the hammer, everything looks like a nail

Old Proverb

For design fundamentalists, "I design because I can" becomes "I design, therefore I am". The designers design, and redesign, because they can. The digital medium and tools allow them to do that easily. Making things just because you can, for no good reason has even been given a name: “inverse vandalism”^[3].

Alas, "doism" ends badly most of the time. This is because of a lack of rational and critical thinking in the moment, especially under time pressure.

"Better than nothing" is worse than "nothing".

Pavel Samsonov, Product picnic

Generative LLM technologies^[4] force a "better than nothing" approach. They are perfect for that. Building products with them relies on confirmation bias and precisely because of that produces subpar results.

And if the "doism" of designer is not enough, a reminder: it's the product manager's job to keep the team busy. When the backlog is empty, it's tempting to make a product feel "new" by redesigning it. Doing a redesign also gives the illusion of progress, especially to unconfident product managers.

Then when it's the right time for a redesign? Should it ever be done? Yes of course - Lets see!

When a redesign makes sense

Some legitimate reasons for redesign are:

Design or technical debt
Change in business rules
Technology forces a redesign
When the old design limits existing users or doesn’t work anymore
Expansion to new markets and new user base

The reasons for redesign should be evidence-based. They should have their roots in user observations, usage analytics, measurable business metrics or feedback. And those reasons are almost never strong enough to justify a total redesign.

Apart from specialized industries that sell "new" as an advantage of a product, the need for a "complete design overhaul" is rarely driven by a genuine product need. This is most evident in well-established products with an active user base. The users want familiar design.

However, the mantra “if it works, then don’t fix it” doesn’t always work. Designer's deceptively convincing excuse is consistency: keeping the same interface for years builds habits in users, raises perceived usability, and makes the product easier to use over time. Users become familiar with the product regardless of its usability: they adapt to wicked interfaces or non-optimal user flows; they develop odd shortcuts to avoid obstacles in their daily work (I’ve seen this many times).

What should designers do when asked for a thorough redesign? They should fight back with "why". This is the universal question, aimed at a productive conversation: talk about the reasons for the redesign. Look for the root cause. If there is none, or it's weak, try to get the decision reversed and propose incremental changes instead. Remember, the product manager might be bored with the current product, but customers most likely are not.

Once all stakeholders understand the real reason for the redesign, the team should set a clear goal for what the redesign should achieve.

If everyone agrees there are clear rationales for a total redesign, designers should still perform it incrementally. Do it carefully, with a plan, in phases. Then, during the rollout, measure the key metrics carefully and change the project direction if needed. For example, if the user feedback is strictly negative in the early phase, re-evaluate the decision to do a total redesign. Sticking to a plan that does not deliver as expected will hurt the existing business. Nobody wants that.

Will this approach lead to a “local maximum” of design? Yes. It can prevent a “moonshot”. And that is the point: be cautious not to disrupt user habits when performing a redesign project; the last thing you need are mad users.

But if the clear goal is a "moonshot", with its known downsides, then go for it. Wipe out the old and do a complete redesign. Even then, you should make a plan before redesigning and offer existing users the option to revert in case the redesign doesn't work.

Today's products are viewed as "innovative" or "different" just because they are "re-designed"; as if "being redesigned" were the only quality. But this misses the point: successful redesign is supposed not to be substantial. The redesign should lean toward the functional aspect of the product, toward "tweaks" and fixes, rather than "complete overhaul". Not every redesign should be revolutionary, nor dramatic. For example, Wikipedia 2022 redesign is barely noticeable, and that’s the point.

Designers should not avoid a redesign at all costs - it is worth doing under certain circumstances. In general, it should be thoroughly considered and done under controlled conditions.

The Evergreen Principle: Respect the Habit

When you redesign, you force users to change their habits. After launch, it might seem that people hate the redesigned product; in fact, they hate losing their habits. Once a habit is established, people would rather not change it.

“You know… we, the users, don’t like it when you change things in the app. We get used to it. Then you change it and we can’t find anything. We don’t want you to change it.”

From a user interview^[5]

Redesigning for the sake of it will not give the product a market advantage. A functional design doesn't need a refresh or a redesign unless the requirements change dramatically^[6].

There is nothing wrong with being "boring" when designing. Boring can be a standout feature and an advantage, especially for established users who care more about usability than aesthetics.

Ask yourself: does the redesign add meaning or solve some of the crucial problems? If so, change carefully then test and measure the impact. Make people's habits your first priority.

Change with care, not with ego. Solve problems and add value - anything else is just redecorating, refreshing or restyling.

In the case of Windows 8 redesign, though, Microsoft's executive team knew exactly what they were doing: they deliberately wanted to steer the platform away from the desktop paradigm and toward to the mobile one by favoring the touch interface. They clearly had the problem they needed to solve. But this came at great cost to existing users - the fix cost them the desktop and never won them the mobile. ↩︎
https://deadparrotbbs.com/why-old-software-sometimes-feels-better/ ↩︎
Coined by Alan Kay ↩︎
Incorrectly called "AI" ↩︎
Emilia Manevska (LinkedIn) ↩︎
Redesign trap ↩︎

For most users, interface IS the product

2026-09-15T00:00:00Z

Alas, designers are no exception.

What you see is all there is

Can you imagine what is this, actually?

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

This hurts ROI and usability at the same time. Double non-win.

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.

I want to be driver, not a mechanic, when using this product!!

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

Does these guys knew what they were doing??

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.

When the interface is the product, the failure is common

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.

Inverted iceberg. Unfortunately, this is how current design process looks. Edited by author.

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.

Jared Spool

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

There are more fidelities other than low-fi and hi-fi..

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.

Not a resort here. You can see backend at its finest.

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 ↩︎
https://www.nngroup.com/articles/hamburger-menus/ ↩︎
https://www.lukew.com/ff/entry.asp?1962 ↩︎
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 ↩︎
"The age of Yet Another" - by Vincent Bruijn ↩︎
I highly recommend the book by Erica Hall ↩︎