Multi-Role Execution-Tracking SaaS

Failure mode 01 Unproven role-based design

The application was intended to serve multiple user roles, but the design implications of that structure had not been worked through. Each role needed a different view of the same underlying execution data: administrators needed oversight and control, project managers needed task-level coordination, and field teams needed clear, actionable assignments. Without a working prototype, the client could not evaluate whether those distinct views would feel coherent or whether they would create confusing fragmentation.

Failure mode 02 Three platforms, one product

The product had to work across web, tablet, and mobile. Each platform implies different interaction patterns, information density, and context of use — a manager reviewing progress on a desktop, a field worker updating status on a phone, a supervisor reviewing a tablet on site. Designing for all three meant making deliberate decisions about what each platform emphasized and what it deliberately left out, while keeping the underlying data model consistent.

Failure mode 03 No validation loop

The client had no mechanism for verifying that a prototype matched the behavior of the live application. Without screen-level comparison, design and development could drift apart, and the prototype would stop being a reliable preview of the product. That gap made the prototype less useful as a decision-making tool.

Decision 01 Role-based information architecture

Octacer structured the product around the three roles and the specific questions each one needed answered. The design decisions began with the data, not the screens: every role needed access to the same underlying project and execution information, but each role's interface emphasized different aspects, actions, and levels of detail. This architecture avoided building three disconnected products. Instead, it produced three views of a single system, which kept the design consistent and the development path realistic.

“One data model, three tailored views.”

Decision 02 Platform-specific interface design

Each platform received an interface designed for how it would actually be used. The web application supported the full breadth of management and administration functions, with dense information and complete controls. The tablet interface served on-site supervision, prioritizing status visibility and quick actions. The mobile application focused on the field worker's needs: clear assignments, fast updates, and minimal friction. Designing each platform's information hierarchy independently — rather than shrinking one desktop layout to fit smaller screens — produced interfaces that felt native to their device.

“Match the interface to the context of use.”

Decision 03 Screen-level QA against the live app

The final phase closed the gap between design and reality. Octacer systematically compared each prototype screen against the live application, verifying that the screens reflected actual app behavior rather than idealized design intent. This QA loop caught mismatches early and ensured the prototype functioned as a reliable reference for the client's product decisions.

“The prototype is only useful if it matches the product.”