Muhit: What makes an interface consistent?

On a design system that begins with colours and components and reaches into behaviour, context and trust.

Imagine a work table. We narrow down the records, select a few rows, then move to another view to examine a detail. When we return, we expect our search, selection and place in the work to be preserved.

We do not often describe this expectation as part of design. Yet much of our relationship with an interface takes shape here: What will happen in response to what we do? What will the system remember? How will we know when an operation has not completed?

This became the question I explored while working on Muhit: How can the different parts of an interface offer the user a shared pattern of behaviour?

Where does consistency begin?

The visible side of a design system is easy to describe. Typefaces, colours, spacing, buttons, cards and tables come together. A familiar rhythm emerges across pages.

Yet two buttons that look alike can create different expectations. One completes an operation immediately; another opens a confirmation dialog. One form shows an error beside the relevant field, while another provides only a brief notification. One table preserves its filter; another returns to the beginning with every update.

In an interface like this, users have to learn the behaviour again even when they recognise the appearance.

Muhit began with the idea of turning the pieces developed during the Nevmos interface work into an independent library. Separating them required asking which decisions belonged to a particular product and which could be carried into other work.

A product's logo and content belong to its own context. Visible keyboard focus, understandable status labels, the ability to retry after an error and feedback on an operation's outcome have a wider range of uses.

Muhit tries to hold these shared decisions together. I also find the associations of environment and neighbourhood in its name meaningful here: each part has its own role, while the environment they create together needs to remain understandable.

A shared language under different conditions

That environment does not have to look the same in every project.

A research tool may make room for long texts and references. A frequently used administration screen may call for a denser layout. Another piece of work may be built around quieter surfaces and more generous spacing.

I approach theming in Muhit through these differences. Colour, typography, density, borders and motion preferences can change together. Underneath those changes are defined roles such as text, background, accent, status and focus.

When a theme changes, we therefore need to ask further questions: Is the text still readable? Is the selected state understandable? Can someone navigating by keyboard see where they are? Are touch targets sufficient in the compact view?

A similar test appears in the different states of a page.

A screen filled with content shows just one moment of the design. The same screen also needs a considered state while waiting for data, when there are no records yet, when a request fails or when access is required.

“There are no records yet” and “The records could not be loaded” are different situations. The user's next step may differ as well. In the first, creating a new record makes sense; in the second, trying again may be necessary.

Working through these states in Muhit's page recipes brings the screen's behaviour outside its ordinary flow into the design as well.

The same care continues when components are connected to an application. In the reference integrations, details such as preserving a form draft when the language changes, or carrying filter and selection state across a table remount, become important. What the user has just done provides the context for the next step.

An interface keeping its promise

This approach also matters when agents propose interfaces.

A model can propose the information to display and the actions to offer as a structured definition. It is possible to establish in advance which components that definition can become and the boundaries within which it must remain.

This is where Muhit's agent adapter works: it validates the definition and constructs the view using permitted components. When the user chooses an action, it passes that choice to the application. Saving data, sending a request and checking the necessary authorisation remain the application's responsibility.

This distinction also needs to be clear to the user. A “Save” button appearing on screen does not show that saving has succeeded. The interface's feedback must be based on the actual state of the operation behind it.

The idea that guides Muhit's design comes together here: The promise an interface makes should correspond to what the system actually does.

This remains an area of work that needs to be tested. Muhit 0.15.0 includes automated checks of components, page states, theme options and integration examples. Use on real devices and evaluation with screen readers remain ongoing parts of the work.

As a design system develops, it gains new components. Alongside that, I want to consider how much new learning it asks of the user.

When behaviour we have already learned retains its meaning on another page, when our selection carries into the next step, and when the system offers an understandable path in an unexpected situation, a shared language begins to form.

I am developing Muhit as an environment in which different kinds of work can find a place within that language while keeping their own character.

---

Different forms, a shared rhythm. The cover illustration was generated with AI for this article.

Resources: Muhit source code · Muhit 0.15.0 documentation

Related essay: What does a limited visual language make possible?

Atlas concepts: Design · Software · Context · Systems