Ideas
Insights on modernization, automation & AI
Design for Both Sides
When one product serves two kinds of user, the person who starts the work and the person who does it, every design decision has to be made once for each. Four lessons from two products built that way.
Read →People Trust AI They Can Check
People act on AI output they can see into, change before it counts and check against evidence. Accuracy alone does not earn that trust; three design layers do.
Read →Ship It Twice
The first version of an AI feature shows you what the second one must be, and no requirements document can. Plan and budget for two versions, and learn from real users on the first.
Read →Take the AI Out and See What Is Left
An AI tool that is only a screen and a few instructions around someone else's model has nothing to defend. Before you buy or build one, take the model out: the value lives in the workflow, the processing and the data around it.
Read →The AI Tax
The call to the AI model is the small part of an AI feature. Most of the build is the work around it: preparing the input, checking the output, time limits, fair billing, fallbacks and cleanup. Budget for that.
Read →Do You Actually Need AI?
Many problems pitched as AI problems are search, rules or form problems. A few questions about what goes in and what must come out tell you which, before you spend money on the wrong fix.
Read →The One-Codebase Trick
A system copied for every client, office or market makes you pay for every fix once per copy. One codebase configured per client pays once, provided you build for one client before you generalize.
Read →Your Design System Is a Business Asset
A design system is one library of interface parts, built once and reused on every screen. It costs a few weeks up front and pays back in speed on every screen after, which makes it a business decision.
Read →Why Version Two Gets Over-Built
Once a first version works, the plan for version two grows to fit every future anyone can imagine. Three questions keep it to what users need now, and it ships sooner.
Read →The Refactor That Pays for Itself
Most of the friction in an ageing system comes from a few of its parts. A refactor aimed at those parts, with its cost and payback written down first, pays for itself.
Read →Test the Riskiest Assumption First
A minimum viable product should test the assumption most likely to sink the product, which is rarely whether the team can build it. Rank your assumptions by risk and build the smallest test of the top one.
Read →The 23-Minute Recovery
Each interruption costs about 23 minutes of refocusing, and many are questions a document already answers. Send those questions to a system instead of a colleague, and the time comes back.
Read →Why AI Projects Fail
When an AI project fails, the model is rarely the reason. The scope, the data, the connections to other systems and a missing measure of success are, and each can be settled before the work starts.
Read →Ready to modernize what your business runs on?
Book Free Assessment