CASE STUDY: NHS East London Foundation Trust (ELFT)

The East London Foundation Trust (ELFT) is an NHS Community & Mental Health Service of 5,000 staff.

The objective of the ELFT project was to replace the existing intranet which was no longer fit-for-purpose.

NHS East London Foundation Trust (ELFT) Homepage

NHS East London Foundation Trust (ELFT) Homepage

Step 1: Stakeholder interviews

The first step is to elaborate on the initial brief through a series of interviews with key project owners and influencers. The intention of this is to discover: why the project is happening; who the users should be; how the platform should fit into the wider digital workplace ecosystem, and; any future projects that might have an impact. The top business drivers were revealed to be:

  • Process efficiency
  • Easy access to information
  • Staff connections
  • Personalisation
  • Mobile working
Embryonic user experience map
Embryonic user experience map

Step 2: Embryonic 'user experience map'

In order to analyse the information gathered from stakeholders, we created an embryonic ‘User Experience Map’. This allowed us to spot areas to investigate further, reveal the gaps in our knowledge and identify the specific staff that would give us the further insight we needed to complete the map. It also allowed us to devise a set of targeted questions for each member of staff we were to interview.

Step 3: 8 contextual user interviews

Owing to the huge variety of workplace environments within the Trust, we opted to conduct our interviews in person at the interviewees’ place of work. This provides us a real-world experience of the work environment and a deeper understanding of the issues faced. Specifically, we identified a strong correlation with stakeholder priorities that easy, quick access to information was vital. But the interviews also allowed us to specify more accurately the types of information they need – and when:

  • During patient care

    = Procedures, policies, guidelines and information
  • During patient transfer

    = Staff and service contact information
User Survey Results
User Survey Results

Step 4: User survey

We also conducted a survey to acquire some more quantitative data on staff priorities. In particular, we provided staff with a list of the functionalities and features suggested by the stakeholders and asked them to select their top 3. Interestingly in this case there was a difference between stakeholders and staff. Where the stakeholders had predicted that ‘mobile working’ should be a top priority, not a single survey respondent picked this as a priority. Much more important, it seemed, was to get the information they need when they sit down at their desk to do their paperwork.

Step 5: Content audit

The final phase of research centered around the content that existed already. We conducted an audit of the priority information in an attempt to understand:

  • The breadth of the data that was required
  • The existing quality of information
  • The information that can and should be removed
  • Past content successes and failures
Stakeholder Workshop
Stakeholder Workshop

Step 6: Workshop

While we had invited our clients to observe some of the research we conducted, they had been largely (and quite deliberately) kept out of the analysis we had been conducting throughout. The 1-day workshop was therefore the first opportunity for us to:

  • Present our findings
  • Generate (and align on) ideas
  • Prioritise functionalities and features

Step 7: Prioritisation, cost/effort analysis & final scoping

Following the workshop we ran a final prioritization analysis based on the SmallWorlders Engagement Framework. But at this point it was important take a step back and re-visit the original requirements. The research had entirely changed the focus of the project from the potential of a news, events and social platform to a procedural and contact information hub. We therefore re-visited the scope of the project to ensure the must-haves could be prioritised prior to launch.

Card Sorting Exercise
Card Sorting Exercise

Step 8: Open card sort & site architecture

Finally, we arrived at the design phase. But before we talked about pages or functionality, we needed to ensure that the structure of the site met the following objectives:

  • Easy to understand
  • Informative
  • Drives users to priority information

To do this we ran a card sort with 50 users. We asked them to categorise a list of 50 items into 5-8 groups and to name those groups. From this we ran various analyses to come up with a structure that represented how staff think and how the platform should be organized.

Step 9: Agile build

The following steps were completed through an agile methodology. Each section of the site was designed and built in conjunction. Some pages were therefore fully built before the wireframing of others had begun. The learnings from the first section were fed into iterative updates for the next section – and so on until all sections were complete.

ELFT Wireframe Prototype
ELFT Wireframe Prototype

Step 9a: Sketch and wireframe from the inside out

Contrary to popular thinking (and indeed to the expectation of many stakeholders) our approach focuses first on the content – the end point of our users’ journey. Once these pages were discussed, sketched, wireframed and put through some basic guerilla tests, we zoomed out to tackle the pages that directly link to this content. These were typically the lowest branches of the navigation we proposed in the previous step. Again once those were complete we could zoom out further and tackle the group pages and finally the homepage. Designing and testing in this way allowed us to solve the most important issues first – those of accessing information. It was also essential to understand the granular-level content priorities before combining them into group and homepage page structures.

Step 9b: Prototyping and user journey testing

Once each journey from landing page to content had been wireframed, we ran some usability tests to ensure users were able to find the correct information under certain scenarios, in particular those mentioned under “Step 8: Contextual Interviews”. It is through this process that we discovered how users might search and what information we needed to provide them to help them intuitively understand where to go.

Step 9c: Visual design

Finally we added the finishing touches to the platform through colour, fonts and styling. The intention was to use a similar design aesthetic to that of the public-facing website, but ensure it was easy to tell which site users were on. The design was therefore given the same visual elements, but the primary and secondary colours were adjusted.

Presenting the concept
Presenting the Concept

Step 9d: Template build and final testing

By this point pages and journeys had been through a number of iterations and testing procedures, so all that was left was to build and overcome any small technical issues that arise. The client had been given the chance to feed back on each step and so were very enthusiastic about the outcome. Each page had been carefully designed to focus users on the information they need at the time they need it, with personalized lists of relevant documents prevailing the entire site.

Step 9e: Content population

Once all the pages and templates had been set up for a particular area, the communications team set about migrating content from the old platform to the new. Priority was given to staff contact information, procedural documentation and guidelines. Once these were imported, the rest could follow.

Step 10: Beta Launch and Final Tweaks

For the final round of testing and iterative updates, the site was released to a small group of early pioneers. They were selected from a range of staff from IT champions to ward staff, and they were given the chance to take a look around, use it during their daily routine and feedback on any issues they found. No major bombshell’s were uncovered, and some of the quick-wins were implemented. Other feedback was noted and placed in priority order together with all the other features and functionalities generated by the workshop in step 6.


The platform is now preparing for launch on 14th December and looks set to make an impact on the daily lives of staff around the trust. Through the SmallWorlders process we uncovered:

The user requirements were to access contact details and procedural documentation when they need it. The platform should be function-driven rather than news or social-driven.And through an agile process of design, testing and iterative updates, we ensured that it met objectives and was intuitive to use, even before a single line of code was written or a single button was clicked.