Rob Rigby

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

Process

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 Before Researcher Paper form, by post Data entry Typed up from paper Checking One person, 50pp guide Database Updated, months later 2 months 1 month 3 weeks After Researcher Works a record online The form Checks entries at source Senior researchers Five staged checks, 1 hour Database 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. In the old version every record went through one person with a 50-page guide; in the new one, the checks can be run by anyone with a little training.

Requirements

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

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
  • There is an email-all button and an email-individual button
  • It is clear which contact on a record an email-all goes to

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.

  • Direct Debit payments that arrive grouped in one payout are attributed to the right customer
  • Fees show as their own entries, separate from the payments they were taken from
  • Each payment 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.