When organisations talk about HR technology transformation, they often focus on the system. The features. The workflow. The timeline. All important, of course, but none of those things guarantee impact. What really makes a difference is how intentionally you design for people, for change and for measurable value right from the start.
This is the heart of the Value by Design framework. It is not a document. It is not a project phase. It is a way of thinking that shapes every conversation and every decision across the life of a project. Value by Design is built on three principles: design the vision, design the experience, and design the proof. This article focuses on the first, how you create clarity and alignment from day one.
This article sets out what that framework looks like and why it is becoming essential for HR and TA leaders who want more than a successful go-live: they want a successful transformation.
A Real-world Example: Struggling Without a Baseline
Recently, an enterprise client had a strong technical launch, with positive feedback from users and a well-coordinated go-live plan. The challenge came six months later when the organisation asked for ROI. The team suddenly realised that no one had defined success in measurable terms at the start. There was no clear baseline from before implementation. They spent weeks searching for historical data and debating which metrics mattered.
In the end, the story was incomplete because the foundation had not been set early. The lesson was clear. If you do not define value and baseline it before build, you cannot credibly demonstrate impact later, no matter how well the technology performs.The Value by Design framework
The Value by Design framework consists of 5 pillars which help you avoid this situation. Here’s how it works.
Define Value Early
One of the simplest and most powerful steps you can take happens before the project even begins. Write one sentence that describes what success looks like. Not a paragraph full of qualifiers. Not a list of ten KPIs. Just a clear statement that completes the idea: We will know this project worked if…
This sentence becomes the anchor for everything that follows. It forces clarity about the outcome you want, not the activity you plan to complete. It also gives your project team a shared language. When HR, IT and business leaders all point to the same sentence, decision making becomes far easier.Where teams often stumble is in trying to define value after the build. By then it is too late. Without a baseline and a shared definition of success, value becomes something you talk about rather than demonstrate
Integrate Change From Day One
If there is one habit that separates high performing project teams from the rest, it is the way they treat change. They do not see it as a final training sprint or a separate workstream. They weave it into everything.
Discovery becomes a chance to understand how people feel today, not just what they do. Design becomes a chance to test messages, not just screens. Testing becomes a chance to bring in champions early, not wait until the end. When you build this rhythm from the beginning, adoption becomes a natural outcome rather than something you have to push.
Stakeholder alignment is also part of this early work. If you wait until the requirements gathering phase to engage stakeholders, you are already behind. People form opinions quickly. They want to know the vision and the why. Including them early helps you prevent resistance before it forms.
Don’t Separate People, Process & Technology
One of the biggest risks in HR technology projects is siloed ownership. HR writes the process. IT builds the system. Communications appear near the end with a launch plan. This separation might feel efficient in theory, but in practice it creates misalignment that shows up the moment people start using the new solution.
A Value by Design mindset brings these groups together from day one. Every decision considers how the system works, how the process flows and how people need to move through it. It means your roadmap is not three parallel documents but one integrated plan with shared accountability. When these elements move together, you build something that fits not only technically but behaviourally.
Use Governance to Create Confidence
Good governance does more than protect the project. It builds trust. In every phase, you should ask three simple questions.
- What value have we unlocked so far?
- What risks could affect adoption?
- How is the business demonstrating engagement right now?
These questions turn a steering committee from a status call into a meaningful conversation about impact. I have seen project sponsors shift their entire relationship with technology delivery just by embedding these questions. Suddenly the project is not only about configuration and timelines. It becomes about outcomes, readiness and confidence. When leaders see progress in these terms, momentum builds naturally.
Value Proof Over Perfection
There is a common belief that you should wait for the system to be perfect before sharing anything about progress. In reality, early proof is far more valuable than a perfect launch story.
Share small wins as they happen. Share early feedback, even if it is mixed. Share examples of champions who are already embracing the new approach. These moments build credibility. They give people a reason to believe in the work. They also help you shape the narrative inside the organisation long before the big reveal.
The Key Do’s and Don’ts
The Value by Design mindset is practical. Here are straightforward actions you can take.
DO
- Bring your change and adoption leads into the project from the beginning so they can shape the experience, not just explain it.
- Start with two or three business outcomes that everyone understands and cares about.
- Share small wins throughout implementation to create visibility and excitement.
- Create a visible one-page Value by Design that captures outcomes, owners and measures. Keep it in front of the team.
- Activate champions early, well before UAT, so they can influence design and build credibility.
DON’T
- Treat change as training that happens in the final week before launch.
- Wait until after the system is built to define what success looks like.
- Limit progress updates to steering committees instead of communicating impact to the wider organisation.
- Hide your Value by Design inside a project deck. If no one sees it, it cannot guide decisions.
- Introduce champions after the solution is already finished because their influence will come too late.
Common Pitfalls To Avoid
There are patterns that show up again and again in HR technology delivery. Leaders often talk confidently about value, yet struggle to describe what it means in practical, measurable terms. Without that clarity, the project becomes a series of tasks instead of a journey toward an outcome.
Adoption metrics also suffer from unclear ownership. Everyone assumes someone else will measure success. When launch day arrives, no one is positioned to track how the organisation is actually experiencing the change.
Stakeholder alignment is another challenge. HR might be looking at process efficiency, IT at system performance and executives at cost or speed. When these perspectives are not aligned early, people end up celebrating different things and questioning each other’s priorities.
And finally, change is often introduced too late. By the time communications begin, the organisation has already formed its own narrative. People feel excluded and adoption slows down.
What’s next?
Here are practical steps:
- Draft your one-sentence definition of success and discuss it with your project team.
- Identify your top five stakeholders and write down what success means for each of them.
- Choose three metrics you can baseline now, even if the data is rough.
- Add a value review item to your next steering meeting agenda.
- Share one early win with the business to generate positive energy.
A Real-world Success Story
Remember that cautionary tale at the start of the article? Well, here’s an example of a client that utilised the Value by Design mindset to build momentum early. On one recent Talent Tech project, we made a simple shift in how the team approached governance. At every milestone, we asked three questions.
- What value have we delivered so far?
- What could affect adoption if we do not address it now?
- How is the business demonstrating engagement right now?
These questions changed the entire rhythm of the project. Steering meetings became conversations about impact rather than slide decks. The team shared small wins as they happened, which built confidence long before go-live. Champions were activated early and shaped parts of the design. When launch day arrived, adoption moved quickly because people already understood the why and could see the progress that had led there. The project avoided the typical post-launch dip and reached steady state faster than expected.
Conclusion
Transformation is not something that happens at go‑live. It is shaped through hundreds of small decisions that happen long before anyone logs in to a new system. When you adopt a Value by Design mindset, you shift the focus from delivering technology to delivering value. You give your teams clarity, you build confidence early, and you create the conditions for real adoption. Most importantly, you set your organisation up to show the impact of your investment in a way that is meaningful and measurable.
Designing the Experience That Turns Technology Into Real Value
The hard truth about Talent Tech is that the technology does not deliver value on its own. Value is created through how people interact with that technology in their everyday work. The experience you design long before going live shapes those interactions, influencing whether hiring managers engage or delay, whether recruiters trust the system or work around it, whether workflows genuinely reduce effort or quietly add friction, and whether data becomes something leaders rely on or something they question.
Most HR tech projects fail because they spend too much investment in selecting the right platform, and too little investment in designing how people will actually experience it. Earlier we focused on making intentional choices before implementation, and we turn our attention to what happens next: the people, the process, and the progress that determine whether that intent translates into real outcomes.
Experience is not an afterthought in transformation. It is the mechanism through which value is realised.
People: Designing the Behaviours That Unlock Value
Every outcome organisations expect from HR technology; speed, quality, adoption, and data integrity, is ultimately driven by human behaviour. Systems rarely fail in isolation. What fails is how people engage with them under real operational pressure.
Across implementations, the same behavioural patterns surface repeatedly. Hiring managers delay decisions because the process feels unclear or unnecessarily heavy. Recruiters bypass the ATS during peak pressure, intending to update it later. Job intake varies based on who is involved, creating inconsistency that ripples downstream. Leaders approve exceptions to keep work moving, slowly eroding the simplicity the system was designed to enforce. Champions are introduced too late, once key decisions are already locked in.
These behaviours are not the problem themselves. They are symptoms of an experience that has not been designed to make the right behaviours the easiest ones.
There are also blockers that are rarely addressed directly. If hiring managers do not change how they engage with the process, nothing else meaningfully shifts. If people do not trust a workflow, they will always find a way around it. And no amount of system configuration will compensate for unclear or competing behavioural expectations.
Teams that unlock value take a more deliberate approach. They identify a small number of behaviours that directly drive the outcomes they care about and design explicitly around them. They remove friction so the desired behaviour is easier than the old habit. They involve champions early as co-designers rather than late-stage advocates. They pay attention to emotional resistance as carefully as they do process gaps.
Where teams struggle, the causes are predictable. Awareness is mistaken for adoption. Training is expected to create habits. Real users are only involved during UAT, when meaningful change is already difficult.
In one example, recruiter adoption was persistently low because the workflow felt heavy and duplicative. By observing how recruiters actually worked under pressure, the team identified redundant fields and a manual handoff that added no value. Removing both increased system usage and improved data quality within weeks, which flowed on to actionable metrics, like faster time to hire and increased recruiter capacity. The technology did not change, the experience did.
Process: Designing Simplicity That Drives Speed and Trust
Complexity is one of the fastest ways to undermine adoption. Every additional step in a process carries a cost, not only in time, but in trust and data quality. Most HRIS professionals understand this instinctively, yet complexity often creeps back in through legacy thinking and unmanaged exceptions. When the dust settles, those same HRIS admins are left to sustain this complexity long after go live – and find themselves responsible for maintaining processes they didn’t design nor support.
In practice, many hiring delays are caused by process friction rather than system limitations. Exceptions quietly erode data integrity over time. And if a workflow requires a lengthy explanation to justify itself, it is already working against adoption.
One of the hardest truths for organisations to accept is that the process people actually follow is the one you have designed for, whether or not it matches what is documented. If people consistently opt for a workaround over the official process, then the workaround is actually the most efficient process.
High performing teams design process with intent. They focus on the majority scenario rather than edge cases. They challenge inherited steps by asking whether they genuinely create value. They prioritise clarity before automation and actively involve recruiters and hiring managers in shaping workflows, rather than presenting finished designs for approval.
Where teams lose ground is equally consistent. Old processes are recreated inside modern platforms. Political considerations outweigh operational simplicity. Customisation is used to preserve exceptions instead of eliminating them.
The impact of simplification is often immediate. Reducing approval layers can cut hiring time by days, not hours. Analysis frequently shows that approval steps add little more than delay, returning significant recruiter capacity when removed. In global environments, replacing country-level exceptions with a single universal workflow can dramatically improve adoption and reporting reliability
Progress: Designing Momentum That Builds Confidence
People rarely resist change because they dislike improvement. What they fear is uncertainty, particularly when they do not understand what the change means for them personally. Momentum replaces uncertainty with confidence, but only when progress is visible.
Silence during implementation creates its own narrative, and that narrative is rarely positive. People trust progress they can see, not progress described in status updates or slide decks.
Rather than relying on traditional change management, effective teams focus on making progress tangible. During discovery, they communicate outcomes rather than features, explaining the problem being solved and why it matters. During design, they highlight what has been simplified and which friction points have been removed. As readiness approaches, they use before-and-after comparisons to clarify what will change and what will remain the same. At go live, they reinforce early wins and keep the story active rather than declaring success and moving on. This does not mean sharing every detail early, but sharing meaning at the right moments, so people understand what is improving and why.
In one global rollout, a short video demonstrating a simplified interview scheduling flow created more confidence than extensive written communications. People could see the improvement, and that visibility mattered more than detail.
Momentum fades quickly when updates are saved for the end, when feature lists are shared without context, or when teams assume people will patiently wait for launch without forming opinions along the way.
Sponsorship: Leadership Sets the Ceiling
Strong sponsorship is visible, consistent, and aligned. Effective leaders reinforce a shared definition of success, treat simplicity as non-negotiable, remove barriers rather than introduce exceptions, and publicly reinforce progress. Most importantly, they model the behaviours they expect others to adopt.
Just as critically, strong sponsors actively back the people responsible for delivery. They give teams the authority to make decisions, defend those decisions when challenged, and remove organisational friction that would otherwise undermine progress. When leaders are not aligned, or not visibly backing the people leading the work, the organisation never is.
Common Pitfalls to Avoid
Many teams unintentionally undermine value by designing for edge cases instead of outcomes. It is very easy to say “But what about X?” in a meeting and it is much more difficult for a project manager to justify “Well, X is only about 1% of all cases”. Nonetheless, every edge case adds a layer of complexity to the process, and has a snowball effect on the process, so it is worth doing the work to really understand if they are justified.
Additionally, allowing politics to override simplicity, adding exceptions that erode process integrity, engaging champions too late, assuming training alone will change behaviour, underestimating how quickly negative narratives form, and designing workflows without a clear understanding of real user behaviour are all among the most common pitfalls we see teams get stuck in.
Where to Start
Regardless of where your project sits today, progress begins with small, intentional moves. Identify one behaviour that directly drives the outcome you care about and anchor decisions to it. Simplify a single workflow step that creates friction and allow that improvement to build belief. Speak to real users and listen without defending the design. Share one visible value moment, whether that is a blocker removed or a step automated. Define what good should feel like, not just how it should function.
Clearer, faster, and easier are often better design guides than any requirements document.
Experience Is the Engine of Value
Earlier we argued that value must be designed intentionally before implementation begins. Next we will focus on how those early design decisions shape the day-to-day experience of the people expected to use the technology.
When people understand why change matters, when processes genuinely feel simpler, and when progress is visible, adoption follows naturally and value emerges quickly and more efficiently. Experience is not the soft side of transformation. It is what turns technology into impact.
What Comes Next?
Designing the experience creates the conditions for value, but it does not answer the question leaders ultimately face: how do we know value is being realised, and how do we demonstrate that impact in a way the business trusts?
Turning HR Tech Outcomes Into Real Value
The Final Test of Transformation
Proof is the moment transformation becomes accountable. Many HR technology programs do create real improvements. Processes become simpler. Time is returned. Data quality improves. Adoption increases. Yet months after go live, a familiar question surfaces in executive conversations:
Was this worth it?
At that point, organisations often discover that ownership is unclear, baselines were never formally agreed, and proof was never intentionally designed. The problem is rarely the absence of value. It is the absence of disciplined evidence.
Transformation is incomplete until impact can be demonstrated in a way the business believes.
Why the ROI Question Always Comes Too Late
The ROI conversation is inevitable, but the mistake most organisations make is treating it as a retrospective exercise rather than a design requirement. In practice, the question “Was this worth it?” typically arrives months after go live, often during budgeting cycles or leadership changes. By then, the project structure has dissolved and expectations have shifted.
Baselines are missing or disputed, time to hire was measured differently across teams, data quality was never clearly defined. Ownership of outcomes is blurred. HR assumes HRIS owns system performance. HRIS assumes the business owns results. Vendors delivered technology, not long-term accountability. Finance asks for proof after investment decisions have already been made.
Evidence may exist, but confidence does not. If no one owns proof, value becomes a debate instead of a fact. Designing for ROI must begin before implementation starts. Baselines should be established early, definitions agreed, and success criteria made explicit. Without that discipline, even genuine improvements risk being questioned.
Reporting Is Not Proof
Dashboards do not automatically create credibility.
Reporting shows activity. It shows usage, workflow completion, and system metrics. With enough filtering, almost any narrative can be constructed. Selecting the largest improvement and presenting it as impact is easy. Sustaining belief under scrutiny is harder.
Proof operates at a different level. Reporting answers what happened, proof answers what changed and why it matters. Proof connects system metrics to business experience. It combines quantitative signals with behavioural shifts and operational sentiment. If recruiters and hiring managers still describe the process as painful, the transformation has not delivered impact, regardless of what the dashboard shows.
Credible proof often includes signals such as:
- Time genuinely returned to recruiters or managers
- Tangible improvements in cycle time or quality indicators
- Reporting that leaders actively trust and use
- Observable behavioural shifts in system usage
- Direct validation from those impacted by the change
Efficiency gains illustrate the point clearly. Returning time to recruiters may look like a win on paper. The harder question is how that time is redeployed. If it is not redirected toward higher value activity, the strategic benefit remains theoretical. Proof therefore extends beyond hours saved to include business relevance.
Proof lives at the intersection of data, behaviour, and narrative. Remove any one of these elements and credibility weakens.
The Ownership Gap
Value frequently erodes because everyone contributes to it, but no one owns it.
During implementation, accountability feels clear. Sponsors are visible. Project teams are structured. Vendors are engaged. After go-live, that clarity often fades. The assumption is that the new system will sustain itself.
This is when responsibility becomes ambiguous.HR may assume HRIS owns the platform. HRIS may assume hiring outcomes sit with the business. Vendors are measured on delivery, not long-term value. Finance expects evidence but is not embedded in defining success.
Ownership becomes most visible when questions are asked and answers are uncertain. As we have written previously, go live is not the end, it is the end of the beginning. Sustained value requires defined product ownership, structured continuous improvement, and explicit accountability for outcomes over time. Without that structure, even stable adoption can mask declining credibility.
When ownership of proof is unclear, value becomes fragile.
Baselines Are Not Optional
You cannot prove change if you never agreed on what came before it.
Baselines are often avoided because they force clarity. They require consistent definitions and transparent acknowledgement of current performance. Leaving them vague may feel flexible in the short term.
In reality, it undermines long-term credibility. Without agreed baselines, improvement becomes subjective. Success is described narratively rather than evidenced concretely. Under executive scrutiny, narratives alone rarely hold.
Baselines do not limit ambition. They protect trust. They allow improvement to be demonstrated with confidence rather than defended through interpretation.
Proof Is a Loop, Not a Moment
Value is not proven once and archived. It must be reinforced continuously.
Early successes should be highlighted, particularly when behavioural change is involved. However, proof must extend beyond initial wins. It should evolve as the organisation evolves.
Effective proof follows a simple loop:
Baseline → Behaviour → Outcome → Narrative → Optimisation.
Baselines establish clarity. Behaviour creates change. Outcomes demonstrate impact. Narrative communicates meaning. Optimisation protects and extends gains.
This is not optimisation for efficiency alone. It is optimisation for credibility. As hiring volumes fluctuate or strategic priorities shift, the proof model must adapt. Static measurement weakens dynamic organisations.
Sustained credibility depends on repeatedly linking behaviour to business outcomes in language leaders recognise.
Turning Outcomes into Value. Designing Proof Completes the Transformation
Across this series, the framework has been consistent.
Vision creates intent, experience creates the conditions for value, and proof creates trust.
Designing the experience enables improvement, but it does not answer the question leaders eventually face: how do we know this worked, and how do we demonstrate impact in a way the business believes?
Without ownership, baselines, and a clear value narrative, proof becomes fragile even when improvements are real. Designing the proof closes that gap. It is the final act of accountability in transformation and the difference between value that is assumed and value that is trusted.
Organisations that treat post go live as a managed value phase rather than a support phase protect their credibility. They schedule structured value reviews. They monitor behavioural indicators alongside system metrics. They maintain governance discipline and continuously translate operational improvements into business language.
What comes next?
Transformation is not complete until impact can be evidenced with confidence. At TalentTech, this is why their managed service model extends beyond implementation. They work with clients to define baselines, clarify ownership, and establish ongoing proof loops that demonstrate value in terms the business recognises. Anything less leaves the work unfinished.
If you need support in building this mindset into your next project or want help assessing where value can be unlocked in your current tech stack, TalentTech would be happy to talk. Reach out any time to discuss your goals, your challenges, or your upcoming plans. TalentTech can help you design the HR Tech enabled experience that turns outcomes into value.
This article is republished from TalentTech with permission, visit website for more details: https://www.talenttech.co/
