Case Study: When a Security Rollout Became a Design Problem

When a Security Rollout Became a Design Problem

This Agile case study is drawn from the Agile Experience Report “Your security team needs design” by Kelsey van Haaster and Emma Lundgren.


When ThoughtWorks tightened password security, leaders expected an easy rollout. But internal surveys showed password manager use varied widely by region, and many employees found the tools unnecessary or hard to use.

The company offered a corporate password manager for employees and families, but setup confusion, support tickets, licensing issues, and accidental password exposure followed.

A small volunteer team treated the rollout as a design problem instead of a policy one. In three months, they cut setup time from 40 to 19 minutes, reduced major errors and support tickets, and increased usage to nearly 3,000 people.

The Challenge

A technically sound security decision collided with real user behavior

The existing expense policy for password managers was poorly understood and applied inconsistently across regions. Centralizing on a single corporate tool was meant to remove friction, but it exposed how complex and confusing the setup experience had become. Instructions were scattered, the process was harder than it appeared, and many users stopped after the first account-creation step because they believed they were finished.

The consequences were concrete: increased support workload, licensing issues, and real security risk, including exposed passwords. The team also faced clear constraints: users were distributed globally, parts of the experience depended on a third-party vendor, and earlier rollout problems had already shown that internal assumptions about user behavior were unreliable.

The Approach

Start with the actual user experience

Instead of issuing more instructions or policies, a three-person volunteer team applied the Double Diamond framework, Stanford d.school design thinking, and hypothesis-driven problem solving. Their working principles were straightforward:

  • Focus on root causes rather than symptoms.
  • Observe users directly in the process.
  • Keep documentation light but useful.
  • Make work visible and remove unnecessary complexity.

They did not try to redesign everything. They concentrated on what they could see, control, and test quickly.

Implementation and Iteration

Identify failure points, then redesign the flow

The team began with an expert walkthrough, followed by one-on-one setup sessions with users in Australia. After four interviews, clear patterns emerged. They simplified the journey from five user types to one primary path with minor variations.

The two most impactful changes were:

  • Reducing instruction sets from seven to one.
  • Moving a critical step earlier in the process so users were less likely to stop halfway through setup.

These were small, targeted adjustments made close to where users were failing.

Results and Impact

Over three months, the average setup time dropped from 40 minutes, with help, to 19 minutes, with the fastest completion at seven minutes. Critical mistakes decreased, including cases where users put passwords in the wrong place. Usage grew to nearly 3,000 people, many of them first-time password manager users, and support tickets declined, freeing the Identity Team for other work.

The project also changed some internal views about what design could contribute to security work and how useful design thinking tools could be in solving this kind of problem.

Lessons Learned

This case points to three clear lessons:

  • Technical correctness does not equal usability. A policy-focused rollout created confusion that a design-focused approach helped reduce.
  • Direct observation beats assumptions. Surveys flagged the problem; watching users revealed where it lived.
  • Simplification is powerful work. Fewer instructions and a better flow achieved more than additional explanation would have.

Key Agile Takeaways

What Agile looked like in action

  • The effort relied on short cycles, rapid feedback from real users, and small testable changes.
  • The team favored simplification over added process or documentation.
  • A small volunteer team owned the problem and adjusted its approach as it learned more.
  • The report explicitly connects the work to the principle that simplicity and maximizing the work not done are essential.

Read the original Experience Report “Your security team needs design” by Kelsey van Haaster and Emma Lundgren.

We hope you found this post informative

Before you move on, please consider supporting our non-profit mission by making a donation to Agile Alliance todayThis is a community blog post. The opinions contained within belong solely to the author or authors, and may not represent the opinion or policy of Agile Alliance.

Picture of Joe Foley

Joe Foley

Joe is the Content Manager for Agile Alliance. He specializes in content marketing and strategy, SEO, writing, editing, and WordPress.

Recent Blog Posts

Recent Posts

Join Agile Alliance!

$5 per month (paid annually)*

*Corporate plans are also available

Post your comments or questions

Recent Agile Alliance Blog Posts

Ready to join Agile Alliance?

Unlock members-only access to online learning sessions, Agile resources, annual conference discounts, and more! And when you join, you’ll be supporting our member initiatives, regional events, and global community groups.

Privacy Preference Center

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to SET UP AN ACCOUNT on the new platform to establish your user profile. Your previous login credentials will not work until you do this set up.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.