How we moved critical customer tasks from our service team to the user, saving time and effort on both sides
Our customers rely on Acquia's team of in-house implementation and support consultants to manage the complex controls and functionality of their customer data platform (CDP) including data onboarding and user management. The process is time-consuming, costly, and often creates delays in deploying updates or making critical adjustments. End users and their administrators are left frustrated with limited visibility and control over their own data, restricting their ability to quickly respond to evolving business needs. primary effect on the user include the following:
Empowered End Users and Administrators: By streamlining data onboarding and user management processes, end users and administrators gain greater visibility and control over their customer data platform (CDP). This enhanced autonomy reduces reliance on external consultants, enabling faster decision-making and the ability to adapt quickly to changing business needs.
Reduced Operational Costs and Deployment Delays: Simplifying the complex controls of the CDP minimizes the time and resources required for implementation and support. This efficiency lowers operational costs, expedites updates, and ensures critical adjustments are deployed promptly, improving overall user satisfaction and system reliability.
Role: Project, design, + research lead - Acquia 2022-23
HAPPINESS: Boost customer satisfaction with implementation and onboarding by 20% within 4 months post-launch.
TASK COMPLETION: Enable admin users to autonomously manage user roles and key database configurations
INTERNAL: Reduce account-related support tickets by 40% and minimize management time for customer-facing teams, measured through internal surveys.
Role-based access control (RBAC)
Permissions are assigned to roles, and users are granted roles. Access is determined by the role(s) a user has, rather than assigning permissions to individual users.
Pros
Cons
Access control list (ACL)
Permissions are assigned directly to users or objects (resources). Each resource has a list specifying which users or groups can access it and what actions they are allowed to perform.
Pros
Cons
Design recommendation
Although an ACL-based permissions structure was expected to be easier to implement initially, the design recommendation provided to the product and engineering teams prioritized an role-based structure. This decision was driven by RBAC's superior scalability—particularly for future integration with other products in the suite—and its increased security from offering consistent, audit-friendly user permissions to support long-term growth and reliability.
HAPPINESS: Partway through the project, we lost funding for the third-party tool used to collect in-product feedback, preventing us from comparing customer satisfaction ratings before and after the feature release. However, in-house support teams reported a noticeable improvement in overall customer sentiment.
TASK COMPLETION: The scope was narrowed to focus solely on user management tasks, with plans to apply the same approach later to other areas like data onboarding. All planned tasks for the admin persona were completed. For non-admin users, all tasks were achieved except for permission viewing (see lesson learned below).
Four months post-release, account-related support tickets decreased by 25%, and internal surveys confirmed a reduction in time spent on management tasks for customer-facing teams.
The non-admin user’s need to view their own permissions was overlooked.
Problem: During the design phase, we did not account for users' need to easily view and understand their permission levels within the system. This oversight led to confusion and reliance on support teams for clarification.
Solution: Post-release, we brainstormed several design solutions, such as adding a dedicated permissions tab in the user profile or embedding tooltips throughout the interface. These are now prioritized in the feature backlog.
What I would do differently: We would have conducted more thorough user research and workflow analysis to identify critical needs like permissions visibility early in the design process. Usability testing prototypes could have surfaced this requirement before development began.
The technical and visual complexity of the permissions system was underestimated.
Problem: The permissions system was designed for general use but failed to account for the diverse and complex structures unique to different clients, leading to technical limitations and visual clutter.
Solution: We implemented incremental updates to the system to address common edge cases and began documenting client-specific needs for future design iterations.
What I would do differently: A more collaborative approach with engineering and client stakeholders during the scoping phase could have highlighted these complexities earlier. Prototyping scenarios with diverse client data would also have helped identify challenges and prevent rework.
Pre-release communication was not detailed enough for users
Problem: Insufficient communication with users about new features and updates led to confusion and an initial increase in support tickets, which strained resources post-launch. While this eventually evened out, there were a few weeks of strain that could have been avoided with a more proactive communication plan.
Solution: We added an onboarding guide and a series of in-app notifications using GainsightPX to explain the changes and how to use the new functionality effectively.
What I would do differently: Developing a detailed communication plan alongside the release timeline would have ensured all stakeholders, including support teams and end-users, were well-informed. Collaborating with marketing or customer success teams could have improved the delivery of these messages.