Twenty-five years leading development projects, and I never once had a psychologist on the team. Not through choice, through budget. Behavioural science sat in the same column as bespoke furniture, the kind of spend client-facing consultancies afford and delivery teams do not. Over the past few months I've written three skills putting a working grasp of user psychology into every project I run. The luxury finally arrived, and it arrived as code.
The shelf everyone keeps stocking
Search any library of AI coding skills and the shelves are full: testing strategy, architecture decisions, code review, deploy checklists, accessibility audits, security reviews. Each one makes the resulting code more correct, more secure. None of them ask who the code serves, or what the person is thinking when they open the screen.
A user's confusion, hesitation, or quiet abandonment gets reviewed never, because nobody wrote the skill to catch it. The imbalance is not an oversight. It reflects where the industry has always put its attention: the artefact, not the reader of the artefact. A pull request gets reviewed line by line. The tooling ecosystem has spent a decade teaching models to write defensible code and almost no time teaching them to read a room.
Three skills built to close the gap
I wrote a skill applying behavioural science and psycho-logic to positioning and messaging decisions, flagging where a pitch, a page, or a piece of writing fails before it ships. It reads copy the way a buyer reads it, tired, sceptical, and looking for a reason to stop.
I wrote a second profiling the psychological make-up of the people using a product, across five evidence-based frameworks, turning the findings into named colour choices, component libraries, and workflow decisions rather than generic advice. It refuses hedged output. Name the palette, name the component, name the reason, or the recommendation does not count.
I wrote a third running structured discovery, including proper user research, personas, journeys, and the jobs a user is trying to get done, before a single screen gets designed. It forces the question a rushed backlog never asks: what is this person trying to achieve, and what state are they in while they try to achieve it.
None of the three write a line of application code. Each one changes what the following code is built to do, and for whom.
What gets replaced, not added
None of this sits on top of good engineering as decoration. Most development teams have carried a business analyst for decades, and most have carried a user researcher for the last ten years or so. What they have never carried is anyone trained in user psychology or behavioural science, the discipline explaining why a technically sound interface still gets abandoned, or why a well-reasoned pitch still gets ignored. This expertise sat behind consultancy day rates only the largest budgets cleared, the kind of spend closer to Palo Alto than to a housing association back office. Everyone else built on best guesses dressed up as user understanding.
I watched what happens when this expertise is missing on a national scale. A pathology coding standard sat unfixed for the best part of three decades because three earlier attempts asked what the correct code was, rather than who would be choosing it under pressure. Terminological purity won every argument in the room and lost every argument with the lab technician trying to find the right code before the queue behind them grew. The working standard started from the second question, built personas, mapped journeys, and let a technician's screen real estate decide what the specification needed to hold. The fix took shape once someone brought a psychological read of the user into a process which had process experts and code experts, but nobody reading behaviour.
This is the pattern these skills exist to force, on every project I touch, not the one project which happened to have a psychologically literate stakeholder in the room by chance. Luck is not a method. A skill running the same behavioural discipline every time, whether the budget stretches to a specialist or not, is closer to one.
The open question
I have not decided whether to open source the psychology skills. Giving them away would put a working method for reading users into anyone's hands, and the argument for governance-minded technology leadership improves when the tools behind it are visible rather than claimed. A board considering someone for a non-executive seat weighs a method it is able to inspect far more easily than one it must take on trust.
What holds me back is not the value of the method to me. It is not knowing whether anyone outside a handful of AI-native teams would put it to use, given most of what gets written about AI-assisted development still concerns the code and almost nothing concerns the person the code exists to serve.
I have not landed on an answer. The hesitation itself is the finding: an industry that reviews every line of code and never the person reading the screen does not yet know what it would do with the method.