Quasarus
Start a project

Prototypes and interface design

A clickable prototype of the core screens, tested by the people who will use them, with the fixes made before developers start.

A screen can pass a design review and still slow your team down on a busy Monday. We design the core screens in Figma, fill them with sample records shaped like your data and link them into a prototype. The people who will use the tool then try set tasks while we watch. Where they hesitate, we change the screen before it goes to the developers.

For Founders, product leads and operations managers planning a web app or internal tool, who want their team to try it before paying for the build.

Brief us on this

You need this when

  • 01

    Your team signed off the mock-ups, then found the gaps once the tool went live.

  • 02

    Developers are deciding how screens work because nobody designed them.

  • 03

    Logging one order in your current tool takes several screens and a spreadsheet.

What’s included.

01

Screen flows

The path for each role through its main tasks, such as logging an order, moving a deal or closing the week.

02

Interface design

Core screens designed in Figma for desktop and phone, with tables, filters and forms laid out for daily use.

03

Clickable prototype

Screens linked so people can click through a whole task, using sample records shaped like your data.

04

Testing with users

Short sessions where the people who will use the tool try set tasks while we note where they stall.

05

Component set

Buttons, tables, forms and their empty, loading and error states defined once, so the build stays consistent.

06

Design handover

Annotated screens and specs the developers build from, with each decision written down.

How it runs.

1–4 weeks as a Sprint. Inside a Build, the prototype is ready in week 2, alongside the signed scope.

  1. 01 · Pick the core tasks

    We choose the few tasks each role does most often and design for those first.

  2. 02 · Design the screens

    Layouts in Figma, filled with sample records shaped like your real data.

  3. 03 · Test with users

    The people who will use the tool click through set tasks while we watch.

  4. 04 · Revise and hand over

    We fix what slowed them down and annotate the screens for the build.

Deliverables

  • Screen flows for each role
  • Figma files for every core screen, desktop and phone
  • Clickable prototype of the core screens
  • User testing notes, with the changes made
  • Component set with empty, loading and error states
  • Annotated handover file for the build

Works with

Figma

What buyers ask.

Why not let the developers design it as they go?

Then the first time your team sees a screen, it’s already built. A change to a prototype is an edit; a change to built software is rework.

Does a prototype replace the scope?

No. The scope says what the tool must do; the prototype tests how people will do it. We usually run both in the same Sprint, so what the testing shows can still change the scope.

Can you design screens for software another team is building?

Yes. We hand over annotated Figma files and a component set, and can join the developers’ reviews while they build.

Pairs well with

Let’s build your pipeline.

Tell us what you sell, who buys it and roughly what a customer is worth to you. We reply with questions, then a written proposal.

Start a project