SPlash: Team manager
Splash is used by a variety of enterprise clients that have large teams. While each client has a unique set of team members that have different responsibilities, they share the need for an interface which allows them to set up their team without depending on Splash support. This includes managing licenses, adding and deleting team members, creating groups, and configuring permissions via user roles.
01. USER RESEARCH
With the help of our customer support team, we reached out to a selection of clients that were set up in Splash with complicated organizational structures. Because all permissions had to be handled internally with different “org properties”, their organizations were a tangle of different combinations of permissions and groups per user. The technical term we used for this was “an absolute nightmare.”
The Product Owner for this project, Jon Saft, then took this research and made a list of “jobs to be done” for the new Roles product. In order to organize this information and begin to divide it into manageable chunks to work with, I wrote each ‘job to be done” on a post it, and mapped them out.
02. USER FLOW
Click for high-res PDF image.
I took the initial analog user flow and digitized it, and it became clear that this new product area could be divided into four distinct sections.
Users: a list of team members who are members of that organization, easy to search by user or by filtering. Users can be added and removed from the team here, and can be assigned a role.
Groups: users are grouped together in order to determine event visibility between users, as well as who is managed by whom. Groups can be created and deleted in this section, users within each group can be viewed and added.
Roles: each role is a grouping of specific permissions within the product, which can range from no access to view only to edit/create/delete. This is where we expose our default roles. Default roles can be edited and duplicated to create custom roles, and permissions can be edited.
Activity Log (nice to have): a dashboard of user activity, which can be chronological, or filtered by user/action/event. This is especially useful for troubleshooting.
03. WIREFRAMES
04. MID-FIDELITY
Once the lo-fi wireframes were ready to bring back to the team, we dissected them. They became a starting point that raised important UX and technical questions, validating some decisions we had already made while disproving others.
For areas we needed more insight on, we moved on to what I called “mid-fidelity” screens. These used our component library, but still left room for UI and visual changes.
Option A: an interface for permissions that uses an “additive” control.
Option B: an alternate option for permissions that we moved away from.
05. PROTOTYPING + USER TESTING
Most of our questions revolved around how roles would work, and how different permissions could be granted based on levels of access and product area. Our main objective is to maintain a high level of role customization with as simple an interface as possible. The customization comes from granular controls for every product area, but simplicity comes from only showing a small portion of relevant controls at a time, and grouping these permissions based on hierarchy.
After additional rounds of iterations to the mid-fidelity screens, we turned them into two prototypes that we then brought to our clients for testing. Below are samples from these prototypes.
06. COMING NEXT
Our user testing goals revolved around usability, navigation, and determining whether the user, an admin, would understand the impact of their actions in this tool on their team members. During testing, we found that the biggest gaps were in understanding default roles, understanding the relationship between license type and available permissions, and improving the language to describe each permission. This project is still in progress; coming next are the updates to the designs based on these findings.