Boosting security for a Developer tool web app with the Service user feature

Client

Humanitec

My Role

Product Designer

Duration

5 weeks

What I did

Workshop facilitation
Sketching
A/B Testing
Taskflows
Competitive Analysis
Wireframing
Design system (Storybook)
UI Design
Prototyping
Presentation & Feedback

Tools

Figma
Figjam
Google meet
Notion

Metrics

Strengthen API Token security

As reported by users.

9% increase in NPS score

Increased brand trust as evidenced by customer feedback.

Background

In platform orchestration which Humanitec does, user trust and security are paramount. The Service User and API token feature is pivotal in ensuring the right access to a company's infrastructure.

Interactive Prototype showing the ‘Add a Service user’ flow

To align the Product, Engineering & Sales on the Service user feature, I conducted a workshop

Unfortunately, we didn’t have a video record/documentation of Sales calls, so I had to resort to a workshop with Sales guys, and other members of the wide cross-functional team. Also, I wasn’t able to get customers for an interview.

The problem and problem statement

After the workshop, I discovered that

The team agreed that Service users can solve the problem.
We defined Service users as a special type of non-human user account that is created specifically for a service or application to access a web service or API. It’s very different from a human user/Org member/Team member.
A particular Service user can have as many API tokens within it as possible and can be customized & personalized regarding security settings.
The API token inherits the permissions and properties of the Service user.
The Service user should/can not be edited. Instead, it should be deleted, and another one can be created.
The team hasn’t decided on the placement of Service users with this new update.

The naming convention hasn’t been decided. Having both Service users & Users side by side is confusing. Other naming options for users include Organisation members, human users, and team members.

For each Service user, there are 3 levels of control/permissions -
Administrator: Has full access to everything within the Organization in Humanitec.
Manager: Same as the Member Role. In addition, can invite and remove Users from the Organization in Humanitec, issue API tokens, and create Apps.
Member: Can access Apps they have a role for.

Details I added to the Service user feature designed based on findings from internal Workshop, Competitive Analysis, and AB Test.

The Hypothesis I had

Placing Service Users on the sidebar for quick access was considered an advantage.
Yet, aligning Service users with regular users, within the Org members raised potential confusion.

I had a few more questions

What's the Users' understanding of Service Users?
What's the optimal placement for Service users within the Humanitec application?
What's our customer's comprehension of the Service user's permissions?
What's our customer's awareness of the Service Users and API tokens relationship?

I looked at other competitors like Vercel and Google console

I studied Google Console & Vercel for insights into similar features, and process.

Competitive Analysis of Google console and Vercel

Feature-Prioritization-for-Service-users

I did a Feature Roadmap with the cross-functional team for Prioritization

Site navigation of the API Token feature

Design system in Storybook

These are the sketches I made

I ran through various version of UI design, presenting to the team, and iterating

Feedback & Refinement

Wireframes evolved into high-fidelity designs using the Design system housed in Storybook. Various rounds of iterative improvements were guided by Stakeholders and the entire team's feedback, emphasizing UI clarity.

The team includes PMs, Front-end Engineers, Back-end Engineers, QA Engineers, Field Engineers, the other Designer, the CTO and Sales team.

The prototypes of both options A & B

Placement issues

While sketching, I discovered the Service user feature can sit in 2 places within the web application - within the Org members page and on the Side panel/bar. I designed two versions of the UI with the two placements and presented them to the team for feedback.

Option A with Service users in the Org member page

Option B with Service users in the Side panel/bar

Option A with Service users in the Org member page

Option B with Service users in the Side panel/bar

A/B Testing

A/B test with Maze favored Option B, featuring Service Users as a standalone on the Side bar, improving task completion rates and times.

PS - It was hard finding an A/B software that caters to entire flows, as opposed to one landing page. So I settled on creating 2 different Maze projects.

Outcome

Option B with Service user as a standalone performed better with more task completions and less drop offs, as opposed to the other one. Also, it had better time on task.

The result of the AB test

Other feedback

Educating both internal & external users

On educating users, I started with the in-house users, the Humanitec Developer team (consisting of all Front-end, Back-end, QA, Field, and Sales Engineers) all make use of the Humanitec app.

An in-house presentation for Humanitec's developer team clarified Service Users and API tokens for all relevant teams.

Also, blog posts, in-app tutorials, and onboarding guides (written by the PM, which I contributed to) about Service users are available on Humanitec’s website, to increase user adoption and reduce the customer’s time to value (TTV).

Conclusion

My key takeaways were:

This design-focused case study demonstrates addressing security and usability issues with Service Users and API Tokens, emphasizing user-centric design principles. Key takeaways:

Consistent documentation and feedback were crucial. I used Notion and Figma for documentation. Weekly UX briefings and Loom recordings sufficed for feedback sessions.
Understanding the product's unique context was vital.
User education was pivotal in successful adoption.