A Developer Is Not a Mind Reader
Many HR software disappointments begin with a perfectly understandable sentence: “Can you build us something simple?” The developer nods, asks a few questions, and produces a system that works exactly as requested. Technically, it is sound. Operationally, it misses the point.
Why? Because the real need was never fully translated.
A developer can build a workflow, form, dashboard or integration. They can make information visible, automate reminders and reduce duplication. But they cannot infer every exception, pressure point, cultural expectation and informal workaround in the organisation. They do not automatically know that payroll needs the start date three days earlier than HR thinks. They do not know that managers avoid the current form because it asks the wrong questions. They do not know that new starters feel lost because nobody explains the company purpose until week three.
The business must bring that knowledge to the brief.
The Gap Between Need and Instruction
HR and Operations teams often understand the pain but struggle to describe the system requirement. “Onboarding is messy” is true, but not buildable. “Managers need to be more accountable” is important, but not a feature. “We want people to feel connected to the company” is valuable, but it must be translated into moments, prompts, content and behaviours.
This is the bridge: Idea, Brief, Mock-up, Feature.
The idea is the broad need. The brief explains the problem, users, current workaround and success measures. The mock-up shows how the process might feel. The feature is what gets built.
Skipping the middle stages is where trouble begins. A feature built from a vague idea may satisfy the sentence but fail the situation.
Start with the Real Work
Before writing requirements, watch the work. What does HR actually do when a new starter is confirmed? What does the manager do? What does payroll need? What does IT need? Where do people copy and paste? Where do they wait? Where do they chase? Where do they use judgement? Where does the company’s mission need to be explained?
Real work is always richer than the official process diagram. The brief should capture that richness without becoming a novel.
For each workflow, describe the trigger, the steps, the people involved, the information required, the decisions made, the outputs created and the risks if it fails. Then describe the emotional experience. Is the user rushed, anxious, confused, confident, reassured? Systems designed without emotional context often feel efficient to the builder and irritating to the user.
The One-Page HR App Brief
A useful brief does not need to be long. It needs to be clear. It should include the problem to solve, the users, the current workaround, the essential features, what is out of scope, the source of truth, success measures and unanswered questions.
For example, do not write: “We need a better induction system.” Write: “New starters currently receive induction information across email, PDFs and manager conversations. This causes missed tasks and inconsistent understanding of our mission, vision and values. We need a single first-week journey showing required actions, named owners, key documents, role-purpose prompts and a short explanation of how the role contributes to the company direction.”
That gives a developer something to work with.
User Stories with Human Purpose
User stories can be powerful when written properly. “As a line manager, I want a Day 1 checklist so that I can prepare equipment, access and role expectations before the employee arrives.” Good. Better still: “As a new starter, I want to understand the company’s mission, values and first-week plan in one place so that I feel expected rather than processed.”
That final phrase matters. It tells the technical team what the system must make possible, not merely what it must display.
A good brief should include both functional and human outcomes. The system must send reminders. It must also reduce uncertainty. It must store documents. It must also help people find the trusted version. It must record training. It must also help managers connect development to the company’s direction.
Testing with Real Pressure
A system is not ready because it works in a demonstration. It is ready when it survives real use. Test it with messy data, busy managers, part-time workers, late changes, unusual roles and people who are not enthusiastic early adopters.
Ask users to complete real tasks. Where do they hesitate? What do they misunderstand? What do they ignore? What do they do outside the system? Every workaround in testing is a gift. It shows where the design does not yet match the work.
Also test the identity layer. Can a new starter understand why the company exists? Can a manager see how to discuss values in a probation meeting? Can HR update mission or induction content without calling a developer? If belonging depends on hard-coded text nobody can maintain, it will decay.
Becoming a Better Client
A better client is not someone who speaks in technical jargon. A better client is someone who can explain the reality clearly. They can say what hurts, who is affected, what good looks like, what must not happen, and which decisions remain unresolved.
They also know when not to build. Sometimes the right answer is a checklist, a better folder, a cleaner spreadsheet, a clearer owner or a revised induction conversation. Technology should support the process, not dignify confusion with an interface.
The Blueprint Mindset
The Talent Flow Blueprint ends here because every article has been preparing for this moment. Find the information. Clean it. Own it. Use it. Connect it to mission, vision and values. Then, and only then, build or buy tools that help people live the company’s purpose more easily.
A developer can build the house. The organisation must first decide how people are meant to live in it.
Working with Technical Teams
Good collaboration with developers is built on respect in both directions. HR should not be expected to speak like engineers. Developers should not be expected to guess complex human processes from a few bullet points. The shared language is plain English, examples and evidence.
Bring screenshots of current workarounds. Bring anonymised real data. Bring the email people currently send when the system fails. Bring the checklist managers ignore and ask why they ignore it. Bring the moments where employees feel confused. These artefacts help a technical team understand the real world.
It is also useful to separate must-have from nice-to-have. A must-have protects the process. A nice-to-have improves convenience. If everything is urgent, nothing is prioritised. If every feature is essential, the brief is not yet disciplined.
After Launch Is Still the Project
Many organisations treat launch as the finish line. In reality, launch is when the system begins meeting real behaviour. Plan for feedback, small fixes, training refreshers and ownership reviews. Ask whether the system is being used as intended. Ask where workarounds have reappeared. Ask whether employees feel more informed and connected.
Most importantly, keep the identity layer alive. Mission, vision and values should be easy to update as the company changes. A system that freezes the company’s story soon becomes another dead manual.
The better client is not the one with the longest specification. It is the one who can keep purpose, process and people in view at the same time.
