Giulia
← All work

Case study · Design process · AI

AI design process
powered by context

Smart Line Balance is a Getter platform that helps factories balance their production lines. I joined as one of two designers and, together with the other designer, structured a way of working in which AI builds the prototypes, the team validates them with the client, and developers receive a specification they can read on their own or through AI.

Company
Getter
My role
Product Designer, one of two
Year
2026
Tools
Generative AI, Figma, Git

Outcomes in the first two months

2 days From client approval to development
~3 h From a request to a first clickable prototype
4 of 7 Prototypes handed off without a handover meeting
1 day From stakeholder feedback to an updated prototype
01 The challenge

Speed without drift

In the factories Smart Line Balance serves, the process engineer balanced the line by hand in a spreadsheet, spending 30 to 45 minutes at the start of every shift moving people between workstations. The product had to replace that routine with calculation and AI suggestions, and the team needed to validate each flow with the client before any code was written.

Generative AI made prototypes fast to produce. Produced in isolation, however, they drifted: each one duplicated styles, departed from the Design System and carried its own copy of rules that were already out of date. With two designers and several features in parallel, speed was turning into inconsistency.

The core insight

AI is only as good as the context it reads.

Instead of better prompts, we invested in context: one documentation for the whole platform, product requirements written to be read by people and by AI, and prototypes built on shared parts of the Design System.

The process, end to end
  1. 01 Requirement Documentation

    The feature page defines the flow, testable requirements, states and exceptions, and open points.

  2. 02 Prototype Generative AI

    Generative AI reads the documentation and the Design System and builds a clickable prototype.

  3. 03 Validation P.O. and client

    The prototype is reviewed in context. Every decision is recorded in the documentation before the prototype changes.

  4. 04 Handover Status

    When approved, the prototype moves to 'In development' and becomes the reference for the front-end team.

New decisions return to the documentation

02 Single source of truth

One documentation every area feeds

We created a single documentation site for the whole platform. Developers maintain the technical documentation and architecture, the product team and designers maintain the requirements and the Design System, and there are guides so that non-developers can contribute. We considered a shared drive, but chose plain text files under version control: every change is reviewed, the history is kept, and the content is lighter for AI to read.

  • Product requirements Product, users, glossary, business rules, decisions and one page per feature
  • Design System Principles, accessibility, content, tokens, components and patterns
  • Technical documentation Architecture, decision records and AI agents
  • User manual and guides For end users and for contributors who are not developers

Anatomy of a testable requirement

Requirement: Accepted file formats

The system MUST accept .xls, .xlsx and .csv files in the template defined by the client.

Acceptance criterion: File in an accepted format

  • GIVEN the user is on step 1 of the import
  • WHEN the user uploads an .xlsx file in the client's template
  • THEN the system reads the file
  1. One format for everyone

    MUST, MUST NOT or MAY, with acceptance criteria in GIVEN / WHEN / THEN. Developers, QA and AI read the same sentence the same way.

  2. Errors are not an afterthought

    Each feature walks through a checklist of states and exceptions: invalid input, empty data, unavailable integrations, conflicts, permissions and destructive actions.

  3. Proposals are not rules

    Anything unconfirmed enters as 'Proposal' and an open point. It only becomes a requirement after someone responsible approves it.

  4. Checked automatically

    An automatic check validates the structure of every page, the testable format and the glossary terms before any change is accepted.

Rules we wrote for the AI

  • Read before proposing product, users, glossary, the feature page, business rules, decisions and the Design System.
  • Do not invent a missing rule is flagged as a gap; an assumption is stated as an assumption, never recorded as a rule.
  • Reuse the Design System first a new component needs a reason and the designers' approval.
  • Accelerate, do not decide the AI's role is to speed up the exploration of solutions, not to replace the designers' decisions.
03 Prototypes and handover

Prototypes that stay consistent

The prototypes got a home of their own. Each one opens in any browser, but the tokens, components, navigation and header of the Design System live in shared parts that every prototype uses. An automatic check flags any prototype that drifts. When we changed the typography scale, every prototype was updated at once.

  1. Shared parts

    Tokens, components and navigation in one place, kept in sync and checked automatically.

  2. Specification inside the prototype

    Each prototype opens its own design specification, with flow, scenarios, errors and open points, written for people and for AI.

  3. Proposals to validate

    Hypotheses the prototype assumed appear in a panel, so the P.O. knows exactly what still needs a decision.

  4. Two brands, two themes

    The same prototype switches between the Getter and the client brand, in light or dark mode.

The same prototype in the dark theme. Colours and components come from the shared Design System parts, so every prototype switches the same way.
The same prototype in the dark theme. Colours and components come from the shared Design System parts, so every prototype switches the same way.

Handover became a status

Every prototype shows its stage in a bar at the top, with a dated history and who to ask. Developers no longer need a handover meeting to know what is ready.

  1. Draft

    Still being made. Not shown to stakeholders.

  2. In review

    Being validated with the P.O. and stakeholders. May change.

  3. Ready for dev

    Approved by the P.O. The reference to implement.

  4. In development

    The front-end team is building it. Changes only by agreement.

  5. Archived

    No longer a reference.

A real prototype's history In review In development

Two designers, one base

The other designer and I worked on separate proposals over the same base, one improvement at a time. We compared the alternatives side by side in a meeting, and only then did the decision enter the documentation and the main prototype. On one of the most complex screens, that meant about 40 proposals reviewed one by one.

04 Validation and result

Decisions go to the documentation first

Because every prototype reads from the same source, validation feedback changes the documentation, and the prototypes follow. Two moments from the validation rounds show the cycle.

A prototype generated from the documentation: the flow, the states and the Design System components come from the same source the developers read.
A prototype generated from the documentation: the flow, the states and the Design System components come from the same source the developers read.
A prototype one day after a stakeholder session: the feedback went into the documentation first, then onto the screen.
A prototype one day after a stakeholder session: the feedback went into the documentation first, then onto the screen.
Client feedback

A new business rule, raised by the client during validation.

It became a requirement in the documentation, with a decision record, before anyone touched the prototype. The screens changed only after that, and the developers read the same rule.

Stakeholder session

A round of changes requested in a review meeting.

The decisions went into the documentation and the AI rebuilt the prototype from it. The next day there was a new version to review, already consistent with the Design System.

What did not work

  • Trusting the AI without limits: It changed files it should not have touched and reported work it had not done. Its limits now live in written rules.
  • Prototypes generated in isolation: The AI duplicated styles and left the Design System. Shared parts solved it.
  • Requirements copied into the prototypes: They went out of date. Requirements now live only in the documentation.

Key takeaways

Generative AI produces consistent prototypes when it works on shared parts, written rules and a single source of requirements, not on isolated requests.

  1. Documentation is the design tool.

    The time spent structuring requirements was not overhead: it is what allowed a prototype to be generated in hours and validated in days. The better the context, the less the AI needs to guess.

  2. Write for two readers.

    Every page is read by people and by AI. Testable requirements, a glossary that forbids synonyms and explicit open points serve both, and they also remove ambiguity between designers, product and engineering.

  3. Keep decisions human.

    The AI proposes, records assumptions as assumptions and never turns a suggestion into a rule. Those limits only hold when they are written down.

  4. Prototype with real-size data.

    Filling prototypes with data at the client's real scale revealed layout problems that a small sample would have hidden, before any code was written.

← All work More cases coming soon