CutLoc
Engage
Engineer inspecting a locomotive in an industrial rail workshop
Requirements and adoption specialists

From strategy to software in use.

We lead discovery for the front end, the back end, and the data, and we design the UI/UX around how people do their work.

CutLoc works between the strategy firm and the build team, and we keep the build matched to the recommendation until people are using it.

See how an engagement runs

Our commitment

We set the usage floor with you before the build starts: how many intended users work in the system, and how much of their work runs through it, by an agreed date. We stay engaged until the floor is met, and we treat go-live as one milestone on the way there. If the scope or the rollout changes, we reset the floor with you in writing.

01Why builds drift

Where the build drifts

A program starts with a clear recommendation. Then come hundreds of small decisions, and each one makes sense to the person making it. Somewhere along the way the build stops matching the recommendation, and every stage gate still clears.

The executives who sponsor a system and the people who use it every day usually want different things, and neither group can always say exactly what they need. On many programs, leadership sets the direction early, and the people doing the work see the system for the first time in training.

Design then starts from process diagrams and assumptions about users, so the workarounds people rely on are missing from the screens, the systems, and the data model. The system ships and works, and people go back to the spreadsheet.

02Strategy

What we mean by strategy

Strategy, for us, means three things we settle with the sponsor before anyone designs a screen: the outcomes the business is paying for, the people who have to change how they work to deliver them, and the limits the build has to respect, such as the budget, the timeline, and the systems already in place.

We write all three on one page, the sponsor signs it, and every design decision after that can be checked against it. Micah Canfield leads this work on every engagement, through the discovery process described below.

03What we do

Requirements for every layer of the build.

CutLoc is a team of requirements specialists who lead discovery for the screens people use, the systems behind them, and the data both depend on, so the build team starts from requirements that match the way people work.

Front end: UI/UX

Design the screens people will use

Your client wants to see the design, and the people who will use it are usually the last to be asked, so we start with them. We design each screen around the decisions users make and the order they make them in, and we test every screen as a clickable prototype before it reaches the backlog.

  • User interviews and shadowing
  • Decision sequences and user journeys
  • Clickable prototypes
  • Usability testing with real users
  • Design approval by sponsor and users
  • Outcome

    Maintenance planners schedule every work order in the new system.

  • Requirement

    Rescheduling a work order takes fewer steps than it does in the spreadsheet.

  • Feature

    Drag-to-reschedule on the planning board.

  • Measure

    Share of work orders scheduled in the system, reported weekly.

  • Cut

    Export to spreadsheet, because it would send the work back where it started.

Illustrative example.

Back end: systems and integration

Specify the systems behind the screens

A screen that looks right can still fail when the systems behind it follow different rules. We write the requirements for the business rules, approvals, interfaces, performance, and access behind each screen, and we check each one with your build team before it enters the backlog.

  • Business rules and exceptions
  • Interfaces with existing systems
  • Approvals and access by role
  • Performance and security requirements
  • Feasibility checks with the build team
  • Outcome

    Buyers get approval on a purchase the same day they submit it.

  • Requirement

    A purchase routes straight to the approver named in the delegation of authority.

  • Feature

    Rules-based routing between the buying screen and the approval system.

  • Measure

    Median time from submission to approval, reported weekly.

  • Cut

    A separate approval portal, because approvers would have one more place to check.

Illustrative example.

Data: sources, definitions, and quality

Get the data right before anyone builds on it

Many arguments about a new system turn out to be arguments about data, with two teams reading two versions of the same number. We find where each number comes from, who owns it, and what it means to each group, then specify the data model, the definitions, the quality checks, and any migration from the old system. When a program needs it, we also help design and manage the database itself.

  • Data sources and owners
  • Shared definitions for key terms
  • Data model requirements
  • Quality and migration rules
  • Database design and management support
  • Outcome

    Buyers and planners work from the same inventory number.

  • Requirement

    On-hand inventory uses one definition and one source across every screen and report, refreshed at an agreed interval.

  • Feature

    A shared inventory definition in the data model, with the source shown beside each figure.

  • Measure

    Share of planning decisions made without a manual spreadsheet check, reported weekly.

  • Cut

    A second inventory report built for one team, because it would bring back a competing number.

Illustrative example.

04How we work

Three stages, each with a defined end.

When CutLoc starts work with a client, we first find where the project sponsors and the end users want different things from the system. We close that gap by interviewing each group about how the work gets done today, including the documents, processes, and systems they rely on, and reconciling the answers into one written charter. We design the UI/UX from that charter and check the build against it every week, so the client launches a tool that works for sponsors and end users alike.

01

Discover

We sit with the people whose work will change the most, map each step they take and the systems each step touches, and sketch screens with them as they describe their work. We also name what would make each user group choose the new way, and the stage ends with the Outcome Charter.

02

Design

We turn those sketches into clickable prototypes, write the back-end and data requirements each screen depends on, and revise the design until it serves the sponsor's outcomes and the users' work. We keep only the features that serve an outcome in the charter, and the stage ends with the agreed design, the Requirements Specification, the Cut List, the Trace Sheet, and the usage floor.

03

Deploy

We check the build against the charter every week. When it moves away from what was agreed, you hear it from us that week, with the evidence, so you can raise it with the client first.

Engineers assembling hardware at a workshop bench with a laptop nearby
In practice

How discovery shapes the design

We ask each group targeted questions, because people describe what they do far more easily than what they want. Here are a few we ask buyers, planners, and operators:

  • Walk us through the last time you made this decision. What did you open first, and what came next?

  • What do you keep in a spreadsheet because the system does not give it to you?

  • Which number do you check twice before you trust it?

  • What would the new tool have to do on day one for you to use it?

We map the answers into the sequence of decisions each user makes, and we design the screens to follow that sequence.

A firm's client judges the program by whether people use what was built. CutLoc designs the UI/UX inside the discovery sessions and confirms each screen with the sponsor and the users before build starts, so the client pays once and launches something people use.

05Mandates

Fixed mandates

You own the recommendation and the build team owns the code, and CutLoc is accountable for the requirements that connect them.

01

Strategy firm

Strategy, the board conversation, and the client relationship.

02

Build team

Engineering management, production code, and integration.

03

CutLoc

Discovery, the UI/UX design, the requirements for the front end, the back end, and the data, the Cut List, and the usage floor. The client keeps ownership of everything we write.

06Terms

Working with firms

We work under your contract, your security terms and the client's. We declare any conflict when we are introduced. We never approach your client for other work, and we name a client only with that client's written approval.

When the engagement ends, we return or destroy our working material, and the client keeps the documents.

07Deliverables

Six documents carry the work.

Each is written to be handed to a client sponsor without us in the room, and to hold six months later when someone new proposes adding back what was cut.

01

Outcome Charter

One page naming what this build has to achieve, taken from the approved recommendation. Each outcome carries an owner, a measure, and a definition of what using it looks like.

02

Agreed Design

The clickable prototype and design rationale that the sponsor and the users approved, with each screen traced to an outcome in the charter.

03

Requirements Specification

The front-end, back-end, and data requirements, each written with a measurement, a population, and a threshold, so anyone can check whether it was met.

04

Cut List

What to build, and everything cut or deferred, with the reason tied back to the charter.

05

Trace Sheet

Each outcome followed through to the requirement that carries it, the feature that delivers it, and the measure that shows whether it worked.

06

Usage Floor

The agreed adoption target, measured in production, written into the engagement terms, and closed when met or formally waived.

08Team

Who does the work

Micah Canfield Principal

Micah has led product discovery and requirements work for dozens of client organizations since 2014. He works with a team of former strategy and technology consultants and heads every CutLoc engagement from the first conversation to the usage floor.

Each engagement team includes three core roles:

Requirements lead

Writes the front-end, back-end, and data requirements, keeps the Cut List, and owns the trace from each outcome to what gets built.

Product designer

Designs the UI/UX from the discovery findings, prototypes each workflow, and tests it with the people who will use it.

Full-stack engineer

Checks each back-end and data requirement against what the build team can deliver, and instruments usage from the first sprint.

Programs that need it add specialists in the client's industry or in data and databases.

09Engagements

Start with one program.

Micah assembles each team for the engagement it serves, so every person on it works on your program. Ask us for references

contact@cutloc.com

  • Answering an RFP

    Pursuit Support

    Discovery findings, a draft Outcome Charter, and key screens for the response, grounded in how the client's people work.

  • Build already underway

    Gap Review

    In two to four weeks, you get the charter and a written account of where the build has drifted from the recommendation and what the drift costs.

  • Before the build

    Pre-build Design

    The full output of the Design stage, set before the build starts while changes are still cheap.

  • During the build

    Build Oversight

    Weekly checks against the charter, plus usage tracking, until the usage floor is met.

  • Over budget

    Rescue

    An account of what is salvageable, what is sunk, and what it costs to finish.

  • Inside your team

    Embedded

    Any of the above, with the CutLoc team working inside yours.