UNIFIED TEAMS & PERMISSIONS
Acquia offers a variety of web management and personlization (SaaS and CaaS) tools. Each has a different interfaces, naming conventions, and structures for its “Teams & Permissions” section.
Work with Product Managers to design a “Unified” Teams & Permissions to increase brand consistency and contribute to a suite-like and consistent user experience.
Process & Research
The most challenging part of this project was to pinpoint the definition of “Unified” when designing for a “Unified” Teams & Permissions.
Initially, Product Managers were invisioning one place where a user could go to adjust their Users, Teams and Permissions for all of their Acquia Products. This was later decided against, for reasons below.
First steps involved analyzing the differences in Acquia’s current products. A site map and structure map were created for each product.
Differences in naming conventions cross-product were also noted and analyzed.
Competitors like Amazon Web Services were analyzed in depth. A site and structure map was made for them as well, and compared to Acquia’s products.
Positives and Negatives of AWS were recorded and discussed with Product Managers.
Overall business and end user goals were analyzed. (The Teams & Permissions project was initially called ‘Unified Admin.’ This was another naming convention issue.)
A structure map was drawn up to demonstrate how the Acquia products would function with a permissionsing system consisting of “policies” like AWS.
Ultimately it was decided that because some of Acquia’s products were in their very early stages, we did not have the data to support created a fully unified/cross-product Teams & Permissions section.
This was partially because some of Acquia’s products were in their very early stages and we could not determine whether or not there would be user overlap, whether the products would be used as the busines had intentioned, and whether or not this more complicated structure could be justified.
Research and Findings were presented to Product Managers and stakeholders. Final deliverables consisted of two structural diagrams, one for next recommended state of Teams & Permissions and one for a future recommended state. The future state will be when Acquia products are fully integrated with eachother in other functionalities and it makes sense to have a unified Teams & Permissions. Additionally a final prototype of low-fidelity wireframes was created for the first diagram.
A low-fidelity wireframe prototype was also created based on this first diagram. Scroll down on this page for a walkthrough, or explore it here.
This prototype is a redesign of an initial prototype on which user testing was performed, and improvements were made.
Naming conventions were unified and documented.
The first structural diagram represents a unified structure of Teams & Permissions while keeping them specific to each product. This includes how each product should be structured, in order to implement the most clear and understandable Teams & Permissions section.
This section will not be cross-product initially. Acquia should implement this and record data on how users are interacting with these designs before changing them.
The second diagram is the future state of Teams & Permissions when Acquia products are fully unified.
In this diagram, Organizations and Teams could be cross-product, but the role concept would be more complex. A "Developer" role for example, would include permissions for all Acquia products.
Teams would similarly be accessible and expandable to resources cross product. However, resources would have to main product specific in that you cannot access "Campaign" data from Cloud for example.
The Acquia product shown here is Lift. Rather than a separate Admin Portal, it made sense to add an Admin section to the Product Grid Icon. Users tested positively to finding Teams & Permissions information here.
In Acquia’s product “Cloud,” the previous Teams & Permissions landing page is shown here. Notice the “Members, Teams, and Applications” tabs. On each of these tabs, information is repeated and it becomes redundant and unnecessary.
In the new design, minimal information can be found at first glance about a user’s teams. However, using the search bar they can find specific information they are looking for.
Also notable: since a main problem users had was a full understanding of the definitions of “teams” and “roles,” the permissioning section was renamed “Teams & Roles.” It was broken down into two simple tabs to be more easily digestible, and definitions were included in the right side bar for help.
After clicking on the name of a specific team, a user is taken to a page where “assigned resources and “Users” tabs may be seen right away. This is designed to show the user exactly what a team consists of: Users, and the resources that the team allows them to be assigned to.
“Resources” will vary across product. In Acquia Cloud, they consist of “Applications and Sites.” In Acquia Lift, they will most likely consist of “Campaigns. This more specific language will most likely be used instead of the word “Resources,” as it is not always clear to the user.
Creating a new team allows users to not add users of the product right away, if they would like to only organize their resources into teams first. This should be helpful because different size customers of Acquia use teams in many different ways. Regionally, by role, etc.