UI/UX and product design for software people have to use every day.

Get an interface your team adopts instead of working around. We research the work with the people who do it, design the flows, test clickable prototypes with them, and give your engineers a design system to build from.

Scope a design engagement How the work runs

Who hires us for this

Product leaders, founders, and operations heads who need software designed before or alongside its build: a product whose users complain, an internal tool nobody adopted, a new application that must be right for people who use it all day, or a team that has engineers and no designer.

Why now

The current product works and users still avoid it.
An internal tool was built and the team went back to the spreadsheet.
A build is about to start and nobody has drawn the screens with the people who will use them.

When companies call us

If this sounds like your business, here is where we start.

Users avoid the product and nobody knows why

Research with the users, the three changes that would matter most, and a prototype to confirm them.

An internal tool was built and not adopted

Observation of the work, a redesign of the daily loop, and a prototype tested with the team before the rebuild.

A new application is about to be built

Design as the first phase: flows and prototypes reviewed with users, then a design system for the build.

The product has grown inconsistent

A design system and a plan to bring the screens onto it, release by release.

A decision, not a pitch

Design first, design with the build, or redesign what exists?

Design is a phase, a partner to the build, or a repair. The right one depends on how far along the software is.

Consideration	Design first	Design with the build	Redesign what exists
Fits when	The application is new and the workflow is unclear	The workflow is understood and the build is starting	The software exists and people avoid it
What you get	Research, flows, prototypes, a design system	Screens designed a release ahead of the build	Findings, priorities, and a prototype of the fix
Then	The build, by us or your team	Working software as it takes shape	The changes, release by release

What this covers

What UI/UX and product design covers.

Research

Interviews and observation with the people who do the work, so the design starts from the job and not from a wish list.

Workflow and interaction design

The flows, screens, and states that fit the work: few steps, the next action obvious, the exceptions handled.

Prototypes

Clickable screens in front of users before anything is built, and the changes that come from watching them.

Design systems

Type, color, components, and patterns the build can carry through, so the product stays consistent as it grows.

Accessibility

Contrast, keyboard use, and screen-reader behavior designed in, not retrofitted.

Handoff and build

Specifications engineers can build from, or the build itself, on the same team.

Customer portalRequestsDocumentsAccount

New service request

Location Northgate · Unit 12

Issue Rooftop unit not cooling

PriorityUrgent

Photos

Submit request

Request 4187

SubmittedToday 8:12

AssignedCrew 2 · today 8:20

ScheduledThu 8:00

Completed

Recent requests

4187Rooftop unit not coolingTodayScheduled

4102Parking lot lightingSep 9Completed

4088Annual fire inspectionSep 2Completed

4071Loading dock doorAug 28Completed

Your requestRooftop unit · Unit 12Scheduled Thu 8:00Technician: crew 2

Assigned to crew 2

How the work runs

Scoped in writing, built in releases, handed over.

01
Watch the work
Interviews and observation with the people who will use the software, in the conditions they use it.
02
Design the flows
The daily loops, the screens, the states, and the exceptions, drawn and reviewed with users.
03
Prototype and test
Clickable screens in front of users; what they did decides what changes.
04
Build the system
Components and patterns the build can carry through, with accessibility designed in.
05
Hand off or build
Specifications for your engineers, or the build on the same team.

Deliverables

What you receive.

ScopeAgreed

First release · version 1.2Scope and acceptance

Includes: The core workflow, roles and permissions, and the first integration
Left for later: Reporting and the second integration
Acceptance: Criteria agreed with your team
Price: Fixed before the build begins
Start date: Agreed in writing

Approved by operations Approved by finance

RunbookHanded over

Operations · version 1.0Running the system

01Deploy a releasePipeline
02Roll back a releaseTested
03Restore from backupTested
04Alerts and who respondsCurrent
05Access and secretsBy role

Written scope
What the first release includes, what it leaves for later, the integration decisions, the acceptance criteria, and the price, agreed before development begins.
Release notes
What changed in each release, what was tested, what the security review covered, and how to roll it back.
Documentation and runbooks
How the system is built, how to run it day to day, and what to do when something fails.
Training and handover
Sessions with the people who will use and run the system, and a handover checklist your team signs off on.

Every release ships with tests, a security review, and documentation, so your team can run what we build.

Your first release

What the first release could include.

The scope is written and agreed before development starts. This is the shape it usually takes.

In the first release

Research findings from the people who will use the software
Flows and screens for the core loop, reviewed with users
A clickable prototype and what testing it changed
A design system: type, color, components, patterns, accessibility
Specifications the build can work from

Usually later

Screens for the next release, designed ahead of the build
Usability testing on the working software
Extending the design system as the product grows

Systems it may connect

Built to work with what you already run.

Figma for design and prototypes
Your existing brand and identity
Your product’s component library, where one exists
Analytics and usage data
The build, in our stack or yours

Logistics company

Dispatchers use the dispatch tool because its first screen matches how they plan a shift.

A dispatch tool can meet every line of its specification and still lose to the whiteboard, because the screen it opens on is not where a dispatcher’s work starts. Design work begins by watching dispatchers plan and reassign loads, then maps the loop they repeat most. The redesign puts the board first, keeps the next action within reach, and holds exceptions in view. Dispatchers test a clickable prototype before engineers rebuild anything, and the design system gives the build consistent components. Later screens are designed ahead of each release.

Where this shows up

Industries where we do this work.

Examples, not a closed list. We take substantial projects from independent businesses in other industries too.

Software companies

Ship the integration customers keep asking for, the mobile client, or the modernization your roadmap has no room for, while your engineers stay on the current release.

Technology-enabled businesses

The internal tools and customer-facing apps your service runs on, built by a senior team before you are ready to hire engineers.

Private equity portfolio companies

Software across the hold period, with a portfolio assessment for the fund and a delivery path for each company.

Another industry entirely

Describe the workflow and the systems around it. Fit depends on the work and the stakes, not the sector.

In plain terms

What is product design?

UI/UX and product design is the work of deciding what software should do for the people who use it and how it should look and behave: research, workflow design, prototypes, visual design, and a system that keeps it consistent. The interface is the product to its users.

We design for software people use all day: operations tools, portals, and products. The measure is whether the people who do the work use it, not whether it wins an award.

Questions

Questions about UI/UX and product design.

What buyers ask before a project starts, answered plainly.

Can we buy design without the build?

Yes. Research, flows, prototypes, a design system, and specifications are a complete engagement, handed to your engineers or another team.

Do you work with our brand?

Yes. Most engagements extend an existing identity into a product design system. Where there is no usable identity, we say so early.

How much research is enough?

Enough to watch the work being done by the people who do it. It is a focused effort, sized in the scope, and it changes the design more than any other activity.

What about accessibility?

We design for it from the first screen: contrast, keyboard use, focus, and screen-reader behavior, checked against the guidelines your customers expect.

Will the design survive the build?

That is what the design system is for. When we build, the same team carries it through; when your team builds, the specifications and components make it possible.

Can you redesign a product that exists?

Yes. Research first, then the changes that matter most, prototyped and tested before they are built, release by release.

Scope a design engagement.

Tell us about the work and the systems around it.
We’ll come back with a written scope for a first release.