Skip to main content

Introducing the Needotron: working out the shape of the product

Posted by: , Posted on: - Categories: GOV.UK

Working out the exact "shape" of the beta has been a long, difficult process.  Working out what needs it should meet, how best each need should be met and then defining how the whole proposition hangs together are hard problems.

But gaining a clear, shared understanding of this overall 'shape' is also fundamental to building a good digital product - "Every superfluous page we create is one more dead end for an angry, frustrated, confused user"

This blog post is about how we went about defining the shape of the citizen-facing beta of, and the tools we developed along the way.

Before continuing I should add a caveat: this is just the first iteration of identifying user needs. It is essential that the shape of the product will continually iterate throughout its life, as will its underlying code, design, user interface and content.

Starting the long journey from 'articles' to 'user needs'

We started with long lists of pages and search terms from Directgov.  These we rephrased into statements describing something you might need from the government. Things like "I need to report a lost passport" or "I need to learn what Jury Service involves". This gave us around 1,800 individual user needs, (or "tasks").

We then

  • Decided which of these initial 1,800 user needs should be included in the beta
  • Aggregated those needs which made more sense to be together
  • Assigned a format  to each user need (in a 'format' is a type of webpage or webapp e.g. a multipart 'guide', a simple answer page, a 'find my nearest' webapp. There are getting on for 10 at the moment)
  • Assigned a priority to each user need

The Needotron

The team built a small webapp (source-code available on github) to manage this process and assigned each need a number, which allowed us to track its process. Here's what it looks like:

Screenshot of Needotron webapp

The Needotron tracks the history of a need through the process and records the reasons for decisions. Things either end up being merged, binned or get a format assigned.

Scope: Should try to meet this need?

We developed the following rules to help us decide which needs we should - and shouldn't - be meeting.

  • Do people want it? (based on traffic and search data)
  • Can people reasonably expect government to be responsible for meeting this need?
  • Can only government meet this need? (or is someone else doing it better already?)
  • Is it explaining someone's rights or obligations?
  • Is it transactional or encouraging a shift to digital by default government services?

How should we group, prioritise and format these needs?

Grouping, prioritising and formatting these user needs ended up being an epic task, involving people from across GDS.

The first couple of approaches we tried were not completely successful. First  we tried to organise the data using , then tried to apply analytics data directly.  Sadly these approaches didn't give us a clear enough answer, though it all helped build up a collective picture.

The method that finally worked was to first remove the needs that obviously fell outside of scope. This changed a huge problem into a big one. We then grouped the needs into broad subject areas (housing, police, pensions) to break the one big problem into many smaller ones. From there groups of 2 or 3 people discussed what should be merged, what should be binned and what format things should be.

All this was done as a paper exercise with the final result copied into the needotron.

Composite of 4 pictures of the beta team working on needs


We then assigned a priority to each need based on their knowledge of search analytics on Directgov. First working individually they each scored the needs as high, medium and low. The scores were then combined to create an overall score.

This prioritisation is being used to make sure we work on the most important things first, and invest the development time in building a handful of bespoke app for the needs that are both important and significantly differentiated - things like reporting a lost passport.

For clarity, this is not the same as saying that one need is more important to a particular user than another - everyone needs different things from government and we aim to meet them all and build in custom analytics into each page to make sure we do so.

The results

We currently have just under 950 needs with formats and priorities assigned, with a similar number either discarded or, more commonly, merged together to form broader needs.

This treemap shows the breakdown by format:

Towards a product dashboard

We are planning to develop the Needotron into a fully fledged product dashboard, to help product managers understand how well each and every need is being met. It will give a view across the full technology and content stack (from the server that it is running on, to the version of the code deployed, to the edition of the content deployed). Crucially, it will also act as the aggregation point for all product analytics, highlighting explicit and implicit user feedback and giving access to A/B test results etc.

Its name started out as a bit of a joke, but the Needotron has quickly become the core of the whole project.

Sharing and comments

Share this page


  1. Comment by Phil posted on

    The needatron is a requirements management tool. You guys should be commended for investing time in requirements. The sad fact of life is that the majority of projects fail because no time is spent considering what the project should actually deliver. Requirments should drive the design and you guys are delivering value by doing that. Money well spent in my view!

  2. Comment by Etienne Delagrave (@edelagrave) posted on

    Just curious : why not use a backlog application to do that? Trello for exemple.

  3. Comment by The 10 UX principle behind GOV.UK « Sailfish Media posted on

    [...] Start with needs (user needs, not government needs). identify what the user needs and design and organise the site around them. Find out more about user needs and the ‘Needotron’ [...]

  4. Comment by why this new government website really matters | Opentopic testing center posted on

    [...] page we create is one more dead end for an angry, frustrated, confused user in announcing the Needotron, our tool for identifying and filtering the real needs of [...]

  5. Comment by Clement Oke posted on

    Kudos to you and the team. I wouldn't listen to the naysayers who haven't a clue about what it means to speak in plain English as opposed to showing how clever you are (or not) with geek speak.

  6. Comment by why this new government website really matters | Technology News posted on

    [...] page we create is one more dead end for an angry, frustrated, confused user in announcing the Needotron, our tool for identifying and filtering the real needs of [...]

  7. Comment by why this new government website really matters | Tech News posted on

    [...] page we create is one more dead end for an angry, frustrated, confused user in announcing the Needotron, our tool for identifying and filtering the real needs of [...]

  8. Comment by Why GOV.UK matters: A platform for a digital Government | Government Digital Service posted on

    [...] puts user needs above all. In September last year, while announcing the Needotron, our tool for identifying and filtering the real needs of users, my colleague Richard Pope wrote [...]

  9. Comment by Why GOV.UK matters: A platform for a digital Government | Government Digital Service posted on

    [...] puts user needs above all. In September last year, while announcing the Needotron, our tool for identifying and filtering the real needs of users, my colleague Richard Pope wrote [...]

  10. Comment by Importanta verbalizarii procesului » Bogdana Butnar .ro posted on

    [...] simplu, daca oamenii spun “start with needs” exista un alt site unde poti citi in detaliu cum si de ce fac acest lucru. In cazul de fata prin crearea unui [...]

  11. Comment by Introducing the next iteration of GOV.UK | Government Digital Service posted on

    [...] using the same approach as for other content in the beta – identifying needs, and then working out the best way to meet them by writing content or building simple to use tools. [...]

  12. Comment by Are digital public services finally set to become a reality? | | posted on

    [...] in ad hoc teams, having their daily scrums. There’s a “success wall” and the Needotron – an in-house application to record and monitor business needs (with the code available to all as [...]

  13. Comment by Welcome « Clear message posted on

    [...] the things the new website is not promising to deliver any time soon. The things that can’t demonstrate a need from the audience. Nor is the Government Digital Service going to try and sort out conflicts between different parts [...]

  14. Comment by Introducing the beta of GOV.UK | Government Digital Service posted on

    [...] have re-written, re-designed and re-thought 667 of the needs people have of Government (broadly, those currently catered for by Directgov) - making them as findable, understandable and [...]

  15. Comment by Using search data to meet user needs | Government Digital Service posted on

    [...] out first and then the GOV.UK beta, search data was a key driver in the process of gathering user needs. The key question was “were people looking for it and what were they calling [...]

  16. Comment by It’s all about the words | Government Digital Service posted on

    [...] take good editorial work for granted. We’ve already talked about how we are identifying user needs and content titles for but this post looks at how we are developing our editorial [...]

  17. Comment by js posted on

    are you explaining this most basic of stuff in an Andy Pandy tone because you are doing it for the first time yourself? for the nation's sake, i hope not....

    • Replies to js>

      Comment by ChrisF posted on

      I assume they're using this 'Andy Pandy' tone for the majority of readers who aren't IAs or UXDs.

      Great article in support of a great (wider) approach to the project. The beta site is already looking vastly more impressive, usable and relevant than most everything else I've seen from the public sector.

  18. Comment by Alex Balfour (@AlexBalfour2012) posted on

    Nice work. Did you analyse search engine based search data (as opposed to searches performed on your site or keyword traffic to your site) on keywords and terms using search engine tools so you know what terms people are searching google for - and may not always end up on your site? Volumes and actual terms used are important and should inform your model further. This will also help determine what words people actually use when searching for stuff.

  19. Comment by Why do people need government department websites? | Government Digital Service posted on

    [...] than has been done for the citizen-facing part of the domain. A fine-grain study à la (brilliant) Needotron 5000 would have bogged me down in analysis paralysis and made delivery by early 2012 [...]

  20. Comment by Tony Gilbert posted on

    This has so many parallels to the approach we independently developed only this month to inform the identification and prioritisation of the "next 500" topics for our government business and industry website.

    However, we did go the extra mile in consulting with stakeholders, customer groups and customer-facing staff in call centres, counter services and field services. That process has produced some interesting outcomes and we are now starting the prioritisation process using that data combined with demand metrics from both analytics and Google keyword search data.

    I really like the "Needotron" concept and hope we can adapt it to what we're doing here.

  21. Comment by Andy Bold (@AndyBold) posted on

    Liking the look of the need-o-tron very much indeed. Are there any particular licenses to be aware of? (Public domain, GPL, or some other?) I couldn't see anything in the source and wanted to avoid possible pitfalls of using this in GPL-unfriendly places. (If GPL applies, of course.)

  22. Comment by Neilfrog posted on

    What a lot of nonsense. Even more worryingly, who is funding this?

    • Replies to Neilfrog>

      Comment by John Gibbard posted on

      In what way is this nonsense? I'm all for debate and a contrary view but please do expand on your criticism otherwise your comment just feels like ignorance.

      As far as funding goes, I don't have the answer but if taxpayers' money is being spent to make Government services online (much) easier to use, universally, then I wouldn't consider that a waste of funds.

      • Replies to John Gibbard>

        Comment by erica961 posted on

  23. Comment by vickysargent posted on

    Very interesting to see the approach is focussed on tasks, which is what Socitm is recommending for local authorities and which is driving our new approach for Better connected, Socitm's annual survey of all local authority websites.

    Have you any plans to engage with local authorities and other local public services (police, fire & rescue, housing, education, third sector provision) about our 'top tasks' and the customer journey to local sites from beta?

    • Replies to vickysargent>

      Comment by Richard Pope posted on

      Absolutely - a task like 'pay my council tax' falls neatly into the category you describe. We are building a tool that does a a post code lookup then directs you to the relevant page on your local council's website, much in the same way as Local Directgov does now.

  24. Comment by Michele Ide-Smith posted on

    Very interesting post Richard. A few things spring to mind as I am currently going through a similar process (albeit on a smaller scale) of identifying families information needs for a revamp of the web based information we provide.

    1. Have you considered using other data sources to identify the 'needs' (or tasks as I prefer calling them)? For example helpline data for key services provided through DirectGov?

    2. In terms of how the list of needs was grouped and prioritised, did you consider getting users' input? For example using a card sorting tool like Optimal Sort to group categories? If you haven't already come across it I would also highly recommend reading about the 'task voting' method in Gerry McGovern's book The Stranger's Long Neck for details on how to prioritise a list like this. I think it's really important to get user input early on, even if you are working in an Agile way.

    Very interested to know how the 'Needotron' comes along. I'd like to try installing it to try it out, but not sure I've got the necessary techie skills! Does it hook into Google Analytics API directly to get the A/B test results?

    • Replies to Michele Ide-Smith>

      Comment by Richard Pope posted on

      Thanks Michele. Call centre data isn't something we've looked at yet, but is a great suggestion.

      The prioritisation exercise was very broad - high, medium and low rather than trying to assign an order to everything. We did experiment with using to create an absolute rank, but it created more questions than it answered.

      A/B testing - the aim is that the Needotron becomes the fulcrum for managing the beta product. It will act as a dashboard drawing analytics, A/B tests and infrastructure information together in one place.