PERSONA // SUPPORTING OUT-OF-BOX DOCUMENT EXTRACTIONS
TIMELINE
December 2025 (3 weeks)
ROLE
Product Designer
TEAM
1 Product Manager,
1 Engineering Manager,
1 Design Advisor,
3 Engineers
1 Product Designer (me)
TOOLS
Figma,
Cursor,
Claude Code
PRODUCT CONTEXT
Persona is a platform that handles identity verification.
One component behind identity verification is DOCUMENT VERIFICATION. For instance, let’s say a truck driving service wants to hire a new driver. During the process, they would want to verify that the candidate has a valid driver’s license. Determining if a driver’s license is valid would include looking at the issue and expiry date, and making sure the driver’s age is valid according to the current date and laws of a given country. For an example like this, the people configuring the verification would need to specifically configure EXTRACTIONS, and specify that they want “issue date”, “expiry date”, and “date of birth” extracted. After specifying the extractions, all of the work needed to verify the validity of a document is done through an automated system in Persona.
In the Persona product, there are a few different types of extractions. In this project, the focus was on “AI extractions”. These extractions work through the user providing an extraction key that concisely describes what field they want extracted, alongside a longer, more explicit description of what the field is. Combined, they serve as a prompt that is fed into an LLM to extract the field from the given document.
PROJECT CONTEXT
When configuring document validation, Persona currently already allows you to either say you want to validate a “custom” document, or choose from a library of Persona document types. Prior to this project, the document types didn’t have any impact on document extractions.
The goal of this project was to simplify the extraction configuration experience after a user picks a specified Persona document type. With this project, we want to suggest related extractions that the user can add to their verification configuration. The extractions will be “out-of-box”, coming directly from a library configured internally by Persona. These extractions would be ones that have been thoroughly tested and that should generally perform best when requesting simple extractions. This reduces the necessity for users to manually configure commonly used extractions.
GOALS
The original document verification flow only allowed for users to configure custom extractions. We still want that support to exist and be just as accessible. However, we just want to now be able to surface this new extraction library alongside it. The intention here is to have builders gravitate towards these tried and true extractions, instead of manually configuring their own. The preference of wanting builders to use these “out-of-box” extractions is something very important to keep in mind.
CONSIDERATIONS
OPT-IN VERSUS OPT-OUT EXPERIENCE
The “out-of-box” extractions are meant to be highly requested suggestions, but not mandatory. This led to a very important driving question: do we want this experience to be “opt-in”, or “opt-out”?
Opt-in: When first configuring the document verification flow, the user will choose a specified Persona document type. Then, when configuring the extractions, the “out-of-box” extractions associated with the chosen document type will be suggested. They won’t automatically be attached to the verification. The user can choose to accept any or all suggested extractions (“opting-in” to the suggestions), or proceed with the usual configuration process and manually set up custom extractions.
Pros:
The user has full control and awareness on what extractions are set.
Possibility of confusion is minimized.
Cons:
We’re providing these suggested extractions because there is proven success with them. Opting-in can bring confusion around why these extractions are suggested but not enforced.
Considering how the intention of this project was to nudge builders to use the “out-of-box” extractions rather than creating their own (when possible), opt-in is less encouraging of that
Opt-out: When first configuring the document verification flow, the user will choose a specified Persona document type. Immediately, the “out-of-box” extractions associated with the chosen document type will be attached to the verification, by default. The user can choose to remove these extractions (“opting-out of the suggestions). The user can still proceed to manually add custom extractions as well.
Pros:
More aligned with the intention of this project.
Having suggested extractions attached to the specific Persona document type also helps the user better understand what that document is.
Helps provide more structure to the specific Persona document type.
Considering the “out-of-box” extractions are meant to be extractions that are commonly used on the associated Persona document, a lot of friction can be minimized with this option.
Cons:
The user may not be aware that these extractions are automatically attached.
Possibility that the extractions appear to be misleading (eg. confusion regarding if these extractions can be removed or not).
INITIAL ITERATIONS
After initial discussions on weighing pros and cons of opting-in/out, the team and I were leaning more towards opting-out. The main point here was to look at the intention of this project: “Out-of-Box Extractions” was built intending to simplify the process for very common verification configurations. Working in the direction of opting-out emphasizes the goal of simplifying this experience.
But before committing to the opting-out option, it made sense to attempt a few designs for both to ensure the decision was thoroughly thought through.
OPTION 1 (OPT-IN):
OPTION 2 (OPT-IN):
OPTION 3 (OPT-OUT):
FINAL DESIGNS
With the above reasons, it made most sense to finalize the designs with the opt-out option.
TAKEAWAYS
This was my first big design project after officially pivoting into design from software engineering. Consequently, my takeaways mainly revolve around "product-minded thinking". I learned a lot from just this project alone, and I would summarize my takeaways as follows:
Remember the intention of the project. When deliberating whether we wanted to do the opt-in or opt-out approach for the designs, the main factor that pushed us to finalize with the opt-out was recalling the intention of the project. It's easy to get distracted and overwhelmed by all the different approaches that the solution can take. But keeping in mind the technical goal of the project can help us stay grounded and recenter ourselves to find the most suitable solution.
Keep "deceptive pattern" designs in mind. In this project, we certainly prefer that our users use the "out-of-box" extractions instead of configuring their own, because the Persona library has guaranteed accuracy. The final designs here inform the user in many ways that they'll be interacting with suggested extractions, and this was an intentional decision to make sure users stay aware of the exact configuration they're building. Having our final designs be using the "opt-out" approach isn't an application of "deceptive design", but it certainly made me think about it. If the project intent was more malicious, it would be very easy for things to be snuck into a user's configuration without them knowing (eg. not giving any indication that they would automatically have suggested extractions). To re-iterate, this project is far removed from "deceptive pattern" practices, but working on it helped me learn that this is something to be very mindful of.