How to produce better designs for complex apps

Designing simple, easy-to-use enterprise products is easier said than done. Customers expect enterprise products to deliver experiences like those of Facebook and Instagram.

John Maeda, former president of the Rhode Island School of Design, identifies “thoughtful reduction” as an approach to better design. He says, “Simplicity is about subtracting the obvious and adding the meaningful.”

So why are designers and the teams they collaborate with susceptible to over-complicated designs?

Let’s take a look at how you can leverage techniques within your design process to break down complex apps and produce better designs.

1. Brainstorm high-level user stories to lay out starting points for design

Agile engineering methodology uses a concept called an epic, which is a high-level user story that explains what the engineer is going to build. For the rest of this post, I’ll use “epic” and “high-level user story” interchangeably.

If you were designing an online payments app like Square, Stripe, or Braintree, here’s an example of a high-level user story:

This story lets an engineer know what the feature will do as a whole, but it doesn’t really explain what this feature looks like, feels like, or how someone finds this feature.

The look and feel gets defined later on in the visual design phase. How a user finds this feature is defined when you create a task flow.

Let’s go through how to write your own high-level user stories.

What is a high-level user story?

A high-level user story describes 2 things:

1. The task someone can accomplish
2. What someone would find valuable within an app

If we were working at an online payments app, here are more high-level user story examples:

• “A user can offer discounts, coupons and special deals to customers so that she can push specific products to the market.”
• “A user can accept money in different currencies so that customers can know how much money was transferred for their purchase in their own local currency.”
• “A user can view a payment history so that she can track transactions.”

Beware of writing poor user stories that are more systems-oriented or broad—your app may handle them without any user input. These are usually things that you can’t design for, but they’re features engineers should include.

An example of a poor user story:

“A user can calculate the total of a transaction so that she knows how much money will be transferred.”

Why’s it poor? Our payment system app automatically calculates the cost, so a user doesn’t need to figure it out with an in-app calculator or press a “calculate” button.

When you’re buying things, do you ever have to add up anything yourself or ask someone for the total? Of course not.

A better version of the story:

“A user will be shown the total of a transaction so that she knows how much money will be transferred.”

By writing these high-level stories for a single feature, you’ll be able to think about the different parts of the app your feature may affect, allowing you to design a starting point in which users can get into the main flow of your feature.

But high-level user stories don’t explain the context of how people use the feature—yet.

That’s what the next step is for.

2. Break the high-level user story down into smaller, more specific user stories to lay out the main flows

A high-level user story can be split into 2 or more bite-sized stories. These specific stories introduce context and details about how the feature works for the user. This not only helps you design for specific use cases instead of tackling a huge problem, but it also helps your engineers understand the different parts of the app that’ll be affected by this feature.

“Split an epic into 2 or more bite-sized stories to introduce details about how the feature works for a user.”

For example, the high-level user story “A user can create subscription plans so that she can define price points and packages for her business” can be split into these stories:

• A user can set the frequency of a subscription plan (days, months, years)
• A user can name the subscription plan (Bronze Plan, Silver Plan, Gold Plan)
• A user can set the price for a plan ($99, $199, $299)

Now we know that the overall concept of “creating a subscription plan” encompasses 3 outcomes for a user:

• Setting a plan frequency
• Naming a plan
• Inputting a price for the plan

By completing these 3 actions, a user successfully creates a subscription plan.

If you break down your high-level user story into smaller parts and it winds up having too many parts, you may want to re-think how many things a user has to do before they can receive value from your app.

“Too many parts to your epic? Re-think how many things users have to do before they can receive value from your app.”

Doing too many things at once is a reason enterprise apps feel clunkier and more cumbersome than consumer apps—and it’s why people are starting to prefer a more consumer experience in enterprise apps.

By eliminating and prioritizing what matters to the user so that they can get value, you’ll be able to focus on your app’s value proposition and get users to realize value sooner rather than later. And that’s what we’re talking about next.

3. Eliminate and prioritize your user stories

Once you have a list of user stories, you don’t have to design for all of them. If you do, you may end up with a bloated feature that does way too much and could overwhelm your audience.

For example, let’s say your target market consists of businesses in the United States. You can focus on handling payments in American dollars. Rather than developing a system to handle multiple currencies, exchange rates, and taxes on a multinational scale, you can focus on your target market. You don’t need to design for international currencies.

This strategic decision can cut down on development time and let you focus on what’s important to your current customer base and your business. It’s a reasonable thing to ignore until your company chooses to expand its business internationally. For now, you can keep things simple.

4. Transform user stories into task flows

As you write user stories, put them onto a whiteboard—it’s easy and it prevents you from getting married to any specific idea. User stories and task flows will go through series of drafts. A whiteboard lets you change your ideas quickly.

With all of the user stories on the whiteboard, you can start piecing together a main flow that you want a user to go through. This is where the task flow comes in. The task flow fleshes out how someone starts with the flow, as well as how they accomplish tasks, exit points, and decision points.

A task flow provides value because it not only allows you to see the big picture, but it also prevents you from creating dead-ends. Moreover, it helps your team understand what you may be thinking.

Here’s a common workplace scenario:

A teammate explains a specific flow verbally in a meeting or through a chat. Everyone in the team nods in agreement. A few days later, you and your co-workers realize you were all on different pages.

Task flows eliminate this risk by visually explaining your vision so that you build common ground with your team. In addition to creating shared understanding with your team, a task flow diagram describes the scope of your feature from the point of view of your users. The task flow forces you and your team to consider all touchpoint, alternate flows, edge cases, and corner cases.

What happens if a user leaves the flow? What happens if the user returns to the flow? What happens if an error happens?

Not all designs are linear and sequential. A task flow takes multiple variables into consideration. Different factors can impact how a user moves through your app. The end result is a strategically thought-out plan of how someone can use your product. As your team creates user stories and task flows, a quote by former professional football player Eric Thomas comes to mind: “Fall in love with the process, and the results will come.”

What to take away from this

A common mistake in the design process is to attack a complex problem head-on and start drawing out a layout in Photoshop as the proposed solution. It’s tempting to immediately start picking out colors, arranging UI elements, and getting the typography just right.

Before you design anything, add these 4 steps to your process:

• Brainstorm high-level user stories to lay out what someone will accomplish with this feature
• Break down the high-level story into smaller, digestible chunks. This gives you a starting point to create more context for the user, and it also gets your team on the same page as you.
• Eliminate user stories that aren’t essential for someone to get value from your app or accomplish something so that it’s easy and simple to use rather than complex and cumbersome
• Go to a whiteboard and draw out a task flow where all of the stories come together so that you have a flexible canvas for discussing ideas, changing flows, and collaborating

With user stories and task flows, you can deliver game-changing designs that lift your product to new heights.

As Steve Jobs once said: “Design is not just what it looks like and it feels like. Design is how it works.”