The DIRTT Pipeline

Research With the People Who Live in the Process

Qualitative and quantitative research with staff and end users, before changing a thing

I ran the inherited process exactly as documented for my first few weeks, treating myself as the first research subject: where I waited, where I repeated myself, where vendor-era assumptions no longer fit. Alongside that I ran a documentation review of our internal artwork hub, years of training videos and PDFs, to understand why each step existed.

• Contextual inquiry and direct observation: working the process end to end, then following the files downstream onto the plant floor to watch what happened after my handoff.
• Stakeholder interviews with the partner-facing side: the Custom Finishes team, the Quality team, and the Product Manager for Finishes, on what partners ask, where they get confused, and where requests stall.
• User interviews with the end users of my output, run separately with Shift A and Shift B, to test whether the two crews experienced the process differently.
• Quantitative baseline: timing each stage of a job, from quote through proof, approval, file transfer, and download.

"I usually allot a full day to download the files."

Print Operator, on the old SharePoint handoff

Both shifts, interviewed independently, named the same bottleneck. When two teams that barely see each other report identical friction, the finding holds.

Mapping the Research Into a Problem Worth Solving

Current-state workflow map and customer journey map, built from the research findings

I translated the research into two artefacts in Miro: a current-state workflow map of the business process, and a customer journey map running from partner submission through samples and final print production. Every point where a job sat idle got marked. Together they told one story: the pipeline waited more than it worked.

• Upstream, jobs still moved at the vendor's pace: quotes 2 business days, proofs a flat 4, Order Entry approval through a 2-day email chain, with buffer days padding nearly every handoff.
• In my own stage, pre-press preparation was fully manual, capping output at roughly 25 print-ready files a day.
• Downstream, the journey map made the sharpest finding visible: the team was maintaining two systems for the same files, and the slower one, SharePoint, sat directly on the critical path.

The journey map turned a vague complaint about slowness into a specific, defensible problem statement: one redundant system was gating the entire pipeline.

Solution Discovery: Remove a System Instead of Adding One

From the mapped pain point to a validated solution

The obvious instinct with a slow tool is to buy a better tool. The research pointed the other way. The journey map showed Production already pulling files from an internal network folder every day for other work, so the faster system was one the team had already adopted and trained on.

• Options considered: keep both systems and try to speed up SharePoint sync, compress files at upload, or consolidate onto the network folder already in daily use.
• Chosen direction: subtraction. Retire SharePoint from the production process. Zero new software, zero training curve, and one place for every job file.
• Validated before building: I took the proposal back to Shift A and Shift B in follow-up interviews to confirm it solved the problem they had described, rather than the one I assumed.
• Second bottleneck, separate solution: with the handoff fixed, my own manual pre-press became the ceiling, which pointed to automation rather than process change.

The strongest solution in the set was the one that removed a tool rather than introducing one.

The Green Light (and the Locked Folder)

The chapter with the most people in it

A pipeline change isn't a design decision you make alone. I built the case and brought it to my Manager, the Plant Manager, and the Plant Supervisor. The Miro maps did most of the convincing. Approval wasn't the last obstacle, though: only the Production Lead had access to the internal job folders, which meant the whole plan didn't work until the Print PC could reach them too. I coordinated with IT to open that access. The final piece was telling partners: a faster process only helps if people know what to expect, so I redesigned the partner-facing Custom Graphics Timeline graphic to reflect the new reality, with updated stages, durations, and complexity tiers partners can self-assess against.

Sometimes the fix isn't the workflow. It's the permissions.