👷‍♂️📈 Rebuilding Our Reporting Feature: The Design Sprint

Dale Alexander Webb
Bad Practice
Published in
4 min readDec 2, 2016

This follows on from this story: https://medium.com/bad-practice/rebuilding-our-reporting-feature-a-problem-well-stated-is-a-problem-half-solved-22fab8e1775b where the team and I discovered that a feature we largely ignored, actually was of significant value to our users.

At this point we had to investigate the users of this feature. For this, we were inspired by the Jobs-To-Be-Done (JTBD) methodology. In short, this approach focusses on uncovering the jobs your product was hired for, rather than the more common personas approach.

We had broken the rules a little here, as our product is used by staff within a company with well-defined job roles. So our JTBD had a pinch of personas.

Our email to all our adviser users

We sent out an email from our favourite tool, Intercom with the email subject being a question that every worker wants to hear: “How can I make your job easier?”. The reason for this approach was to let our users know that we want to help and we’re listening! Whilst the responses from this could generate a lot of noise, we wanted to know who has the most pains and who felt them the most.

We had some in-depth responses and lengthy email exchanges. From those, some of our users were happy to talk with us over the phone to clarify some points that they made.

Here are the JTBD, in relation to the reporting feature, we uncovered from these interviews:

A “Work Coach” will assist people looking for jobs in activities such as writing CVs. They refer to these jobseekers as customers.
A “Jobs Broker” will source job vacancies for jobseekers.
A “Centre Manager” manages staff (Jobs Brokers and Work Coaches) in a centre that is designed to help people find work.
A “Regional Sales Manager” manages Jobs Brokers over a geographical region in the UK.

We noticed that the frontline staff (Jobs Brokers and Work Coaches) seemed to need the bottom-line figures for themselves and individuals they work with. However, the management staff (Regional Sales Managers and Centre Managers) cared about performance over a particular time period and wanted the data to try to increase performance.

To move the conversation forward with our interviewees, we created a first revision of what we believed reporting would look like:

The idea behind this interface was to have expandable metrics, where a user can see the bottom-line figures at-a-glance, then dive deeper into each area by expanding the cards. This would zoom into a day-by-day, week-by-week or month-by-month breakdown to show the distribution with the option of seeing specific details.

We sent this back out through Intercom and got some thumbs up (which generally aren’t super useful) but there were no bad comments. More importantly, we had some questions back and things that users want included.

We quickly spun up a new iteration:

This one allowed multiple metrics can be viewed at-a-glance, so that a user like Bianca can choose what to see. We only allowed one chart per card, with a maximum of three chosen metrics to be inspected, so there would be a maximum of three series per chart (rather than multiple charts). Her last comment was not relevant at this stage of the reporting feature as this focussed on the performance of the centre (Persona group).

After we were confident that this would satisfy our users, we had our “north star” to aim for.

Now to start coding in the workshop!

--

--