Start a project

/02 Service

Product strategy & design

We help you decide what to build before you pay to build it. You get research, a clear scope, and tested designs, with each decision in writing.

/01 Problems and fixes

Where this work often fails, and how we prevent it.

  1. /01
    The problem
    The scope grows every week, because nobody recorded what the first release must contain.
    What we do
    We write a scope document that lists what is in, what is out, and why. You approve it before engineering starts.
  2. /02
    The problem
    The team builds from opinions, and users ignore a feature that took months to make.
    What we do
    We interview and observe real users before we design. Then we test clickable prototypes with them before anyone writes production code.
  3. /03
    The problem
    Designs show only the ideal screen, so engineers guess the error, empty, and loading states.
    What we do
    We design every state that a screen can show. Engineers get annotated files and acceptance criteria, not only pictures.
  4. /04
    The problem
    Screens become inconsistent over time, and users no longer see one coherent product.
    What we do
    We build a design system with tokens, components, and usage rules. Designers and engineers use the same source.

/02 Deliverables

What this service gives you.

You receive

  • A research summary with observed tasks and user quotes
  • A written scope with priorities and items out of scope
  • Clickable prototypes tested with real users
  • A design system with tokens and components
  • Annotated screens for every state, ready for engineering
  • A decision log with the reason for each choice

Typical work

  1. 01Product research and scope for a new product before the first build
  2. 02A redesign of an internal tool that staff find hard to use
  3. 03A design system for a company with several products
  4. 04A prototype to test a new workflow with customers
  5. 05A scope review for a project that is over budget

/03 Ways to engage

Three engagement models.

  • /01

    Do you have a defined project?

    Project delivery

    • One senior team from the first call to launch
    • A signed definition of done for every milestone
    • Working software to review every week
    • Handover to your team, or Ongoing ownership by ours
  • /02

    Do you need more senior engineers?

    Dedicated team

    • Engineers picked for your stack and your industry
    • Daily work inside your tools and meetings
    • A monthly check on fit and results
    • Monthly changes to team size, with notice
  • /03

    Do you have a system that must not stop?

    Ongoing ownership

    • An assessment of the system before we accept it
    • A fixed monthly budget and agreed response times
    • Security patches, monitoring, and on-call coverage
    • A written report every month

/04 FAQ

Questions clients ask first.

Do you have a different question? Ask us directly

Do we need this before a build?

Not always. If the scope is clear and you know your users, a short review is enough. If your team disagrees on the first release, product research costs less than a wrong build.

How long does product research take?

Most product research takes three to six weeks. The time depends on the number of user groups and the research that already exists. We agree on a fixed timeline before we start.

Can another team build from your designs?

Yes. We prepare each design for engineers who did not attend the design sessions. The files, components, and acceptance criteria are complete enough for any competent team.

/05 Related

/ Next step

Talk to us about product strategy & design.

Send a short note about your system and your constraints. We reply within one working day.

Start a project hello@aeontechnologies.io