What I Inherited

The existing policy editor was simply a JSON editor textarea with a link to documentation. Customers had a difficult time creating permissions policies using this tool.

Understanding Users

Talking to several customers who manage AWS permissions I identified two primary user personas:

1. The casual admin - Their real job was developing software but managed some users & permissions things to get their job done. They were generally unfamiliar with concepts presented here.
2. The cloud architect - They were experts in this area and spent significant amounts of time managing users & permissions.

I also identified several key insights:

• Writing policies by hand was difficult – users had to remember too many rules
• Users started from policies found online then modified them
• The documentation was too dense
• The policies language in JSON was difficult to understand
• Frequent back-and-forth between cloud architects and developers was common to debug policies
• Users wanted to generate policies based on user activity

The Solution

The team designed a visual editing component, making it much easier to build policies. You start by picking a service you wish to enable.

Then pick actions based on the above service. Info links make it easy to access the documentation for each action.

Then define resources for the actions you picked

Easily move back-and-forth from JSON mode to confirm your policy is built as expected.

Policy “Linter” detects issues in your policy, making issues easy to find and address.