The user profile is one of the main points of interaction for administrators and supervisors at health systems that use Relias. It’s how they manage the work force.
As part of our effort to overhaul how we handled user identity information we needed to change the code base for the user profile. This seemed an opportune time to bring the design in line with out current design standards and improve the organization of information.
As you can see in the above image (you can click on it to see the full thing), the user profile is an obnoxiously long and overwhelming form of input fields that start to all blur together.
There are also a number of actions that can be taken on the screen that are hidden by being lost in the jumble.
My first steps to redesigning the user profile was to update the design assets, move several functions to the top of the page to make them more obvious and easily accessible, and to split up the input fields to make the information on the page more manageable.
I moved the more modern icons for seeing the user’s transcript and emailing the user from being hidden at the top of the form, to next to the user’s name. As well as adding the ability to log in as this particular user to the same spot.
This makes their location more obvious and makes sense as they directly affect the user themselves. I did demphasize the “Login as User” button by making it text only as it stands out enough with its new location and I don’t want to over emphasize it since it’s not a primary goal of a user on this page.
I also moved the save button to the top right corner to help it stand out more and to reflect that it affects the entire page.
The input fields are now split onto different tabs and grouped by the type of information they contain. This keeps the user from being overwhelmed by a blob of fields and also makes it easier to find whatever field they are looking for.
The information on this page is divided into “User Information,” “Professional Information,” “Roles and Permissions,” and “User Settings.” This denotes the difference between personal data, where the user is located within the organization, what the user is allowed to access, and managing the user’s account.
When a user comes needs to interact with this page, whichever of those sections it is their goal to change, they can access it right away.
Roles and Permissions was part of a larger pitch to how we manage user information and manage the overall experience of the platform.
Currently, we have a list of a number of very specific roles that can be assigned to users. These roles determine what a user is allowed to access within the platform and even what their overall view of the platform will be.
Each role contains a specific experience and that can be changed using the rolse switcher drop down on the right hand side of the header.
The pitch is that this drop down is incredibly annoying to use (and is hard to find). We should kill the drop down and allow every user to have the same experience while roles simply define what they’re able to access.
Or put another way, roles move from defining experience to simply being a group of permissions.
Other issues I wished to improve with this design is that we have a lot of confusingly named roles with very low usage across our clients. This is because the roles were frequently created to respond to the needs of a single client.
Talking to our users revealed that there were only three completely separate roles that were absolute requirements for all our users: “Learner,” “Admin,” and “Supervisor.”
I wanted to limit the roles to those three while utilizing the new paradigm of roles being groups of permissions to make them far more customizable. Users would be able to alter specific permissions for specific employees. Further, they’d be able to create their own roles to fit exactly what their needs are.
The hardest thing about designing for medtech is that every health consortium does things completely different from every other health consortium. The solution is to offer limited uniformity and expand customizability.