Skip to content
Zimcrest Technologies — home
Chat on WhatsAppStart your build

Product design

Interfaces people can use on a bad day, on a bad connection.

Start your build

What's included

The work, and what you receive

Each capability names an artefact you end up owning, not an activity we perform.

Our approach

How this runs, and roughly when

Durations are bands, not promises. We revise them in the open when the work argues otherwise.

  1. 1

    Understand

    1–2 weeks

    Time with real users on their own devices. What they do now, and what they do when it fails.

    • Research notes
    • Task inventory
  2. 2

    Design the failure states

    1–2 weeks

    We draw the difficult states before the happy path, because the happy path largely falls out of that work.

    • State matrix
    • Wireframes
  3. 3

    Prototype and test

    2–3 weeks

    Two rounds of testing on a mid-range Android, with the findings and what we changed.

    • Tested prototype
    • Findings and changes
  4. 4

    Hand over

    1 week

    A component library and accessibility specification your engineers can build from without guessing.

    • Component library
    • Accessibility specification

Tools we use

Boring, well-supported, and replaceable

We tell you when something newer is worth its risk, and when it is not.

Related work

Where we have done this

Questions

Asked often enough to answer here

Yes, and on a mid-range Android specifically. A build that feels instant on a developer laptop can be unusable on a four-year-old phone on a congested network.

Yes. We would rather extend what you have than replace it, and we will say so if we think it needs replacing.

No. WCAG 2.1 AA is the baseline we design to. Retrofitting it later costs considerably more.

Working against a constraint?

Tell us what it is. We will tell you what we would build, what we would not, and what it would take.

Start your build