Before I get started here, I know talking about Application Design in the middle of a surging global pandemic and crisis in US democracy is a bit like building a gazebo in the middle of the Civil War. But here we go…

A few months ago, I stayed at a vacation rental house. In the shower, I noticed something that caught my attention. The shower faucet was a standard single knob — nothing unusual here — but in the upward direction were the words “Push Up Open”. Now, I understand that a plumber may think about a shower as being “open” when the water is flowing from the shower head. So, technically speaking, sure, it’s open. But, as a longtime user of showers, that’s not how I think about the state of a shower when water is flowing, and I bet you don’t either. Can you think of a time when you said, “I’m going to open the shower,” (not meaning opening a door, but actually initiating the water flow)? No, what people usually say is that they will “turn it on.”

Ultimately, who cares right? I’ve seen this type of shower dial before, so it was straightforward enough. It wasn’t any of these pieces of work:


I knew how to operate it and even if I didn’t, the feedback I would receive from pushing the dial up (i.e. water flowing) would essentially train me how to use it. But, if the manufacturers of the shower dial decided that it was necessary to use a few words to help bathers know how to operate their dial, then shouldn’t they be the words that are most direct and helpful to us, the people using the shower?

Using Microcontent

Here at, everyone who works on our products thinks a lot about how our AI for enterprise applications work. We are similar to the manufacturer of that shower dial; in that we are minutely aware of the mechanics of how our products work. We deal with the “plumbing” of information: we even refer internally to our “data pipelines” that move information from databases to the Interface. And like the shower parts manufacturer, it’s very easy to get caught up on the details of how the product is working. For example, questions like, “Which data science model is creating certain information, what API is delivering what metric?” may come up. But as a product designer, it is my role to make sure the app makes sense to the person using it and avoid making the same mistake as the shower maker.

Don Norman, in his pivotal book “The Design of Everyday Things” talks about how the responsibility for usability falls on the designer, not on the user. He says, “Machines are not people. They cannot communicate and understand the same way we do. This means that their designers have a special obligation to ensure that the behavior of machines is understandable to the people who interact with them.” In Noodle’s case, the user needs to get a certain job done, and it’s not their job to conform their understanding to the app. Ultimately, it’s our responsibility to build an app that conforms to the way the user understands the process and engages with the product.

A lot of important design considerations go into our app interfaces, but one important piece that should not be forgotten in the User Interface (UI) are the words used to direct and guide our users through the functionalities of the applications. As a designer, it’s on me to leverage every tool at my disposal to make our apps as usable and error-proof as possible. One of those tools is what’s called “microcontent,” but we can also just think of this as the words and short phrases that appear in the app.

According to the Nielsen Norman Group, “Microcontent is a type of UX copywriting in the form of short text fragments or phrases, often presented with no additional contextual support.”

Using microcontent in the right way is super important in helping our applications users navigate through and efficiently operate our applications. As Christie Lenneville advises in her article, good microcontent is “… crystal clear, brutally concise, and perfectly descriptive, using real language and a conversational tone.” The language I use in the microcontent of our apps need to reflect the job that needs to get done — i.e., turning the shower “on”— not the language of the data science or engineering under the hood.

An example at

I’ll give you an example from an app that’s in the development stage for our Vulcan Manufacturing AI Suite, called “Sequence Planning”. Without going into too much detail, this app leverages machine learning to improve efficiency at a steel mill by optimizing the order in which steel coils are manufactured. It’s actually a very interesting process, plus there are big, fiery explosions!

There is a step in this app where steel mill managers give direction to the machine learning model before running it. They can choose settings like grades, dimensions, and duration of the steel coil production process for the ML model to then follow. On this screen, there is a brief description telling the users what they should do in this step.

Now, from our side of things as builders of this app, a logical short description on this page may be “Assign data model parameters.” But this is the equivalent of the “Push Up Open” text on the shower knob. It’s entirely from the app developers’ perspective, not from the app user’s. And so, a more useful short directive on this screen would be:

“What type of coils should this sequence include?”

It’s more human language, and it poses the question that the planner needs to answer to do his job. The steel mill managers are smart and know their industry well, this isn’t about dumbing anything down. It’s simply using language that is relevant to them so that the app speaks their language and reduces the user’s cognitive load.

The concern with vague or jargon-y language is not that a user will misinterpret a single bit of copy leading to an error (although, that is a possibility); it’s more that every complex decision the user has to think about drains a little bit more energy from their tank — this is why President Obama wore the same color suit every day. It’s the cumulative total of interpreting many poorly worded bits of copy putting the user in position to make a poor decision. So, all the words should be chosen to make their next action easy — even obvious. It’s Steve Krug’s maxim (and book title) “Don’t Make Me Think”, this leaves the user with full mental reserves, ready to confidently take their next action.


The small type matters. It may be obvious how to operate a shower with or without clear directives but interfacing with machine learning algorithms in enterprise level software is another story. There are likely to be scores of actions for the user to take, with countless moving parts and that requires a carefully considered UI with language that is clear, direct, and familiar to the user. Here at we leverage clear language in our apps to make them easy for our customers to use.

To learn more about our Vulcan Manufacturing AI Suite, visit our product page or contact us!