Design for feature escalation

Dealing with infinity in the enterprise world

Enterprise design is a whole different beast. I’ve always said that if you can solve for enterprise design, you can do anything. One important challenge is to manage escalation.

When creating B2B (business to business) software, one thing many not know is you’ll be adding features to FOREVER. I mean it pretty much literally. If you have one million features, clients will ask for one million and one.

This is huge. Imagine keeping an apps screen easy to understand, focused, with the potential to do hundreds of actions. It’s easy to add a new button, dropdown, tab, or whatever graphical element. The hard part is to understand the long-term impact of your interface.

The 90’s and early 2000 had this problem. If we don’t study the past, no matter how “clean” we think our designs are, we could run into the same problems.

Learnability vs. Discoverability

There’s dumb users out there (yes, there are), and to combat this, we have to make interactive items as clear as possible.

Say you have a button with a nice icon on it. You add words to explain it’s function with a simple verb. Congratulations! You just took over a percentage of your screen for years to come.

Remember, you’ll probably be adding buttons as long as there’s an app. Anything you might add to your screen will be multiplied by an unforeseen number. Every couple of weeks you’ll have to add more.

It’s might seem impossible to balance button exposure. Do you simply design an icon they’ll quickly learn the meaning? Hide the button in a sub-menu through a right-click? The struggle is real.

Here at our company, we give dominance to actions which initiate primary outcomes. E.g. creating a contact would be clearer, as any other action stems from an existing contact.

We identify what the screens intention is, categorize functions, and then assign each one a menu. We can do this because every screen is designed to keep the user focused on the task as hand.

Focus your design

It’s a myth that humans can do many things at the same time. We might switch between tasks very fast, but in reality we’re only doing one thing at a time. Design for this with navigation.

It’s painful to navigate away from the screen to complete a huge task, but think of screens as categories. Each category should be optimized with the tools necessary for that category.

Go back to the contacts example. The user clearly navigated to the contacts screen for a reason. Why would designers deprive the user of their focus? Why would they have the ability to quickly change random unrelated calendar settings from the contacts screen?

You could have a shortcut if it’s crucial, but don’t go overboard.

Keep shortcuts to a minimum

Shortcuts should only navigate to the most important elements that complement the task at hand. A desktop with a couple of shortcuts is good, but too many and you defeated their purpose.

Think of it like designing a highway with 100 lanes. The only shortcuts you need is to ensure that lane 1, 50, and 100 can easily access an exit. Don’t worry about lane 23 merging into lane 75.

If you add an exit to every lane, you’ll create an expectation in the driver. This will lead then to believe an exit will be created for every lane that’s added. Design for scale without leading on.

Don’t create expectations

We created a feature in our app that allowed the user to see their tasks. We made the mistake of calling it “Task Calendar”. The problem arose when users expected it to function like a calendar. Because, no shit.

They could view their tasks in a week format. Naturally, they assumed we would build a monthly view, and then a yearly view. Hooray! We set ourselves to be a calendar company…

To fix this we simply changed the name to “Agenda”. This helped users expectations become non existent, and bring focus to features that mattered.

The name of your screen could influence what features will be added. Be wary of what you call it, even internally.

Remember, the path you lay ahead will pretty much be forever. Make sure it’s the right path.

And speaking of leading on…

Avoid Tabs

One day, I wanted to show the biggest problem tabs have. To do so, I plotted and handed over a design with two tabs in it. After some brief stares, the team was happy that we were introducing tabs into our app.

The next day, we walked in a meeting room to discuss the new design, and where new features would go.

I swear to you, it didn’t even take five minutes till someone pointed at the monitor and said: “Well… we can just use another tab for it.”

The first solution was to add another tab. Are you kidding me? This might not seem like a bad idea, but remember the “forever” part I mention so emphatically? Imagine adding a tab every couple of weeks. Yes… it will happen, and it has to stop before it begins. Just look at every enterprise app from the past.

Tabs aren’t bad or useless, they just open the door for clutter, and lazy design. It creates expectations externally, and internally.

There’s a lot of patterns than can drive you into a corner. Be careful.