ZECH
Specialist Services · Specialist

Product design that holds up once real users, real data and AI features arrive.

We research how people actually work, structure the product around those tasks, and prototype and test before build — including the harder parts of AI features, such as showing sources, uncertainty and what the system is about to do.

What we deliver
  • User research and task maps
  • Information architecture
  • Interactive prototypes
  • AI interaction patterns
  • Design system and handoff
Tools & platforms
FigmaStorybookMaze and moderated usability sessionsWCAG 2.2

Where this helps

Screens designed before the workflow was understood
The interface looks finished, but it follows the org chart or the database schema rather than the order people actually do the work. Training fills the gap, and support tickets follow.
An AI feature nobody trusts
The model output appears in a text box with no source, no confidence and no way to correct it. Users either ignore it or accept it without checking, and neither is what you wanted.
Every team builds its own buttons
Without a shared design system, each new screen reinvents spacing, forms and states. Accessibility fixes are made one page at a time and drift again with the next release.

What we deliver

01
User research and task maps
Interviews and observation with the people who do the work, summarized as task flows, pain points and the decisions the product has to support.
02
Information architecture
Navigation, content structure and naming tested with users, so people can find things without being told where they are.
03
Interactive prototypes
Clickable prototypes of the key flows, tested with representative users before engineering starts, with findings and changes written up.
04
AI interaction patterns
Designs for how AI output is shown, cited, corrected and approved — including loading and streaming states, confidence cues, source references and handoff to a person.
05
Design system and handoff
Tokens, components and usage guidance built in your design tool and matched to code, with accessibility requirements documented per component.

How it works

  1. 01

    Discover

    We review analytics, support themes and existing research, then interview and observe users to agree which tasks matter most.

  2. 02

    Structure

    Task flows and information architecture are drafted and checked with card sorting or tree testing where the structure is uncertain.

  3. 03

    Prototype and test

    We prototype the priority flows and test them with users in short rounds, changing the design between rounds rather than after launch.

  4. 04

    Systematize

    Validated patterns become components and tokens in a design system your engineers can build from.

  5. 05

    Support the build

    Designers stay with the engineering team through implementation, reviewing built screens and resolving edge cases as they come up.

Design decisions we make with you

  • Research depth

    How much research the project needs depends on how well the current workflow is understood. We scope it to the open questions, not to a fixed method.

  • Accessibility target

    We design to WCAG 2.2 AA by default — color contrast, keyboard paths, focus states and screen-reader labels are specified, not left to the build.

  • How much the AI does on screen

    Whether AI output is a suggestion, a draft for review or an action taken on the user's behalf changes the interface. We decide this with the product owner before designing it.

  • Design system scope

    A full system is not always worth it. For a single product we may start with tokens and core components and grow the library as patterns repeat.

Questions buyers ask

Both. We can hand off a design system and prototypes to your engineers, or design and build with our own web application and mobile teams.

AI output can be wrong, slow or partial. The interface has to show where an answer came from, what the system is unsure about, and how a person corrects or rejects it — and it has to handle streaming and failure states that ordinary screens do not.

Yes. We usually start by auditing what exists, keep what works and extend it, rather than replacing a system your teams already use.

Discuss this capability with an engineer.

Tell us about the workflow or product. We reply with questions, a suggested first step and who would work on it.