Project Overview

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.


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







Adobe Firefly


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

Nothing comes for free.

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.

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.

Using the Design Thinking Framework

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



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

Growth as a Designer

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:

  1.   if there’s even a need for this tool
  2.   market fit
  3.   potential pitfalls in a product concerned with data privacy

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.

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

Key Insights from the Research

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:

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:

Crazy 8s

Sitemaps, User Flows, IA

Paper Wireframes & Reverse Engineering

Digital Wireframes

Thumb Zone Considerations

An Unexpected Snag

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:


  • Difficulty completing the “Review” feature user flow
  • Confusion around the terminology used in the copy, labels, and names of app features
  • Pain points while changing the format of the summary page
  • Need for more instructions about how to initiate auser flow or use the app
  • Navigation redundancies between the home page and fixed bottom menu bar

This led to the following insights:


  • Only 50% of participants successfully completed the “Review” user flow. This suggested that more instructions (such as visual prompts, a tutorial, or a step-by-step series of screens) were needed to help users initiate and complete the flow.
  • It was observed that 4 out of 5 users were confused by some of the language and terminology in the app. This indicated simpler, clearer language that users are familiar with from other tools might be more helpful than idiosyncratic, branded terms.
  • Nearly half the participants did not understand that they had successfully changed style settings on the summary page. This meant adding confirmation or visual feedback that immediately shows a change in the summary could help users use this tool more effectively.
  • Around 40% of users commented on navigational redundancies between the home screen and bottom navigation bar, and at least one participant was very confused by this. This suggested simplifying the home screen’s navigation options might improve the user experience.

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:

A New Homescreen

A/B Testing

Color Palette Iterations

Try the Figma prototypes:

Takeaways and Next Steps

Leveling Up in Figma

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.

Missteps with the responsive 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.

Better Research  =  Better Designs

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.

Next Steps

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.