How Roy Builds

Roy has strong opinions about how systems should work. He builds for people doing real work, not users who never misread instructions or click the wrong thing. If something looks bad, feels confusing, wastes time, or requires constant babysitting, it’s not done.

​

The constant question

One question runs through every stage of the work: “How much effort is this asking from the person using it?” Good systems fade into the workflow. They don’t demand attention or force users to remember special procedures. People should think about their work, not about the system.

​

Building standards

These are the standards Roy holds his own work to. If something he built violates one of them, it isn’t done yet. Unused systems are pointless no matter how well they technically function.

​

It can’t be ugly

Visual design signals whether the builder cares. People judge reliability and competence based on whether something looks deliberate. Trends and personal taste are ignorable. Whether the interface respects the user’s time is not.

​

It has to be easy to use

If something is hard to use, people avoid it. Roy designs to remove friction and pain points at every step without stripping out what the system needs to do. The question isn’t whether it works. It’s whether it’s easy enough that people will actually use it.

​

It must minimize manual effort

Repeated tasks get automated. People make random errors. Automations are more consistent.

​

It must be documented

If it only works when Roy is available to explain it, it’s incomplete. He writes documentation immediately, while the design decisions are fresh and the reasoning is still clear.

​

It needs to scale beyond the first use

If something works twice, it needs structure. Roy turns repeated solutions into systems, templates, or reusable components. One-off fixes are expensive to maintain and easy to break.

---

​

How the work actually happens

1. Identify the real problem (not the polite version)
2. Map the current workflow
3. Find friction
4. Remove unnecessary steps
5. Build the smallest useful version
6. Test with real usage
7. Write documentation immediately
8. Automate repetition
9. Improve layout and ergonomics
10. Package for reuse

Steps overlap. The “real problem” turns out to be a symptom. Parts that seemed finished need rebuilding. Roy circles back as needed, but some things still come before others: understand before building, test before documenting.

​

Output

The systems Roy builds:

• Respect the user’s time as more valuable than the system’s convenience
• Reduce cognitive load instead of demanding constant attention
• Degrade gracefully when things go wrong
• Explain themselves through design, not through training
• Scale without requiring coercion or surveillance

Quiet systems. They don’t announce themselves. They don’t send notifications unless something actually requires human judgment. They don’t punish mistakes with data loss.

​

Acknowledgements

Alaina Hardie had a huge influence on how Roy thinks about building.