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





My Role 

Product Designer


8 weeks 

What I did

  • Workshop facilitation
  • Sketching
  • A/B Testing
  • Taskflows
  • Competitive Analysis
  • Wireframing
  • UI Design
  • Prototyping
  • Presentation & Feedback


  • Figma
  • Figjam
  • Google meet
  • Notion



Reduced time to value TTV for onboarding new customers


Increased brand trust as evidenced by customer feedback.


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

The problem

The primary challenge was security. Existing API token management posed risks by granting broad access to anyone. Questions arose regarding access control, token duration, and attributes.

Also control - Who controls what? How long should API Tokens exist? What properties should they have, in relation to how long they exist?

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.

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

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

I had a few more questions

  1. What's the Users' understanding of Service Users?

  2. What's the optimal placement for Service users within the Humanitec application?

  3. What's our customer's comprehension of the Service user's permissions?

  4. 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


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


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 - the Org members page and 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.




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)


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:

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

Want to work together?

Get in touch!


Designed by Debbie B.

Back to top Arrow