Assistente de Garantias — Turning consumer law into a component library

Overview

The Associação Portuguesa do Direito do Consumo (apDC) — a non-profit scientific society that congregates specialists in Portuguese consumer law — briefed our team to design a mobile app that would help consumers understand how product warranties work.

They arrived with a solution already in mind. We argued against it, and they agreed.

What we delivered instead was a guided-questionnaire app: you answer a short sequence of questions about your purchase, and the app tells you whether the product is still covered, when the cover ends, and which specific decree-law and article governs your case. You can save the result, and separately store your own warranties with a photo of the receipt and get notified before they lapse.

Underneath it sits the part I care most about showing: a reusable component library built with Atomic Design, a full style guide, and three complete visual themes — standard, dark, and high contrast — plus colour-blind coding across the whole navigation system.

How to read this piece

This project was never evaluated with users. No usability testing, no SUS, no task success measurement — the unit ended at the high-fidelity prototype and the timeline didn’t include a validation round.

There was a market survey, but it ran at the front of the process to gather requirements, not at the back to validate the design. It is not evidence that the interface works.

So this case study is about craft and systems, not about outcomes. It documents how a client brief became a structured product, and how that product became a component library that could be handed to a developer. Where I’d design it differently today, I say so.

The brief — and the case against it

apDC’s original request was a static repository: an app containing every decree-law and annexed piece of legislation relating to warranties, plus a directory of where to go to resolve a dispute.

We told them it wouldn’t work, for a reason that came directly from thinking about the user’s actual moment of need. Someone whose microwave has just died does not want a legal library. They have one question — “am I still covered?” — and a static repository answers it only if they already know how to read legislation. It converts a specific, urgent question into an unstructured research task, which is precisely the problem the app was supposed to solve.

Our counter-proposal inverted it: ask the user the questions a lawyer would ask, and return the answer plus the article it rests on. The legislation is still there — it just arrives at the end, as justification, instead of at the start, as an obstacle.

The association accepted the change. That conversation is the single most useful thing I took from the project, and it happened before a single screen was drawn.

Who we were designing for

We ran a market survey (n = 22, Google Forms) alongside a competitive analysis and a task analysis.

The sample is weak and I’m not going to pretend otherwise. It was distributed through the institute’s general mailing list, so it is a convenience sample of the Bragança academic community: mean age ≈24, 40.9% resident in the Bragança district, and skewed toward students — not the general adult consumer population the app was for. With n = 22, none of the percentages below should be read as population estimates. They were used as directional input to prioritise features, which is roughly the weight they can bear.

What it did tell us, clearly enough to act on:

Two of these shaped the product directly. Everyone wanted verification, and almost nobody was tracking dates — which is why the app has two distinct jobs rather than one: the quiz answers “am I covered?”, and a separate vault answers “don’t let me forget”. And 63.6% asking for simple and direct is the reason the final interface leans on colour-coded categories and short question sequences instead of a dense information architecture.

The competitive analysis (three apps: Código Defesa Consumidor – SLEX, Código Defesa Consumidor, Anatel Consumidor Mobile) found the category almost entirely Brazilian, aimed at law students rather than consumers, and — the opening we took — visually dated and largely inaccessible.

Structuring the product

Before any interface work, three artefacts turned the brief into something buildable.

Task analysis established what consumers do today: consult the legislation themselves, ask someone who works in the field, or pay for a consultation — all slow, and often with a cost attached. The desirable task was defined as reaching an answer fast, without cost or bureaucracy.

A conceptual model fixed the metaphor (assistant) and the object model — Product, Consumer, Quiz, Question, Administrator — with their attributes, the actions available to each, and the relationships between them. This is what made the app definable in one sentence rather than a wish list of features.

Six decision flows encoded the actual legal logic, one per situation type:

• Purchase of physical goods
• Purchase of digital content
• Contracting of digital services
• Unfair or fraudulent commercial practices
• Dispute resolution
• Warranty period verification

Each flow branches on conformity with the contract and terminates in the remedies available to the consumer — repair, replacement, price reduction, or contract termination. These are what the quizzes execute.

The navigation map then reduced the whole product to six destinations: Categories/Home, Saved, Warranty Vault, Notifications, Settings, and Report an Error.

The interface

The final high-fidelity prototype is organised around colour-coded categories. The home screen presents the situation types; picking one starts the relevant question sequence; the sequence terminates in a plain-language verdict with the governing article attached, which can be saved.

The decisions worth naming:

• Progress is always visible during a quiz. Legal questioning sequences feel open-ended, and an open-ended sequence with no visible end is a sequence people abandon.
• The Warranty Vault is manual, not automatic. The user enters the product and attaches a photo of the receipt; the app computes and notifies the expiry. Automatic capture would have needed retailer integrations the project had no route to.
• Terms and privacy policy live in drop-downs. Legally mandated content that would otherwise dominate the screen with text nobody reads at that moment.
• A dedicated error-reporting screen, on the reasoning that an app making claims about a user’s legal position needs an explicit route for “this looks wrong”.

The component library

This is the layer the rest of the project rests on, and the reason I still show this work.

The interface was built with Atomic Design: the smallest indivisible elements are defined first, combined into progressively larger units, and only then assembled into screens. Nothing on a screen is drawn directly — everything is an instance of something defined further down.

Alongside it, a style guide documents typography, the colour palette, icons, buttons and form elements as a single visual reference.

Why this was the right call for this specific project, not just good practice in general: the app has six situation flows that all share the same interaction shape — question, options, branch, verdict. Building those screen by screen would have produced six slightly different versions of the same thing. Defining the quiz card, the option button and the result block once meant every flow inherited the same behaviour, and a change to any of them propagated everywhere.

It is also what made the three-theme requirement below tractable at all.

One naming correction I’ll make explicitly: this is a component library with a style guide. It is not a design system — there are no design tokens, no naming conventions documented for handover, no usage guidance, no versioning, no governance model. The distinction matters and I’d rather draw it myself than have it drawn for me.

Designing for three themes and colour-blind users

The competitive analysis had found the whole category inaccessible. Rather than treat that as an observation, we treated it as the differentiator.

colorADD. Because the app navigates by colour-coded category, colour was carrying real information — which makes it a single point of failure for anyone who can’t distinguish it. We applied colorADD, the Portuguese colour-identification system created by Miguel Neiva, which adds a small graphic symbol encoding the colour itself. The categories remain distinguishable when the colour signal is unavailable.

Three text sizes. Small, standard and large, user-selectable — a baseline accommodation for reduced visual acuity that the component library made trivial to implement consistently.

Three complete themes. Standard, dark, and high contrast, each carried through every screen in the prototype rather than demonstrated on a sample. This is the clearest payoff of building on atoms: re-theming meant redefining the colour atoms, not redrawing 60 screens.

The honest caveat: the high-contrast palette is Windows’ default high-contrast palette, adopted under time pressure rather than derived from the product’s own colour system. It functions, and defaulting to a platform-tested palette is a defensible fallback — but it is a fallback, and it means the high-contrast theme is the one part of the visual system I didn’t actually design.

Limitations

Stated plainly, because most of these are visible to anyone who looks carefully anyway.

• No user evaluation of any kind. The strongest claim this project can make is that it was built coherently — not that it works. Every accessibility decision above is a reasoned accommodation, not a validated one.
• The survey cannot bear weight. n = 22, convenience sample, academic community, skewed young and geographically concentrated.
• The legal decision flows were not reviewed by a jurist. They were drafted from coursework in communication law with the assistance of a generative model, and checked against the legislation — but for an app that tells people what their legal position is, “not reviewed by a lawyer” is a material limitation, and a production version could not ship without that review.
• The high-contrast palette is borrowed, as described above.
• Contribution boundaries are blurred. This was a three-person team on a shared Figma file with genuinely collaborative sections; the UML diagrams were entirely Adelino Vieira’s work and the onboarding manual entirely Ana Costa’s, and neither is claimed here.

Learnings

• The most valuable thing I did on this project happened before any design work. Arguing the client out of a static legislation repository changed what the product was. No amount of interface craft would have rescued the original brief.
• Atomic Design earns its cost at the point of change, not at the point of building. Setting up atoms and molecules feels like overhead until you need three themes and three text sizes — at which point it’s the only reason the requirement is achievable inside the timeline.
• Accessibility is cheapest when it’s structural. colorADD and text sizing were near-free because the system was already componentised. The one accessibility decision I bolted on late — the high-contrast palette — is the one that came out worst.
• Building a complete system and never testing it is a specific failure mode, and recognising it is what changed how I work. Every project I’ve run since ends with an evaluation round, whatever else has to be cut to make room for it.