Most digital workplace projects are scoped on assumptions about what employees need. A discovery replaces the assumptions with evidence – user research, stakeholder interviews and a technical review of what you already own – and produces a roadmap your board can actually sign off.
Most of our projects start here. Not all of them need to.
What it is
A fixed-scope research engagement that establishes what your employees need, what your Microsoft 365 estate can already deliver, and what to do first.
How long
Two to eight weeks depending on the size of the organisation and how many locations or languages are in scope.
What you get
A research report, a prioritised roadmap, an information architecture recommendation and a requirements set - enough to build a business case on, or to run a tender from.
Is it compulsory
No, but some form of discovery always pays. Where you already have solid research, we scale it down to knowledge transfer and recommendations rather than repeating work you have done.
Six questions, evidenced rather than assumed – whether the project in front of you is an intranet redesign, a migration, or a broader digital employee experience programme. If you can already answer all six with data, you do not need a discovery. You need someone to design and build against what you already know.
Interviews, focus groups, surveys and observation across a representative cross-section, including the groups that usually get missed. The output is documented pain points - bottlenecks, search fatigue, and tool overlap where three systems half-solve the same job.
A technical review of your tenant, your licensing and what is already configured. Frequently the cheapest finding in the report.
Whether a product like Lightspeed365 fits better than a bespoke build, and which existing systems should be switched off.
A prioritised roadmap rather than a wish list. Phase one is scoped tightly enough to be funded on its own.
Baseline measures taken during the research, so that adoption can be evidenced afterwards rather than asserted.
Stakeholder mapping across IT, internal comms, HR, operations and knowledge management. Usually the reason projects stall.
If you have run your own discovery, or had one done elsewhere, send it over. We will review what you have, tell you where the gaps are, and scope a design and build against it. There is no requirement to repeat research that has already been done properly.
Five elements run in parallel, then a synthesis step. Summaries below, detail on expand.
Interviews, focus groups and observational research across a cross-section that genuinely represents your workforce - not just the people who volunteer.
In an intranet discovery this is the element most often cut for budget, and the one that most determines whether the finished product gets used. Workforces are more varied than the requirements documents written about them, and one group’s essential tool is another group’s clutter – so the research segments the workforce rather than averaging it. That is what supports a personalised intranet with targeted content, rather than one homepage serving everybody equally and nobody well.
Employees tell you what they need. Business leaders and IT managers tell you what the organisation needs. There may be some overlaps, but there are often differences that need to be resolved.
Stakeholder input is what determines scope and prioritisation. User research tells you what would be valuable; stakeholder research tells you what the organisation will fund, and in what order. Where the two pull against each other the report says so and recommends a resolution, rather than leaving it to surface during the build.
An expert evaluation of the existing intranet - navigation, information architecture, and level of adherence to best practice user-experience principles.
The measure that matters is friction: how long it takes to find an internal document, and how often people give up and ask someone. Migration cost is driven by content volume above anything else, and most organisations carry a great deal nobody has opened in years.
Most organisations already hold years of evidence about what is not working. Very few have read it back.
This element costs the least and frequently changes the most. Quantitative findings from your own data are also harder to dismiss than qualitative findings from interviews, because nobody can argue the sample was unrepresentative.
The SharePoint discovery half of the work, and the element most discoveries leave out - a current state assessment of your tenant, licensing and what is already switched on.
A research-only discovery will tell you what people need. It will not tell you that you are already licensed for two thirds of it. Frequently the cheapest finding in the report, and the element a pure UX consultancy cannot run.
A playback of insights from the research combined with our own extensive experience, and a clear set of actionable recommendations for the path forward.
The report does not stop being useful when the project starts. It feeds the business case, the design, the change management plan and the adoption approach, and clients return to it after launch when someone asks why a decision was made.
Design work happens inside the discovery, not after it. It is what turns findings into something stakeholders can react to.
We wireframe the pages and journeys the research points to, so people can see the solution rather than read a description of it. That is a different conversation. Stakeholders refine something in front of them, and disagreements that would otherwise surface three months into a build surface in week five, when resolving them costs a conversation rather than a change request.
Every screen is annotated, so each design decision traces back to a specific research finding rather than to a designer’s preference.
Where it would help, we make the wireframes clickable and interactive. That lets stakeholders move through a journey end to end, and it means we can test the structure with real users before anything is built – the cheapest point at which to find out that a navigation model does not work.
If you want a different provider to build the solution from our specification, we make sure additional information is added to keep them on track.
The artefacts that ensure what you build remains on brief – meeting all the requirements and not drifting from the core objectives.
Findings with the underlying evidence attached, so the recommendations can be challenged rather than taken on trust.
Functional and non-functional, in a form you can put straight into a build or a competitive tender.
Sequenced, with phase one scoped tightly enough to be funded and approved on its own.
A separate short version written for people who will not read the full report. Designed to drop into a business case or funding paper.
Structure based on how your people look for things, tested rather than assumed.
The pages and journeys the research points to, made clickable where that helps stakeholders test and refine them.
Two to eight weeks depending on scale, priced as a fixed fee against an agreed scope.
One country, one language, a largely desk-based workforce and a settled stakeholder group.
Several locations, two or three languages, or a set of requirements that needs unpicking rather than recording - integrations, regulatory constraints, or functions whose needs genuinely conflict. The extra weeks go on understanding the requirement properly, not on travel.
Two things drive the length, and neither is process. The first is research volume: sampling across a dozen countries and running sessions in several languages cannot be compressed without the research stopping being representative, which is the only thing it is for.
The second is scheduling. Engaging thirty or forty stakeholders means working around thirty or forty diaries, and none of those people has been given time off their day job to help with your intranet. Getting an hour with a regional operations director is often slower than the research itself, and building that reality into the timeline is more honest than quoting six weeks and then explaining the overrun.
If the timeline does not fit a funding deadline we phase it – a three-week first pass to support the business case, with deeper research running alongside phase one.
The five elements run in parallel, which is what keeps even the enterprise tier to weeks rather than quarters.
Afterwards
The deliverables are yours. Three of these four do not involve us building anything.
1
The most common immediate use. A business case usually lacks a documented current state, evidenced user need rather than assertion, and a phase one small enough to approve on one budget cycle. The report supplies all three, and several clients have taken the board summary more or less intact into a funding paper.
2
Tell us at the outset and we scope in a build-ready design pack - annotated wireframes, specified states and behaviours, documented edge cases - that an internal SharePoint team can work from directly. We will review as you go if you want a second pair of eyes, or stay out of it.
3
The requirements set is supplier-agnostic by default, so it goes into an RFP or tender pack without editing - requirements, success measures and information architecture all travel with it. We would rather compete against a well-specified brief than win a vague one, and we have lost tenders run off our own discoveries.
4
Design, development, migration and rollout on SharePoint and Microsoft 365 - or Lightspeed365 where the research points to a standard intranet delivered quickly. The discovery cost is not credited against the build; it was a separate piece of work and stands on its own.
Proof
LEK came to us for one intranet. The research found two distinct problems.
“Content Formula worked closely with our team to deliver a new and innovative digital workplace experience for my company… beginning with the discovery phase, requirements gathering, identification and design of key UX features, proof of concept, build, user acceptance testing, and launch.”
“They took the time to understand our organization and its needs… Our new intranet has been very well received with engagement at 80%+ in the first few weeks.”
Susan Inman, Director
L.E.K. Consulting
The brief was a single intranet. The research separated internal communications from knowledge management, and the engagement delivered both – a communications hub, and a knowledge platform that became the home for the firm’s intellectual property and case delivery material. Splitting them was a discovery finding, not a client instruction.
From the team
Half an hour on what you already know, what you are assuming, and where the gaps are. That is usually enough for us to tell you whether a discovery is worth doing, roughly what it would involve, and what it would cost.
Common questions
A digital workplace discovery is the foundational research phase used to establish an organisation’s current technology ecosystem, how employees actually work, and what the business needs the digital workplace to deliver. It covers user research including interviews, focus groups and observational research; stakeholder engagement across IT, communications, HR and operations; heuristic and content review of the existing intranet and its information architecture; and analysis of existing data such as help desk logs, past engagement surveys and search logs. It produces documented pain points, personas, a prioritised roadmap and a requirements set.
Two to three weeks for a single-site organisation under about 1,000 people. Four to six weeks with multiple locations or a significant frontline workforce. Six to eight weeks for a multi-country, multi-language enterprise, where the length comes from research volume and stakeholder scheduling rather than process. Shorter engagements sold as readiness assessments typically run one to six weeks, but those analyse configuration and governance rather than conducting primary research. It can be phased if a funding deadline will not wait.
It is quoted as a fixed price against a written scope rather than from a price list, because cost is driven almost entirely by how much primary research is needed – and that varies more between organisations of the same size than most people expect. A single-site business with a desk-based workforce is materially smaller work than a multi-country enterprise with a frontline population nobody has researched. We scope first, then quote, and the figure does not move unless the scope does.
Sometimes not, and we will say so. If you have recent user research, a settled information architecture and real agreement across IT, communications and HR, a discovery would largely confirm what you hold. More often one of those exists and the other two are assumed – the test is whether you can state what your frontline staff need, with evidence, without asking anyone. If you have already run one, send it over: we will review it, say where it is solid and where the gaps are, and scope a build against it.
An executive sponsor for two or three conversations, a project lead as the day-to-day contact, and access to a genuine cross-section of employees for interviews and workshops. On the stakeholder side, usually IT, internal communications, HR, operations and whoever owns knowledge management. Realistically that is two to four hours a week for the project lead and considerably less for everyone else – the research effort sits with us, which is most of the reason organisations bring it in.
