The software feels like theirs because, in a meaningful way, it is.
They helped decide what matters, how the work should flow and what the experience should feel like.
Most software adoption begins after the important decisions are over
A traditional implementation works towards a handover.
The product is selected. Requirements are gathered. Configuration is completed. The finished system is presented to the people expected to use it.
Then training and change management begin.
We ask people to become invested in decisions they did not make and an interface they did not shape.
When they resist, we often describe the problem as adoption.
Sometimes it is authorship.
The IKEA effect applies to software too
Researchers Michael Norton, Daniel Mochon and Dan Ariely used the term “IKEA effect” to describe how people place more value on things they have helped create.
The effect is not that flat-pack furniture is objectively better.
The work creates a feeling of competence and ownership. The finished object contains evidence of the person's participation.
The same idea is useful when thinking about internal software.
People do not need to write the code. They need to recognise their judgement in the result.
They should be able to say:
We decided this was the information that mattered.
We changed this step because the old handover always failed.
We asked for this view because it helps us notice a problem earlier.
That is very different from being consulted about the colour of a button after the workflow has already been decided.
AI has shortened the distance between an idea and an experience
In conventional software projects, interface decisions become expensive early.
A team may live with a poor screen because changing it requires a new procurement process, a vendor request or a development project. As a result, requirements are gathered in large batches and users are asked to imagine the finished experience.
AI-assisted development makes a different rhythm possible.
We can sit with two to five people, observe their work, create a small working interface and let them respond to something real. A board can become a timeline. A form can become a conversation. A dense dashboard can reveal that only one exception actually matters.
The people doing the work can assemble the experience with us.
The specification and interface improve together.
Participation does not mean building everything from scratch
This is where a Headless foundation matters.
The team can shape its own experience without redesigning identity, permissions, audit history, customer records and integration patterns.
The protected foundation is shared.
The working surface is local.
That distinction prevents co-design from becoming a collection of fragile personal applications.
People get meaningful influence over what they use while the organisation retains dependable records and controls.
They assemble the parts that should be theirs.
They do not rebuild the plumbing.
Software no longer has to appeal to the lowest common denominator
Large software products are designed for enormous, conflicting audiences.
They are often purchased by senior administrators, technology leaders or risk-conscious buyers. The interface has to look credible across industries, roles and cultures. It cannot be too strange, too colourful or too specific.
That produces a certain kind of professional grey.
A small internal experience has different constraints.
One team may want strong colour and animation because they spend all day moving work through a visual process. One person may understand the organisation geographically and want a map. Another may want a quiet daily list with three actions and nothing else.
These are not frivolous preferences if they help someone understand and enjoy the work.
Software can have joy without losing seriousness.
The interface can reveal how a person thinks
Generic software asks different people to think in the same shape.
Headless software can adapt the shape while preserving the underlying meaning.
A relationship manager may think in conversations and commitments. A programme manager may think in milestones and dependencies. A leader may think in exceptions and outcomes.
The same operational records can support each view.
Co-design is valuable because it reveals these mental models. The team is not merely requesting features. It is showing how it recognises progress, risk and completion.
That insight belongs in the organisational specification, not only in the interface.
Why this improves adoption
People are more likely to use a system when three things are true:
- it removes work they dislike;
- it reflects how they understand the job; and
- they can see their contribution in the result.
The first condition creates utility. The second creates comprehension. The third creates ownership.
Together, they change the rollout conversation.
The team is not waiting for a finished product to be imposed. It is already using and improving a working version.
Training becomes lighter because the interface contains decisions the users helped make.
Change management becomes participation in the build.
The IKEA effect has a warning built into it
People can overvalue what they helped create.
That is part of the original idea.
A team's affection for its own application does not make the application safe, maintainable or useful to the wider organisation. Co-design can produce unnecessary features, personal conventions and resistance to retiring something that has outlived its purpose.
Ownership therefore needs boundaries.
The organisation should still require:
- shared records and definitions;
- common identity and permission controls;
- reusable design and integration components;
- testing before consequential actions are released;
- a named owner;
- evidence that the interface removes real work; and
- a way to retire or replace it.
The IKEA effect can help adoption.
It is not a substitute for architecture.
Build with people, not merely for them
A useful co-design rhythm is simple.
First, observe the work rather than asking for a feature list.
Second, agree on the outcome and the records that matter.
Third, build one thin experience quickly enough that people can respond to reality.
Fourth, watch them use it. Notice where they hesitate, what they ignore and what they try to do that the interface did not anticipate.
Fifth, make the next decision together.
The team should participate throughout the loop, not appear at the beginning for discovery and at the end for training.
This is one reason small AI builds are adopted faster. The distance between the problem, the builder and the user remains short.
The deeper organisational change
When teams can shape small software experiences safely, software stops being a fixed environment handed down to the organisation.
It becomes a way the organisation expresses how it wants to work.
The shared foundation remembers the common reality. The specification describes the rules and outcomes. Small interfaces let teams participate in turning those ideas into everyday behaviour.
This does not remove the technology function.
It changes its role from supplying every screen to providing safe foundations, reusable parts and skilled partnership.
The organisation becomes capable of changing its software at something closer to the speed it changes its mind.
Bottom line
People value software more when they can see themselves in it.
The IKEA effect helps explain why participation creates ownership, but the opportunity is larger than a psychological trick. AI-assisted development and Headless foundations make it practical to build software with the people doing the work while keeping records, permissions and governance consistent.
Give people influence over the experience.
Keep the foundations shared.
The result can be safer than a personal workaround, cheaper than another departmental platform and far more enjoyable to use.
