.normalui-logo-cls-1{fill:#ffffff;}Normal UI: A Usability Technique For Non-DesignersI've been building web apps for 25 years. B2B, SaaS, eCommerce, intranet apps, and more. I've also been a UX designer for much of that time. I've run and watched hundreds, if not thousands, of usability tests.That means I've been watching average users (non-developers) try to use web apps (without helping them) for over two decades.You begin to see patterns in what makes a web app usable or unusuable under particular circumstances.In this post I will introduce you to a technique that I developed over those years. It provides a simple, concrete framework to improve web app usability, is friendly to non-designers, often results in cleaner code and improved accessibility, and facilitates good UX and developer communication.I call it "Normal UI".(If you'd like to watch a video version of this post, I'm embedding it below.)The Design DilemmaThere are two versions of a dilemma in web app design that I see de

.svg-holder { text-align: center; margin: 2rem 0 0 0; } div + h2 { margin-top: 0.5rem !important; } .svg-holder > svg { max-width: 100px; }How to Rewrite a Web ApplicationYou're about to start rewriting a web application. If your first step is to choose your technology stack and start estimating features: STOP, you're doing it wrong.A screen-for-screen, feature-for-feature rewrite is a massive waste of opportunity and a huge waste of time and money.Let's talk about how to do it properly..garden-cls-1{fill:none;stroke:#ffffff;stroke-linecap:round;stroke-linejoin:round;stroke-width:3.5px;}The Big LieThe big lie of software rewrites is: "the requirements are already there in the existing software". If you think that, you're lying to yourself.That's like saying "the previous process that resulted in this software was perfect". No, it wasn't. I've seen so many teams get themselves in trouble by starting with this mindset.Assume the existing software is full of requirements holes and unneede

Smart Jerks Aren't Worth ItMyths proliferate in every culture. Some are harmless. Some are not. The myth of the "difficult genius" is perhaps one of the most harmful myths that still exist in software development today.Your software is hurt by toxic personalities on your team. Smart jerks aren't worth it. Let's dispel the myth.The Myth of the Difficult GeniusThe myth of the "difficult genius" is not unique to software development. The myth itself proliferates in part because of famously difficult-to-deal-with scientists, mathematicians, engineers, and more throughout history.A steady diet of books, movies, and pop culture have taught us that great things are accomplished by jerks and the people who tolerate them. This has been true.It is also true that great things have been accomplished by well-functioning cohesive teams of people who respected each other. That, however, isn't seen as fodder for great storytelling (who wants to watch or read about a team getting along).The important q

Understanding React CompilerReact's core architecture calls the functions you give it (i.e. your components) over and over. This fact both contributed to its popularity by simplifying its mental model, and created a point of possible performance issues. In general, if your functions do expensive things, then your app will be slow.Performance tuning, therefore, became a pain point for devs, as they had to manually tell React which functions should be re-run and when. The React team has now provided a tool called the React Compiler to automate that manual work performance tuning for devs, by rewriting their code.What does React Compiler do to your code? How does it work under-the-hood? Should you use it? Let's dive in.To gain a complete, accurate mental model of React by deep diving into its internals, check out my new course Understanding React where we dig into React's source code. I've found a deep understanding of React's internals greatly helps even devs with years of React experien

On The Why DownHow To Do Better Than MVPHow do we build software that solves real problems? How do both software development teams and the organizations that surround and utilize them come together to make good decisions? How do we acknowledge and work with the human factors built into all aspects of software development? How do we know what to build?The Myth of the MVPThe "Minimum Viable Product" is a great idea on paper. Over the years, however, I find that, no matter the software development process, defining what needs to be built is a problem that it doesn't solve well.MVP has two major flaws:The fog of "viability": Who decides what is "viable"? This term is subjective, and highly susceptible to organizational politics and human bias.The undefined "minimum": Minimum is a moving target, and often incorrect. It's susceptible to siloed organizational structures and communication breakdowns.MVP isn't the only issue. Companies have adopted Scrum and Agile. These too are meant to approa

A wall of wine at a winery in Niagara-on-the-Lake. The undersides of the bottles are curved, which gives the wall of wine a lovely reflective appearance.However the bottoms are curved, not for appearance sake, but to prevent the pressure from bursting the bottles while they sit in the rack.The best UX is both beautiful and serves a functional purpose. Analyze your design and remove the beauty that exists only for beauty’s sake. Focus on making functional things beautiful.

How To Write Email People Will ReadEmail is a part of everyday life. We are inundated.So how do you write an email that clients and co-workers will read?Give them a good user experience.UX and EmailPeople don't just read your email, they experience your email; the flow, the structure, the tone, etc. An email also sits inside of the chrome of the person's email client, webmail, browser chrome, etc. All of these things fight for visual attention.Thus think of your reader as the user of your email, and concern yourself with their user experience. Scannability, readability, simplicity, gestalt principles and other UX concepts all apply.Below are some UX tips for writing emails that people will actually read, based on my own experiments and experience.Short Subject LinesUX Principle: ScannabilityDon't put too much information into the subject line. It's annoying. Huge subject lines suggest that the reader doesn't read email and needs to be beaten to open it. That just makes people want to s

The diesel fuel pump in one state is green, while in another is black. Quite confusing for the traveler.One may find oneself confused as to why the pump does not fit into your gas tank…however the prevention of error is extremely important in this case.Consistency and standards are good things. While making something obvious is the best approach to software design, respecting standards prevents confusion against learned behaviors.At the same time, preventing error is equally vital, especially if the error will cause serious, irreparable problems.

This gas station pump asks for your zip code when you enter your credit card. Then you have to search around for where to enter it. The keypad is set off to the right and inset.It doesn’t appear to have any relationship to the screen where the message displays, causing a brief moment of confusion as you scan for an interface to obey the screen commands.Pay attention to gestalt principles. Elements of an interface that are related should appear to be so visually via position, color, size, borders, whitespace, etc.Make related elements obviously, visually related, and you will cause less moments of confusion, less scanning, and less frustration.

Boarding a Southwest Airlines plane is a study in frustration. There are always at least several people milling about in confusion, most trying to figure out their line-up process while handling bags and children.The competitive ‘get on the plane first and claim a seat before everyone else’ turns their confused state into potentials for agitation and aggression (getting ahead of others when you shouldn’t, realizing too late you’re further back than you should have been).Those who are frequent flyers on the airline have a decided advantage over the new ones, and the agitated state of passengers translate into more frazzled employees.UX isn’t just about ease of use. It’s about avoiding frustration. It’s about how software makes you feel.Frustrating software results in agitated users. Agitated users means you have failed UX. Agitated users also introduces a host of other problems, such as exaggerated complaints, lack of patience with other minor software issues, and loss of loyalty.Care a

Mall kiosk with a Windows error. Graceful handling of errors is everyone’s job. A poorly handled error can pull the user down into the lower layers of abstraction, destroying the user experience.Handle errors gracefully, either hiding them, or displaying them as an integrated part of the user experience.Special integrated error pages or messages go a long way to put the user at ease when an error occurs. It says: “we knew this could happen - don’t panic." This would include user error, coding error, and even OS and network errors where possible.Assume everything will break - then work up from there.

Simple Is Not the Opposite of ComplexMy college life was all about education. Mathematics, arts, and sciences were thrown at high speed for high credits. Yet some of the longest lasting lessons didn't come from the classroom - at least not the ones I was paying for. One lesson in particular informed the way I would look at software development and user experience for the rest of my life. It came from pool.(Life) Lessons in BilliardsI was a commuter in college, and hung out in the 'commuter lounge'. It wasn't very fancy - there were some lockers, a TV, tables and sofas. But the centerpiece of the inner half of the room was the pool table, and it drew me to the place every day.I fell hard for the game, playing constantly (for better or worse in regards to my GPA). A graduate student saw my love of it, took pity on me, and offered to train me. He was good. Very good. I accepted, and learned a ton.One day we were watching two students battling in a game full of tough shots. A crowd had for

Simple garage door opener. It does one thing well. There is a single button, and an indicator providing feedback. However it is also extremely easy to click the extruded button.Time and again I find myself accidentally opening or closing the garage (sometimes with myself in it). So much so that I periodically check that the garage door is closed.Ease of use is incredibly important in software. However certain functions, especially dangerous ones, should not be made easy to accidentally invoke.For deletions, take a user to a completely separate screen or large modal with clear indications of what is about to happen.Wherever possible and applicable, provide ‘undo’, and make it immediately available after the action is taken.Easy-to-use is rewarding. Easy-to-do-accidentally is frustrating. Be sure your designs know the difference.

Heating and Cooling controller in an older model Kia. There are 12 positions. Seven are labelled. Five are not.What in the world is the position between ‘defrost’ and 'feet and defrost’? I have no idea. In fact, I still have no idea. Perhaps the designer ran out of room for icons, but the middle states simply aren’t guessable unless you designed the system.One of the most common mistakes in UX is failing to realize that your design appears usable to you only because you already understand the system.What is obvious to you is not necessarily obvious to the user. Don’t let love of a design blind you to its failings. Don’t let yourself get away with 'they can read the manual’, 'they should be smart enough to get this’, or other such self-serving thoughts.Make it obvious. Make it guessable. Make it good.

Key and LockIn his seminal work The Design of Everyday Things (revised in 2013), Don Norman notes that with every new technology designers repeat the same mistakes of the past.User experience designers should not fall into this trap, because a fundamental key to good UX design is humility. It takes humility to change a design based on user testing; and it takes humility to look back at technologies of the past that have endured, and show them their due respect.One of the oldest and best interfaces has endured for thousands of years. The two part interface: key and lock. Let's pull some software lessons from before there was software.GuessabilityThe key and lock is guessable. Most doors have only one keyhole. The key looks like it fits in the hole. If you handed someone a key, and pointed them at its corresponding door, they would likely guess what to do even if they'd never done it before.Both the key and lock follow DOTW (Do One Thing Well) and it is hard for a user to get it wrong.Ma

The key and lock is one of the oldest and best examples of a good interface. It’s guessable (there’s only one keyhole in the average door), secure (you have to know and have the right key, but it isn’t hard to use), consistent (know how to use one key, you know how to use almost all), and provides good feedback (key turns or it doesn’t).Above the all the key/lock interface is good abstraction. Few people truly know how the tumblers in a lock work, and fewer still could design them. Yet the key abstracts the user away from the inner workings of the lock, allowing them to focus on the task (opening or locking the door) rather than how the tool helps them accomplish it.Interfaces that have been around for centuries have done so for a reason, because they rely on UX truths that work no matter what the technology.Guessability, security, consistency, feedback, and good abstractions are something that every interface (physical, software, or otherwise) should share.

Drink machine at a local Five Guys. I watched as every single person made some form of mistake during use.There is a touch screen selection UI, and a ‘Push’ button below it. However the button always says 'Push’, so most push it not realizing they’ve made a mistake in the selection process and something unexpected pours out.The beauty of old-school drink machines is that they’re hard to get wrong. Each lever corresponds to a specific drink, and the only action available per drink is 'make this drink come out’.Newer or prettier isn’t always better. Using a new interface technology simply for the sake of the new technology is a fail if you don’t follow the basics of good user experience.In this case the UX principle broken is feedback. Since one button does many things ('Push’ could mean one of any of the drinks), it fails to follow DOTW, thus good feedback is vital.For example the button could say 'Push for Coke’ when Coke is selected and 'Push for Sprite’ when Sprite is selected, etc.

A Behringer 802 Mixer. Mixer boards are powerful and useful, but they must be learned. A mixer board is the opposite of a lightswitch, there is nothing obvious or intuitive about it.There are so many options the user’s best guess is likely wrong (though labeling helps), and the designer must rely on memorization and education on the user’s part to use the device well.There is nothing wrong with dashboards, portals, hubs, etc - as long as you don’t expect them to be used by new users. Many options means many ways to get it wrong. If you build an interface this way, you must assume memorization and education, not guessability.So look at your user base and decide: Am I building a mixer board or a light switch?

Walmart. Primary sections, sub sections, and sale areas are clearly marked – yet you still have to stumble around to figure out where you are in relation to everything else.If you were suddenly transported to a spot like this in the middle of a Walmart, would you know how to get to Electronics?If you watch people’s user experience at a Walmart, there’s a lot of neck craning, searching for signs of where to go.Better: Subtle markers pointing to other areas visible from any point in the store.Navigation in your app or site should meet the ‘dropped in the middle of the site from a search engine’ test.It may be clear where other related pages are, but can your users tell where they are in relation to your entire site?Don’t make your users crane their necks to find what they’re looking for. They might just give up and leave.

DOTW: Do One Thing WellThe Mantra of the Guessable InterfaceIn the land of coding there is a principle that defines the essence of modern multi-tier software architectures. DRY: Don't Repeat Yourself.DRY has become so widely accepted in software design because the benefits are obvious and immediate. Less code to write, less bugs to fix. It makes for less confusing software from the programmer's perspective, which leads to better software for everyone.The DRY principle is this: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." DRY works for software architecture. It's about reduction.In my design experience I have found that there is a very similar UX principle that is equally effective in developing usable (that is, guessable) software.DOTW: Do One Thing WellThe principle is simple. As with all principles, its application varies depending on the circumstances. If I was to try defining DOTW more strictly, I would say:Any screen or

A mechanical pencil follows DOTW (Do One Thing Well). There is only one way to get lead out, and only one option to try. However it breaks down when the lead runs out. How many times have you shaken a pencil to see if lead is still in it?Better: If, once the lead ran out, a bright red warning piece of plastic came out of the tip clearly indicating the error state.A simple interface that ‘Does One Thing Well’ is highly desirable and guessable. Yet you must take into account all 3 states of an interface: Empty, Full, and Error.If you have a clear picture of all three states when you design then so will your users.

Back of a Black & Decker Air Station. Can be powered from a standard plug (AC) or a car lighter (DC), and you choose which. The design doesn’t assume you know which is AC and which is DC.Actually, it gives various opportunities to figure out which is which, and when all else fails provides the icon of a car to make it absolutely clear. It’s ensuring understanding and educating at the same time.Labels are good. Labels that assume the user has a specialized vocabulary are not. For example a button that says ‘Check If This Username is Available’ is much better than a button that says 'Validate The Uniqueness of this ID’.Be sure your labels do not make unreasonable vocabulary assumptions. Better, teach the user new vocabulary through the interface design.

A flashlight is designed to be used in the dark. The simple act of picking it up puts your fingers in the position needed to be able to turn it on. You can turn on a flashlight without having to see.Actions should be in the most natural positions for their usage. A large form with a save button icon somewhere off in a corner, or an important screen hidden under a four level navigation menu keep the user blind.The more the user has to hunt, the more likely their frustration, exhaustion, and potential failure.

The doorknob with lock. People on the outside cannot open the door, however turning the doorknob from the inside automatically unlocks it.Security is important, but that isn’t excuse for software to be laborious. Afford people the ability to both provide their credentials and their intentions.For example, if they go to a secure area of the software and are forced to log in, after they log in you should automatically take them to wherever they originally wanted to go.

An on/off switch on a desk lamp. A single interface controls both on and off. Since it is the only option, it is obvious by process of elimination. There is also strong and immediate user feedback. “Light off! Light on!” is hard to miss.Elements of an interface should only perform one function. You can consider a toggle as only “one” function: ‘Off’ is only available when 'On’ and vice versa.Toggle is less obvious when many interface elements are present, so strong feedback from the action (like 'light on/light off’) becomes even more important.

Portable charger for a car battery. Cords are made to wrap around the charger and lock in place. This looks very nice, but the cords are far too short and makes it extremely cumbersome to connect. This only worsens the frustration you are almost always already experiencing whenever you use this device.Aesthetics are important, but they are not worth sacrificing ease of use. The best designs are both beautiful and clever. Ease of use is even more important when the functionality is explicitly used under stressful situations.

Panel on a Keurig coffee brewer. Turn it on, main screen says ‘Ready to Brew’, and you choose one of 3 cup sizes. There are no labels, but the clarity of icons and reduction of options makes it self-evident.Normally labels are needed on icons. However (if the icons are extremely clear, agree with the context, and the interface’s goal is self-evident and highly focused) labels aren’t always necessary.

Back of a vacuum cleaner. How do you turn it on? Once you turn it on, how do you tilt it back?Primary functions should be obvious. Secondary or related functions should be easily accessed alongside the primary action.

Struck by the brilliance of a tissue box. Not so much that you can get a tissue out, but that the next one is left waiting for you.Most software is a series of tasks. Make the next logical tasks readily available upon completing the current one.

My toaster oven. Top dial when in the ‘off’ position means oven is off, but toaster is on. The bottom two individually control toast versus oven.Many a time I have left the toaster thinking it was toasting, when it was in oven position, or vice versa. The toaster ticks, but I return to find no heat, no ready food.In software each interface should DOTW: “Do One Thing Well”. The more functions any element of an interface carries out, the less likely it is do any of them well.

Dyson bathroom hand dryer.Good: Where do you put your hands?Bad: Hand spaces are too small. You inevitably touch the sides which ruins the whole point.Make it easy. But software has to actually do what it says it will do, otherwise all the other good UX doesn’t matter.

Airplane tray table. How do you open it?Give your user’s best guess the highest probability of being right.

Single light switch on blank wall.A self-evident interface doesn’t need documentation. Scannable, limited options teach without words.

Good Interface, Bad InterfaceI have been doing a great deal of traveling as of late. Travel is frustrating. Airports, hotels, car rides and more are filled with other people's design choices. Some are good, some are bad, and they all carry lessons in user experience.Airport bathrooms, for example, turn out to be pretty diverse in their design choices - and their influence on the traveler's overall user experience is, understandably, intense. When it's bad, it's really bad.So, when faced with a bad user experience, I apply a simple mantra:If you see every moment as an opportunity to either teach or learn, life is a lot more enjoyable.Actually I try to apply this for good user experiences as well. Try to stop and recognize it when you've just effortlessly used some device or process, and ask yourself why it worked so well. Then take that lesson and ask how does it apply to software.Every user experience you have, whether bad or good, can inform the software you design.I'll give you an ex