Caveat is a conceptual project for an AI-powered tool that helps people understand legal agreements such as terms of use and privacy policies before they sign and agree to them.
The ultimate “TL;DR” app, Caveat integrates with web browsers and mobile devices to summarize and demystify dense legal language for users.
I developed the concept for this product and worked as the sole designer. It was created as a capstone project for Google's UX Design Professional Certificate.
Timeline
April 2023 -
June 2023
My Role
Lead Designer
My Contributions
Created concept and led project direction
Built hi-fidelity prototypes
UX and UI design for cross-platform product layouts
Generative and user research with a focus on in-depth user interviews
Evaluative research with usability testing
Tools Used
Figma
Mural
InDesign
Illustrator
Photoshop
Midjourney
Adobe Firefly
Notion
Optimal Workshop
Caveat offers several ways to input a document or chunk of text. It analyzes the text, provides a summary, and flags potential privacy, use, or data concerns.
It aims to increase transparency about products, decode legal jargon into plain language, and empower people to make informed decisions about what tradeoffs they’re agreeing to in exchange for using digital products
How many of us take the time to read through the legal terms and conditions we aree to every time we sign up for a website, download an app, or update a piece of software?
Contracts are often written as dry, jargon-filled, lengthy documents that can be challenging for a layperson to understand at first glance.
We’re often asked to sign and agree to these contracts in the middle of a task, such as signing up for an account or while downloading a product.
If a task is time-sensitive, such as updating software that we need at work, we may feel there’s no choice but to accept.
.png)
The Solution
A dedicated app and responsive website that allows users to easily scan and analyze agreements while in the middle of a user flow.
Caveat can be used to read and summarize a document via a web browser extension, user input via hyperlinks or copied plain text, or by uploading text-based documents such as PDFs or RTF files.
The app and website will utilize Chat GPT4’s API to generate succinct, digestible summaries of user input.
The product allows users to select filters, which will be added to the AI prompt and flag specific privacy, data, or legal concerns if they exist within the document.
Caveat was a non-existent and hypothetical product, so sitting down to design it from the ground up — even to define it clearly for other people — felt like a daunting task despite the clear vision in my head.
I needed to see who else was already attempting to solve this problem. Most importantly, I needed to talk to people.
I followed a version of the Design Thinking framework, with an emphasis on research and discovery to define the core design problem and understand the platform-specific needs of the product.
01 Research
user interviews & surveys
market & exploratory research
persona building
experiments with Chat GPT4
learning about existing legislation
02 Problem Definition
"how might we" statements
planning a mobile-first approach
03 Ideating solutions
competitive audit
crazy 8s
information architecture
wireframes
mockups
color palette ideation
reverse engineering existing products
04 Prototypes & Testing
lo-fi prototypes
hi-fi prototypes
usability testing
05 New Iterations
updated mockups & user flows
building component libraries
revised prototypes
final mockups
This project was also an opportunity for growth as a designer. Here's what I did differently on this project:
Robust Research with User Interviews
I placed greater energy into conducting qualitative user interviews. It was essential to have meaningful conversations with people instead of relying solely on survey statistics to understand:
In previous projects, I'd relied on user surveys as an inexpensive way to reach a broader group of participants, but this project showed me how interviews yield much higher-quality responses.
Developing a Design System and Component Libraries
The need for a design system became clear early in the design phase.
One of the key features I was exploring in the product was filtering information with the use of buttons that almost appeared like flairs on forums or clickable labels.
Keeping track of the permutations of these filters across different pages was essential even in the wireframing stage, so I created and maintained a design system from very early on.
Has This Already Been Solved?
I wondered why more products like this didn’t exist. Was there no need, no desire?
I needed to do discovery research and learn about any existing solutions to this problem.
Research Plan and Methodology
I created a research plan that aimed to incorporate a mix of primary and secondary research methods.
Then, the next logical step was to have conversations with real, potential users.
Generative Research with User Interviews
Next, I conducted 1:1 interviews with seven participants using a set of 10 questions (with a few follow-ups for certain respondents).
My questions were designed to get people thinking and talking about their notions of privacy, data, and the way they consent to exchanging their data. Each interview was conducted over the phone and lasted around 30 minutes.
The greatest weakness was the sample group’s lack of racial and socioeconomic diversity. Ideally, I would have had an opportunity to speak with two to three more people representing BIPOC communities as well as a wider range of socioeconomic categories.
"I don't like reading legalese. It gives me a headache.”
"I'd like my privacy respected, but the reality is I’m not that vigilant with protecting it.”
"If it’s not a Fortune 500 company, I do not trust them with my data.”
— Participant #1
— Participant #4
— Participant #6
1. End-user agreements (EULAs) are too lengthy, dense, and time-consuming
2. Almost everyone dislikes "legalese"
3. People don't feel they have a real choice
Almost no one reads them when accepting agreements for digital products and services.
There's a definite market and demand for help translating legal jargon into plain language.
Most participants reported feeling they had no choice but to accept EULAs, particularly when using products for work.
4. Existing legislation on data privacy isn’t well publicized
5. People don't trust AI products yet
6. EULA's present accessibility challenges
Almost none of the participants were familiar with the EU’s General Data Protection Regulation (GDPR). Only the permanent resident born outside the U.S. had heard of it. No one I spoke to was familiar with the California Consumer Privacy Act (CCPA).
The majority of interviewees and survey participants share concerns and trepidation around the use of AI, but almost everyone believes it’s here to stay.
Reading dense agreements on a digital screen can be challenging from an accessibility perspective and was cited as an issue by a couple of older participants.
Next Steps with Research Findings
After synthesizing the research findings, I defined four key user groups.
Although I typically believe user archetypes can be more useful than personas, in this particular case, the detailed concerns of each user group were helpful to keep in mind while designing the product.
Click on a persona to view it in full resolution.
Dialing in the Product Definition
With a better understanding of existing pain points and user groups, it was time to narrow down the product definition and immediate design problem to tackle.
I did this through a mix of competitive analysis, technical experimentation, and project planning to be able to articulate problem statements.
Read about each below:
Competitive Audit
I bridged this transition from research to product definition by conducting a competitive audit to see what, if any, other solutions tried to address the problem Caveat is tackling.
Experiments with ChatGPT4
I experimented with promptcrafting to see how well ChatGPT4 could execute summaries in varying degrees of complexity and for different reading levels.
I identified specific phrases in prompts that could reliably create consistent results.
Planning a Mobile-First Approach
I decided to approach designing Cavet with a mobile-first process using progressive enhancement.
Caveat's purpose is to process large amounts of information and simplify that data into concise, digestible/bite-sized summaries.
So, figuring out how to elegantly display large amounts of information on a small mobile device was going to be the biggest challenge.
How Might We Statements
Finally, I wrote several “How Might We” (HMW) problem statements.
Some HMW's focused on the overall product, and a few were specific to the mobile app I knew I'd design first.
Beginning to Ideate
I began ideating on solutions using a combination of exercises, including mapping information architecture (IA) and user flows, sketching with Crazy 8s and lo-fi wireframes, and reverse engineering wireframes for existing products.
Read about each below:
I began the ideation process with a loose Crazy 8s sketching exercise to start visualizing initial, rough ideas for basic features and potential pages the app might require.
I find Crazy 8s is typically a sobering exercise in which the images that felt pretty great in my mind’s eye immediately fall apart, and I start spotting potential design issues and obstacles.
In this case, it illuminated a few key features likely needed in this app:
ability to adjust the length and level of detail in document summaries
a filtering system that gives users a way to highlight specific areas of concern
choice between copying/pasting text, pasting a URL, or uploading a file (such as a PDF)
an alert or notifications system that flags any questionable areas in a legal agreement
a collection of agreements already reviewed
I created sitemaps that laid out the app and website's information architecture. This exercise also explored which features were essential and which were “nice-to-haves” that could live on the website but weren’t necessary for mobile app functionality.
I also sketched rough user flow maps to better visualize the product's structure and potential user journeys in the app. Three key flows were the "Review" flow to analyze a document; the "Constitution" flow in which users set their areas of concern and summary display preferences (similar to a "My Account" section); and the "Agreements" flow where users view documents saved in their library.
This helped me identify several screens I would need to create, including file selection screens, upload confirmations and error messages, and operating system-specific export option overlays.
I started playing with ideas for specific screens by drawing rough paper wireframes that compared at least three versions of a page:
Potential home screen layouts
Options for the document input page
Options for the summary page
Options for the "My Agreements" layout
I also did a reverse engineering exercise in which I created wireframes for Grammarly’s existing app, since it shares some functions with Caveat in terms of inputting text and receiving alerts.
Being able to compare those wireframes with my own sketches helped me think about additional design options, such as:
Wireframes of Grammarly's existing mobile app screens
After highlighting the best elements in the rough wireframes, I refined them in cleaned-up versions for a couple of the big “Review” and “Constitution” user flows, for the summary outputs that would be shown to users after entering text or a document, and for the “Alerts” and user “Account” pages.
Turning the original "Build My Constitution" sketch into two more refined options
Sketching out the primary user flow
Polished sketchs of other screens, such as "Alerts" and "My Account"
I translated the wireframes to a digital format in Figma. This part of the process often encourages new ideation for me. I typically replicate the paper wireframes faithfully, then go to town iterating on more nuanced design ideas since screens can be copied so instantaneously and displayed side-by-side with the first idea.
It was during this process that I landed on a few key changes to the Document Summary page, which is supposed to be the calm, legible, easy-to-process page that outlines the major points of whatever text you submitted.
Evolution of the Summary Page, where users receive a concise report about the EULA or document they submitted.
Something I wanted to be cognizant of early on in the ideation process was designing key functions in the app to occur comfortably in “the thumb zone,” or the area in which users can most easily reach their thumb while holding a mobile device with one hand.
The thumb zone was one of the key reasons I decided on a fixed bottom menu for the app’s navigation. I also tried to keep all the CTA buttons and key navigational elements in the user flow in the green, or comfortable, thumb zone.
I felt this addressed several use cases that emerged repeatedly in user interviews in which several participants imagined using this functionality on the go or while multitasking at work.
As discussed earlier, I focused primarily on the mobile app first knowing this was the smallest screen with the most crucial functionality needs. If I could solve the challenge of fitting such high volumes of information on the smallest mobile screen, I was sure progressive enhancement to larger screen sizes, including a mobile web browser screen, tablet size, and full desktop resolutions, would be a cinch.
This didn't go as smoothly in reality as it did in the planning phase.
Learning from Inadequate Planning and Skipping Steps
I had to rethink the navigation for the mobile web browser. Even though I’d worked with responsive websites before, I’d been so focused on the dedicated mobile app that it took me a minute to remember the mobile web version would need a different type of menu for smaller breakpoints.
Perhaps this was because I skipped ahead to the desktop webpage instead of incrementally sizing up in screen size order, from the mobile webpage to tablets to desktops.
More Research to Address the Problem
I ended up completing a second, informal competitive audit of a few information-heavy websites (Mailchimp, Credit Karma, the National Park Service, and Typeform), looking particularly at the navigation and layouts they used.
This, in turn, forced me to think about the different use cases of the website from the mobile app. What exactly was its function?
Earlier in the ideation process, when I’d created sitemaps to explore the information architecture for the web version vs. mobile app, I knew the web version could and would contain more educational resources. This helped me realize that the website would also be the most likely introduction to the product; users would probably encounter it first before deciding to download the mobile app or a browser extension. It needed to explain and sell the product and demonstrate how it worked.
My Solution
I decided on a tiered layer cake layout for the Home Page that emphasized an explanation of the product, invited users to use a demo, and hinted at Caveat’s core features in graphic cards with illustrations positioned just above the fold.
If users were inspired to keep scrolling down, they found bite-sized information in columns with illustrations to break up big chunks of text. The home page also suggested use cases to help people imagine themselves using the product, followed by two more CTAs: the first advertising premium features, the second inviting, once again, users to try the product for free.
The remaining pages, I realized, functioned more like search and encyclopedia pages, so for those I modeled them off a multi-column layout more akin to Wikipedia, which I imagined most users would find familiar.
Usability Testing with a Lo-Fi Prototype
With the first iteration of digital wireframes complete, I created a lo-fi prototype in Figma to test the dedicated mobile app’s design.
When describing this product to both the design community and to my research participants after the interviews were complete, I realized the concept was abstract to certain users until I explained and verbally illustrated potential use cases.
In order to clarify the idea and move it out of the realm of abstraction, I wanted to create a prototype that included more interactive details and components, such as toggle switches and form fields that changed with clicks and buttons. I felt it was important for users to play around with these features to understand the product, even in the lo-fi phase.
Usability Test Results
The results of Usability Test #1 were sobering: only 50% of users could complete the flow being tested. I’d underestimated the challenge of introducing people to a new, basically non-existent product. The designs needed a lot of work.
Themes and Insights
The following themes were identified in feedback from the usability test:
Themes
This led to the following insights:
insights
Faulty Assumptions
The following themes were identified in feedback from the usability test:
I had brought assumptions into the first round of ideation and took for granted that I could design for Jakob’s Law (a principle devised by Jakob Nielsen that states that users spend most of their time on other sites, so they prefer your site to work the same way as all the other sites they already know).
To be clear, Jakob’s Law was still a highly relevant principle that influenced some of my design choices, such as navigation with the fixed bottom bar, icons, and UX copy. My instinct was that incorporating these time-tested elements would help users feel comfortable in an unfamiliar product.
But for a product with few existing parallels, Jakob’s Law isn’t necessarily at play in the same ways. The user flow in this product wasn’t familiar the way an e-comm or food app checkout process might be, because it’s an activity most users have not done before.
It was clear that I needed to introduce people to the concept behind the app and guide them into the user flow with a more obvious call to action, clearer instructions, and perhaps even a tutorial.
With my prioritized insights from evaluative testing in hand, I made targeted changes to each area of the mobile app and website.
Read more about a few major iterations below:
Focusing on this problem of how to more clearly invite users into the flow, I created a new version of the Home Screen.
I also expanded the user flow across more screens. My first instinct in Draft 1 of the digital wireframes was to simplify actions and reduce the number of pages users had to navigate through.
But the usability test pretty thoroughly debunked this instinct.
I tried a new version that led users through a series of two steps:
Step 1: pick your format (a URL, text, upload a doc, or review an app)
Step 2: enter whatever data is needed based on that input method
User flow V1
Revised user flow V2, with step-by-step instructions
Key changes to the wireframes in Iteration #2:
Another piece of feedback I received from the usability test was that users didn’t understand that they were successfully changing the way summaries displayed when they toggled between “Summary” and “Bullet List” formats or changed the length from simple to medium or detailed.
This was because the “Alerts” section in the wireframes took up all the space above the fold, forcing users to scroll down to view the content. There were also no headings indicating the type of content being displayed.
I changed the Alerts section to a collapsible accordion-style menu that was set to a collapsed display by default (so, if users wanted to view the alerts, they could expand the menu, but they weren’t being forced to view the alerts).
This new style also allowed a new, added summary description to be visible without users having to scroll down. This descriptive heading would change instantly as users toggled view options, providing real-time feedback of how user input was changing the data output.
A/B testing revealed an improved user experience: all five participants found the updated design clearer and easier to scan.
Option A
Option B
4 out of 5 participants preferred Option B
I also used A/B testing to decide on the format for the Constitution page, where users set the type of alerts they’ll receive and adjust the default summary displays.
I had played with the idea of using buttons on this page that could be selected or deselected, but after A/B testing, 4 out of 5 participants preferred toggle switches. They felt the toggles more clearly indicated selections, and older users in particular found the toggles easier and more legible.
Later, when I was creating hi-fidelity versions of the mockups, I iterated on color combinations for the home screen.
Ultimately, after asking for critiques and feedback on the options, I chose a WCAG-compliant olive green as the primary color for headings and CTAs. Some of the feedback I received indicated the options using more orange echoed warnings and alerts, creating a sense of anxiety too early on in the user flow.
This project ended up being a watershed moment for me in understanding the power of Figma’s components, especially how to use variants, instances, and some of the prototype settings to create if/then instances in the prototype. Keeping all the variations of platform screen size organized also necessitated developing a design system.
What I’d do differently: next time, I plan to keep my Figma workspaces and design kits tidier on separate pages from the mockups, especially components with prototype functionality. I definitely lost some time in the prototyping phases by not keeping versions of components better separated from wireframe and mockup iterations.
2024 Update: If I were to redo this project, I'd also improve the visual design of the UI.
Since completing this project for the Google UX course, I feel my aesthetic sensibilities have changed and improved quite a bit. I would approach the visual design differently with much more negative space and padding around objects, a clearer separation of sections and headings, and cleaner, simpler button design.
As stated above in the “Unexpected Snag” section, I didn’t follow a logical progression in screen sizes.
In some ways, it was helpful and refreshing to jump from a dedicated mobile app to the full desktop resolution: it allowed me to reset and play with the polar opposite of the small-scale design I’d been poring over. But it ultimately cost me some time and required additional research.
What I’d do differently: in the future, I would increase the scope of my initial research to cover both web and dedicated mobile design needs, with an emphasis on platform-specific competitive audits.
Despite the missteps discussed above, this project necessitated more in-depth and higher-quality research than I’d previously had an opportunity to do.
Even though I conceptually understand the importance of quality research, I was still impressed by just how nuanced and helpful user interviews were. Every conversation expanded my view and revealed blindspots in my own thinking.
I came out of the research phase with an entirely more comprehensive (yet specific and actionable) sense of product needs than I would have had I just attempted a design completely on my own, without feedback.
The next design spring for this product would focus on the UI for the web browser extension.
I do have a longterm timeline to ship a working version of Caveat, so I am currently learning how to implement ChatGPT through an API and researching how users could securely input data in personal or work contracts without it being stored beyond a user’s device.
