Construction tech · Operations SaaS

From Sticky Notes to Construction SaaS

Digitizing a national construction operation that had scheduled work with paper, phone calls, and sticky notes for more than two decades.

Read case study All projects

Key results

20,000+

pools and commercial projects completed annually

20+branches represented in the operational model

13deep stakeholder workshop sessions

10 monthsfrom discovery into a working SaaS beta

2023–2024Discovery to beta

Project colophon

USGunite

Role: Project Manager / Design Lead / UX Designer
Engagement: 10 months
Scope: UX/UI · Discovery Workshops · Project Management · Design System
Tools: Figma · Tailwind · Lottie.js

Areas of impact

The clearest artifact in the discovery phase was not a diagram. It was a photograph of the dispatch center: walls and boards covered in sticky notes, carrying the schedule of a construction company that had worked this way for twenty-six years.

The process was familiar, flexible, and held together by experienced people. It was also difficult to repeat consistently across more than twenty branches, hard for management to see, and dependent on paper records for scheduling crews, invoicing clients, and paying workers.

I joined as Project Manager, Design Lead, and UX Designer. The assignment became one of my strongest examples of combining stakeholder discovery with delivery leadership: understanding a deeply physical operation, building trust with the people who ran it, and turning their knowledge into a product an overseas development team could implement.

The sticky notes were not the problem. They were the visible layer of a system people had spent decades learning how to operate.

01/05Discovery+

Discovery

Learning the operation before redesigning it

The company did not need a digital copy of its dispatch wall. It needed a shared understanding of how a job moved from booking to crew assignment, field execution, daily reporting, invoicing, and completion, including the exceptions that experienced schedulers handled from memory.

Thirteen workshops, not one requirements meeting

We ran thirteen workshop sessions, each lasting between two and three hours and involving three to eight participants. Together we mapped the end-to-end workflow, surfaced edge cases, defined user paths, and separated essential capabilities from requests that could wait.

A priority matrix made trade-offs visible and showed that most high-value features could fit within the available budget. We also defined role-based access early, giving developers a clearer foundation for the backend rather than leaving permissions as a late-stage interface concern.

Designing with both enthusiasm and resistance

Two broad proto-personas emerged. Younger employees were eager to remove the burden of paper daily logs used for client invoicing and crew payment. Older schedulers trusted the system they already knew and were willing to change only if the new product respected how the work actually happened.

We followed the workshops with interviews involving the people who would use the software. This helped us avoid treating resistance as a lack of digital literacy. It was often practical skepticism: users wanted evidence that a centralized tool could handle the exceptions their paper process made easy.

The crew schedule before the product existed: two whiteboard calendars covered in handwritten sticky notes — **From dispatch wall to shared workflow**The whiteboard, the intake wall, and a remote session with the crew. Two decades of scheduling lived on those two boards before any of it lived in software.

Job intake notes on the wall, each sticky carrying a builder, an address and a plaster type in someone's handwriting — **From dispatch wall to shared workflow**The whiteboard, the intake wall, and a remote session with the crew. Two decades of scheduling lived on those two boards before any of it lived in software.

Product definition

Turning workshop evidence into a buildable system

Discovery only creates value when the delivery team can use it. The next step was translating a large operational map into a sequence of decisions, flows, permissions, and product increments.

Planning with engineering, not around it

I co-created the project timeline with the lead developer, making phases and dependencies visible across design and engineering. Deadlines were flexible, but the plan gave the distributed team a shared way to handle blockers and downtime without losing momentum.

We selected Tailwind as the interface foundation because most developers already knew it. That was a product-delivery decision as much as a technical one: reducing implementation friction made it easier for the system to stay consistent after handoff.

Low fidelity as an alignment tool

The design team created low-fidelity flows for the primary journeys and the most consequential edge cases. Interactive prototypes let stakeholders test the structure before visual detail made unfinished decisions appear settled.

The work then moved into a scalable design system and high-fidelity direction. The client wanted the product to feel distinctly Texan. Rather than dismissing that request as cosmetic, we translated it into typography and color decisions that felt credible to the organization while remaining maintainable in a SaaS product.

Protopersona for Trevor, the scheduler, mapping his pains, needs, fears, motivations and daily behaviours — **From map to system**Trevor the scheduler, the insight wall he came from, the role matrix that set what he could see, and the planner that replaced his wall.

Synthesis board separating user insights from stakeholder insights before the product scope was agreed — **From map to system**Trevor the scheduler, the insight wall he came from, the role matrix that set what he could see, and the planner that replaced his wall.

Validation

Prototyping the expensive interactions first

Scheduling depended on dense drag-and-drop interactions. Building them directly in the frontend would have made every usability correction expensive, particularly with an overseas development team and a client still learning how to describe a digital product.

Clickable prototypes as risk reduction

We built several high-fidelity prototypes to contextualize drag-and-drop behavior, validate interaction logic, and show users what would happen before and after an action. The prototypes included guidance and test prompts, making them behave more like working product scenarios than disconnected presentation screens.

Testing with operational users and C-level stakeholders resolved usability questions before development and gave decision-makers a shared object to react to. It also protected the engineering budget: Figma was the least expensive place to discover that an interaction model did not work.

Wireframe inventory of the scheduling flows laid out for review before visual design began — **Scheduling interactions under test**Wireframes and the linked prototype. Scheduling was the expensive interaction, so it was the one tested before it was built.

Connected prototype map showing how the scheduling screens link together for testing — **Scheduling interactions under test**Wireframes and the linked prototype. Scheduling was the expensive interaction, so it was the one tested before it was built.

Project leadership

Building the team while building the product

The work started before a complete delivery team existed. Within four days I assembled the team, finalized the order and estimates, ran the kickoff, and facilitated the first discovery session. One designer was recruited and onboarded inside that same window.

A single thread across client, design, and development

The client was non-technical, engineering was overseas, and the workflow contained decades of tacit operational knowledge. I kept information moving between those groups, clarified decisions, and adjusted the plan when new evidence changed the product model.

The product grew into a full-scale SaaS beta with additional contexts and flows prepared for future testing. Development continues incrementally, but the strategy, workflow model, and core experience are no longer trapped on a dispatch-room wall.

2023 delivery roadmap sequencing UX and development workstreams across the engagement — **From project setup to working beta**The roadmap, then the beta it produced : builders submitting a schedule request and job-site details directly.

The working beta: a Gunite and Plaster schedule request portal that builders can submit against directly — **From project setup to working beta**The roadmap, then the beta it produced : builders submitting a schedule request and job-site details directly.

Reflection

Transformation begins with respect for the old system

USGunite was a successful UX project because discovery changed the product, not because workshops were completed. It was a successful project-management engagement because the evidence remained connected to estimates, sequencing, team coordination, and implementation.

The original paper process contained years of adaptation. Treating it as primitive would have alienated the people whose knowledge we needed most. By taking it seriously, we could preserve what worked, expose what did not scale, and give the organization a realistic path toward centralized operations.

Next project