Information architecture

Let's imagine that we've formulated a product idea and defined our audience. We know loads about their habits, needs, problems, desires, and most importantly, our experienced UX researcher has compiled use cases (user scenarios) for us. So what are we going to do now? The next step is to figure out the structure of the interface.

Interface structure

When people talk about the interface structure (also known as information architecture), they are usually referring to the sequence of screens required to perform a particular action. What will the main flow be? At what point will the user be able to access additional options? How can someone who becomes deeply immersed in the settings section quickly return to the main screen without clicking the "back" button 20 times? It's critical to solve these kinds of issues before you start creating your service.

A system's information architecture is a schematic representation of the information in its structure. It's utilized for analyzing individual use cases and the entire service as a combination of different screens. By defining an app's architecture, a team can estimate how long it will take to develop. They can identify key features, divide the creation into phases, and determine the MVP (minimum viable product) and subsequent stages of improvement.

Focusing on information architecture also helps with the initial design — when there is no clear understanding of what should be included in the service. It allows you to analyze the interface structure of similar applications (such as those of your competitors) to help determine the standard steps users should follow so your product is convenient and comfortable to use.

You can see a simple example of an interface structure below, containing several screens from a movie tickets app:

Users begin by logging in. But what should be on the screen at this point? Should people log in via social networks or email? Or should we just ask for a cell number and send them an SMS? These are the questions that only tend to crop up when you map out the structure.

Use cases

A use case is a step-by-step description. It defines how a particular type of user will utilize your application to achieve a specific goal.

To create a use case, you normally need to consider the following questions:

1. Who is the user?

2. What actions does the user want to perform?

3. Why does the user want to perform these actions (what is the user's ultimate goal)?

4. What steps will the user need to take to accomplish a particular task?

5. How should the service respond to an action?

Let's look at a couple of application usage scenarios and the system architecture they would require.

We will start with a simple calculator app — you can see the answers to the use case questions below:

1. Anyone

2. Calculate some numbers

3. To get the correct mathematical answer

4. Input some numbers and use mathematical operators

5. Show that the number is written, show that operator was used, show the calculation result

In this case, the entire architecture of the service is built on a single screen because the user is so familiar with using a physical calculator:

Next, let's imagine that our calculator has become a little more sophisticated. In the below example, the application allows us to view previous calculations (history) and lists tips about using various mathematical formulas:

In this case, our application consists of three screens with different functions. It's important to be aware that the main screen which opens when you start the application is still a calculator. The user can simply calculate the numbers they need and close the application if they wish. However, if required, they can also click on additional icons to switch to other screens and view the history of calculations or see various hints about formulas.

Note that you can't move directly to the hints screen from the history screen or vice versa because the only possible navigation from these screens is the "back" button.

Third-party services or browser

The user may sometimes need to leave your application to perform an action. For example, this might be necessary to make a payment or read a user agreement published elsewhere. Let's define how this architecture would be implemented by adding to the picture shown at the beginning of the topic:

As you can see, we have indicated that the user must use a browser to buy a ticket or to study legal documents.

Conclusion

It's essential to consider your users' goals and objectives when designing an application, which can be done by defining use cases. Before developing your app or creating a visual design, you should also model all the screens to understand the service's architecture. This stage provides valuable information about how much time (and money) will be spent developing the platform and enables you to decide which features to implement first. Finally, don't forget that you can analyze your competitors' application architectures before creating your own service!