Building Products Around Real Workflows, Not Assumptions

A product can have every feature on a requirements document and still fail its users.

Why?

Because requirements describe what a system should do. They don't always explain how people actually work.

That is why understanding real workflows is one of the most important parts of building useful software.

The difference between a process and a workflow

A process might say:

Customer makes a deposit → teller processes transaction → supervisor approves → transaction is completed.

But what happens between those steps?

Does the teller need to switch between multiple systems?

Does someone manually verify information?

Where does the supervisor receive the approval request?

What happens when something goes wrong?

How is the transaction recorded?

How does management know how long the transaction took?

These details are where operational friction lives.

Research before design

During the development of AltTill, the existing manual framework was mapped across branch transaction types to identify friction, duplication and control gaps.

The team worked with branch operations, audit and technology teams to define the MVP and interviewed tellers, supervisors and vault officers to understand the real workflows behind the documented processes.

That research informed the product.

The interface was designed for speed and simplicity because tellers would be processing high transaction volumes under time pressure.

The workflow shaped the design.

The same principle applies across industries

Harmony presented a different environment but a similar product challenge.

The system supports store staff managing sales and inventory, while administrators need visibility into activity, stock levels and performance.

Features were mapped directly to real store workflows, with simplicity as a primary design principle.

The product went through multiple release cycles, with live feedback shaping subsequent refinements.

Good UX starts before the interface

User experience is often associated with screens, buttons, colours and layouts.

But good UX begins much earlier.

It starts with understanding:

Who is using the product?

What are they trying to accomplish?

What information do they need?

What can go wrong?

What decisions do they need to make?

What currently frustrates them?

The answers influence everything from navigation and information architecture to automation, notifications and permissions.

Don't automate a bad workflow

One of the biggest risks in digital transformation is taking an inefficient process and simply automating it.

If a process requires five unnecessary steps manually, turning those same five steps into five digital screens isn't transformation.

The better question is:

What should this workflow look like if we were designing it today?

That doesn't mean ignoring existing processes. In complex environments, existing controls can be essential.

It means understanding why each step exists and determining how technology can preserve the necessary control while removing unnecessary friction.

AltTill, for example, embeds Maker-Checker approvals, automated validations and audit trails directly into the system.

Build for the person doing the work

The most effective products don't ask users to become experts in the software.

They make the software fit naturally into the work.

That requires research, observation, iteration and continuous feedback.

Because real usage reveals what planning cannot.

Build around the way people work, and technology becomes an enabler rather than another layer of complexity.

Build technology that works for your business.

Talk to Unshelled about your next product or digital transformation project.