Lakera Guard Policies
Process
The problems:
1. The users need more customization in what they want our product to flag. Besides, they need a custom way of setting the thresholds for different entities they care about depending on the use case they have (such as Chatbot application moderation concerns, Personal data leakage, prompt injections of LLMs etc)
2. Users get too many false positives and don’t trust the data
3. Users get false negatives and might miss a potentially dangerous incident.
4. So they need to decide what data to flag on which threshold and what data can be ignored depending on a use case.
The process:
1. I got the first information about the problem from our CPO and the senior product manager on my team who I work closely with. The data was collected from the Customer success calls and the Sales calls. I read the meeting notes to investigate further.
2. After that I’ve discussed the project in details with the product manager to ask the questions I had and clarify some moments.
3. I started working on the user stories and user flows for the project using the data I had from the customers
4. Explored the competitors and solutions they provide, also looked at similar products which are not necessarily our competitors (such as typical cyber security products and other technical products that might use policies/guidelines etc)
5. After discussing the UX research and competitor research with the team (product manager and the lead engineer), I started designing the wireframes. The following were divided into 3 categories: MVP version (should be easy and quick for engineers to build, meets the essential user requirements, Clean-up version (has a bit more nice UI elements that can make the user experience more enjoyable, however, not a deal-breaker for a user if we don’t have them), and Nice to have (might be a bit difficult to implement but has more benefits for the user and a nicer UI and interactions, however, these can be added later if we do see the need for them)
6. The next step was to discuss the initial wireframes (3 categories) with the team and check for technical limitations, get their feedback and iterate.
7. The improved version of the designs was prepared, together with the interactive prototype flows based on the user stories.
8. User testing and collecting the feedback from users
9. Iterating again after the testing
10. Preparing the designs for engineering hand-off. Adding notes and documentation
11. Adding the new components into the Design system
Result
1. Users’ needs are satisfied, and paying customers closed ( we managed to close deals with customers who required custom policy functionality)
2. We meet the requirements of the market by providing such a solution, more likely to attract more SaaS customers
3. More customers are interested in SaaS deal rather than Self-hosted since the platform provides more flexibility and the interface is easy to use
