The Clipboard Was Our Biggest Competitor
Helping restoration technicians capture trustworthy information in the field.
When I joined Albi, one of the projects on my plate was Drybook, a mobile documentation tool used by restoration technicians responding to water damage events.
The request sounded straightforward enough. The existing sketching tool was difficult to use, documentation was inconsistent, and technicians wanted a better experience for recording floor plans, moisture readings, and equipment placement.
Like many product problems, that turned out to be partially true.
The sketching tool had issues. But fixing the interface wasn't the hard part.
The hard part was changing behavior.
At first glance, Drybook looked like a documentation tool. In reality, it sat at the center of a much larger workflow. Technicians collected information in the field. Project managers used that information to track progress. Insurance companies used it to validate claims. Customers depended on it to understand what was happening inside their homes.
The quality of decisions made downstream depended entirely on the quality of information collected upstream.
The business understood this. The challenge was getting everyone else to care.
Technicians already had a process. Some used paper sketches. Others relied on notebooks. Many had developed personal systems refined through years of experience. Those workflows weren't perfect, but they were familiar, fast, and trusted.
Our biggest competitor wasn't another software product.
It was a clipboard.
That's the part many software teams underestimate. Users don't compare your product to some ideal future state. They compare it to whatever they're doing today.
And what they were doing today worked well enough.
The organization saw better documentation as a path to better reporting, stronger insurance claims, and more informed operational decisions. Technicians saw another thing they had to do before they could move on to the next job.
Both perspectives were valid.
The challenge wasn't building a better sketching tool.
The challenge was aligning those incentives.
Once we looked at the project through that lens, many design decisions became obvious.
The users weren't sitting comfortably at desks. They were standing in damaged buildings, carrying equipment, wearing gloves, and sometimes working in full PPE. They were moving quickly through environments that demanded their attention.
Large buttons weren't a visual design choice. They were an adoption strategy.
A guided workflow wasn't an information architecture exercise. It was an attempt to reduce variability and help technicians complete documentation with less effort.
Every interaction had to answer a simple question:
"Is this easier than the clipboard?"
Because if the answer was no, adoption would suffer regardless of how much value the software created for the business.
This shifted our focus away from features and toward friction. Every extra tap became suspect. Every unnecessary decision became a barrier. Every additional field needed to justify its existence.
The goal wasn't maximizing the amount of information collected.
The goal was creating a process people would actually follow.
Looking back, Drybook taught me one of the most valuable lessons of my career.
Most product problems aren't interface problems.
They're behavior change problems.
Organizations often recognize the value of better data long before the people responsible for collecting it do. Product designers end up standing in the middle, translating business goals into workflows that people are willing to adopt.
The best solution isn't always the one that captures the most information.
It's the one that successfully changes behavior.
Because that's the only one that survives contact with reality.
