blog

Bananas - illustration

Role Based Design

by

When designing custom software, designers often need to keep user roles in mind to make an efficient and effective user experience for multiple workflows. By taking a look at the needs of each user, we can design for multiple intuitive user flows while retaining a clean, cohesive look and feel.

User roles are based on access control, which determines who can see what in a piece of software. User roles can be as simple as allowing only registered users to access software through a login, or they can be much more complex, using access rules to show or hide content depending on the user’s purpose.

The primary benefit of custom software that keeps roles in mind is the ability to create one software suite that can handle multiple functions, while providing the user with exactly the information they need to make their experience useful. We can achieve flexibility in design by using modular widgets, common workflows, and universal navigation placement with customized text per role.

User roles can make onboarding new users a more streamlined process. It allows for flexibility in development, features and widgets can be added on a per-role basis, if the needs of those roles change.
Common User Roles

User roles include users that are critical to the success of the software. They can be defined based on the needs of the software and the organization, but most user roles contain at least guest, registered user, and administrator access.

A guest user can have limited functionality or a preview of the software, and often is presented with an option to become a registered user.

Registered Users are authorized to use the software and can access it through a login or other authentication method.

The administrator often has access to all areas of the software, both as a user and as a manager who can configure the user interface and grant access.

From there, roles can be developed and refined based on the software specifications, and the functions that each type of user needs to be successful in the application.

Our Example: The Banana Stand

Our custom software is an app to facilitate banana sales by linking together grocery stores, growers, and customers through an interface that is being developed by our client, the business owner.

Our user roles for this application are:

  • Banana Stand Guests – This user role represents unregistered users, who could be customers looking to buy bananas locally, or unregistered sellers or suppliers interested in our software.
  • Banana Suppliers – This user role represents growers who need to sell bananas to marketplaces in our application.
  • Banana Sellers – This user role represents marketplaces buying bananas wholesale and selling them to customers directly.
  • Banana Administrators – this user role represents the users that have full access to all parts of the software, including assigning or revoking user access.

Designing for User Roles

When working with custom software that needs user roles, designers must keep in mind the experience of each type of user. While a design for any custom software project can, and should be uniform, designers can customize the appearance of the software for each user role.

User Stories

The first step to designing for user roles is to develop user stories. It helps to take a step during the spec writing phase and look at each role as a story and determine what their needs are for the software.

There are a variety of ways to outline this user story, but most involve writing an informal description of the user’s purpose in the software, and their path to success. User stories can evolve over time, especially if additional functionality is needed during development, so they should remain flexible and editable.

User Flow

Once the user stories are complete, it can help to create a user flow, or user map, that shows the path each user role will take to complete their tasks. Outlining a visual path toward success for each user role can help clients verify that the workflow is correct, and it also helps highlight inefficiency or workflow issues before software design begins.

Now that we have user stories and flows, we can create our wireframes. With the information we created in the previous two steps, we can create views for dashboards and other templates that are customized for each user role. By showing relevant widgets and navigation specific to each user role, we can create a modular design that is flexible, useful for each user role, and can easily be modified in the future.

Creating a dashboard for multiple user roles

A dashboard is a great place to implement user roles to customize the experience for a user based on what they need to see to complete their task. We can display relevant reports, widgets or navigation that is specific to each type of user.

With these user roles, we can design a unique experience for each, while keeping the same common elements.

Our Example: The Banana Stand

In our Banana Stand wireframe, we have common elements in the same location for each user role. The header and toolbar appear the same, but the center content varies depending on the user roles.


Banana Stand Guests

Banana Stand Guests

Banana Stand Guests represent two types of users. They may be looking for local bananas, or they may be users that could potentially be buyers or sellers. Since we have no way of knowing, we can present them with two options – to sign up as a seller or supplier, or to find bananas nearby. This screen can also double as a login screen, to allow other user roles to access their own accounts.


Banana Growers

Banana Growers

Banana Growers are users who have bananas and need to sell them. They need to be able to change contact information, send / receive messages, see sales reports, and search through listings for potential buyers.This user role represents registered users with limited permissions. Here, we see our basic dashboard design for the first time, with basic card options and a universal toolbar. The header remains the same throughout the app.


Banana Seller Reports

Banana Sellers

Banana Sellers have more reporting needs than banana suppliers but have nearly identical needs otherwise. These users need to be able to change venue contact information, send / receive messages, see sales reports, see purchasing reports, and purchase from buyers.


Banana Administrator Dashboard

Banana Stand Administrators

Banana Stand Administrators have access to all other functions, but have additional functionality not granted to other user roles. Administrators have the sole ability to grant and revoke permissions and edit existing user roles.


From here, we can customize each view based on the information we gathered in the user stories and flow stages. Even shared features, like reports, can be customized to each user, by showing relevant data while retaining the universal design guidelines.

Designing for user roles should be part of the workflow of any design project. If the specifications support user roles, keeping these roles in mind during wire framing will give a depth to the design and provide a customized user experience for each type of user.

+ more