NoUI: Initial Thoughts

Some Backstory

I used to work the dorm desk when I was in college. We worked hourly shifts, and the worst shift was the 11 AM shift on weekdays. That’s when UPS arrived, along with several dozen Amazon packages.

We processed packages by filling out a paper slip for each package. This slip tracked the recipient, shipping company, delivery date, where we stored the package, etc. These slips were placed in each recipient’s mailbox. We also copied all of this information into a log book.

To pick up a package, a resident would first have to check their mail to find a slip. They’d exchange the slip for their package. At that time, we also had them initial the log book to indicate they received their package.

We were overwhelmed by packages. All the slip-writing and package handling took time. Shifts would sometimes be over before the desk worker could finish going through the entire delivery.

As a budding software engineer slash web dev, I replaced this with a digital package system. Nothing novel—just a database-backed inventory system with email notifications. This system reduced processing time from an hour to 10 minutes.

No Interface

That was the story I found myself thinking back to as I read The Best Interface is No Interface, by Golden Krishna.

Krishna’s main point is that we are, wrongly, screen-obsessed. Our end goal has become to design some UI on a screen, rather than to help a user accomplish the task at hand. Users have to jump through hoops to use an app or a site, leaving them frustrated.

As a north star, Krishna aims for no interface. By using technology in more invisible, seamless ways, we can create magical experiences where a user doesn’t even have to interact with a screen. They just do.

An example: today, cars can automatically unlock when they detect a key fob or your phone is nearby. You just open the door.

Krishna refers to this philosophy as NoUI.

Thoughts & Responses

I agree with the big picture for NoUI. If achieved, things will “just happen.” They’ll be simpler, natural, and less frustrating.

However, from where we are today, I think this is hard to achieve—primarily due to practical concerns. I think the greatest initial push would come from a big name NoUI demonstration—something that makes it clear that there’s a standard companies should aspire to.

This book feels like a “visionary” book. Its job is to inspire and share a dream, not to pave a way forwards. And so it does not really address challenges or obstacles that need to be figured out. That’s for the next wave of adopters.

Now, some specific points.

Surface Area

The biggest question I found myself asking: what can/should we apply NoUI to?

Many of Krishna’s examples are physical. They involve a human interacting with a physical object or entity. Examples include unlocking a car/apartment door, ordering coffee, and starting a laundry machine.

A number of them have a common theme: use some kind of physical tracking device to provide proximity-based features. For this class of interactions, NoUI seems to be a great and achievable goal.

I’m skeptical about interactions that either (a) are based on a screen or (b) involve information processing or manipulation.

Krishna acknowledges that watching a movie will probably always involve a screen. To have a conversation with someone in another city, I have to use and interact with my smartphone. Playing a video game requires a screen.

We can extrapolate a bit. Screens are used for one of two things: user input and displaying information. NoUI can be used to improve both, but it seems much more powerful and helpful on the user input side.

With user input, the assumption is that we can use contextual information, tracking, or indirect user input to improve an experience. The challenge is around designing mechanisms to collect or process that information. This burden lies on “producing” side (the designer, developer, company, etc.), rather than the “consuming” side.

Information display is much harder. If the information consumption is a means to an end, we might be able to find a clever way to circumvent it. But if the consumption is the end itself, we’re heavily constrained.

How would you learn when fridges were invented? How would you learn what’s on the menu at a restaurant? You need to ask a friend, do something in person, obtain a physical information medium (pamphlet, book), or use a computer. If you use a computer, it needs a way to present its information.

A note on smart assistants: they aren’t good enough yet. They can do some things well, but they are still constrained by many of the bad user experiences described in the book (faulty input, errors, etc.).


Okay, so what do we need to create a NoUI experience?

There seem to be two main keys: user intent and configuration. The degree to which your experience is a good one depends on how well you nail these things.

User Intent

User intent is what someone is actually trying to do. NoUI has a few broad approaches, as presented.

We can classify and determine what a user is trying to do. This relies on contextual information (weather, today’s date) and indirect user input, often via sensors (current location).

We can try to engineer a scenario where the user stays happy—eliminating the need for them to take an action. An example here is Next—if your home is at a good temperature, you’re rarely going to think about it.


Configuration involves determining the right set of parameters for a good experience.

We can select a default that we hope/believe is good (meaning useful/acceptable to a significant amount of users). If a user is unhappy, we can allow them to manually configure this. (Krishna falls back to screen-based configuration here.)

We can adapt and tailor an experience to a person, via data science and AI. In practice I feel that there is still a lot to do here, even for “simpler” seeming features—YouTube recommendations suck.


The biggest practical constraint I see is cost. Or, in another light, ease of getting started. The smaller your organization is, the more constraining this is. Relatedly, people are also constrained by different incentives.

Good NoUI (really, UX) involves a more detailed, intimate understanding of what someone is trying to do and what is happening while they do it. Someone who has a lot on their plate or is just aiming to hit a deadline will not have enough space to figure this out. The easy thing to do is to slap on a screen.

NoUI can also be multi-disciplinary. This adds two new types of challenges: competencies and logistics. As soon as you add a sensor, you are adding hardware. Are you competent with developing and integrating hardware? Are you set up deal with those physical components?

This forces a NoUI follower to make a serious commitment. Some may not even have the authority or ability to do so, even if they really want to.

Additionally, “NoUI or nothing” is a false dichotomy. Some screen-based solutions are legitimate improvements over existing solutions—such as my package system. They may not be pushing any boundaries, but how many people are trying to do that?

The point of all of this is not to say that NoUI is too hard or not worth it. I still think it’s a good goal. The point is that there are still many improvements that can be made that are not NoUI.

There are many local maxima (especially when factoring in cost/ease), and it can be much easier to reach those than to reach a NoUI maxima. People do what is easy, and so this is a very real human obstacle for NoUI.


Krishna presents arguments for people concerned with risk / automation adoption. I agree here, but there’s nothing new here. Risk analysis is looking at possible outcomes, probabilities, resulting impact, remedies, and your own tolerance.