How the work was specified

Two things that sit behind the case studies: who does what in the research and checking process, and how I wrote down what each feature needed to do before it was built.

Back to the case studies

Who does what, before and after

The same process as the timeline on the front page, this time split by who carries out each step. The point of the redesign was to move checks off people and into the form, and to give the senior researchers a process they could run themselves.

Before Researcher Data entry Checking Database Paper form, by post Typed up from paper One person, 50pp guide Updated, months later 2 months 1 month 3 weeks After Researcher The form Senior researchers Database Works a record online Checks entries at source Five staged checks, 1 hour Live, same week as typed batches of 100 same day

Drawn from the processes as they run now. The lanes are the people and systems that hold each step, which is what made the bottleneck in the old version visible: everything waited on one person with a 50 page guide.

What each feature had to do

Requirements for four features I specified and then built or had built, written as user stories with the conditions I tested against before anything went live. The wording is tidied up; the substance is what was agreed at the time.

Validation at the point of entry

As a researcher, I need the form to stop me entering something obviously wrong, so that errors are caught while I still have the company on the phone.

  • Fields with a fixed set of answers are chosen from a list, not typed
  • A record cannot be marked done with a required field empty
  • An invalid postcode or phone number is refused at the point of entry
  • Nothing about the way the checks work changes what a researcher has to remember

Built into the research form.

Staged checking of a batch

As a senior researcher, I need to take a batch of records through the same stages every time, so that nothing is skipped when I am interrupted part-way through.

  • A batch moves through five named stages in a fixed order
  • A person makes the decision at every stage; the platform records it but does not decide
  • Progress is visible at a glance, so a batch can be picked up later or by someone else
  • A batch cannot be exported until every record in it has an outcome

Built as the checking platform.

Sending from inside the platform

As a customer, I need to email a selection of companies without exporting the data first, so that I can run a campaign without handling a spreadsheet.

  • A selection can be emailed from the screen where it was made
  • The data stays inside the platform rather than leaving as a file
  • The customer who asked for it uses each change before it reaches anyone else
  • Each change is tested against how it will actually be used, not just that it works

Specified for the external agency who develop the customer platform, piloted with one customer, then released.

Payments landing on the right date

As a director, I need the forecast to show money arriving when it actually arrives, so that I can decide which suppliers to pay and when.

  • Payments that arrive grouped in one settlement are attributed to the right customer
  • Each one is dated when it was paid, not when it was invoiced
  • A payment that cannot be matched keeps its original date rather than being guessed at
  • The position reconciles against the bank, not only against the accounts software

Built into the forecasting tool.