IMPROVING PROCESSES: MENU TICKETS
IMPROVING PROCESSES: MENU TICKETS
Embedded Files
THE PROBLEM
THE PROBLEM
John Lewis in-store staff update pricing tickets on a daily basis. With prices changing in response to deals, promotions and other factors, it is a vital process that gives customers the most up to date information.
The existing ticketing hardware, know as an HHT gun (handheld terminal) was slow, cumbersome and reaching end of life. To improve the Partner experience, save time and money we were asked to migrate the function to the Partner Device. Ticketing app was rolled out in stages; Menu tickets were a special type of pricing label that included multiple products at once.
DISCOVERY
DISCOVERY
We shadowed a number of in-store Partners as they used the existing HHT guns to see the current process. From this we gleaned a fairly substantial set of pains (and very few gains)
Slow, repetitive process
Can’t see product names
Can’t reorder products
No feedback when sent to print
Same complete process for every ticket (no batching)
As we moved forwards we looked to migitate and remove as many of these as possible.
Screenshots of what had been the current process
To gain a wider view of the problem I ran a kick-off session with my entire team, taking them through the work so far and brainstorming any more insights and ideas.
The team is fairly vocal so new ideas and suggestions were never in short supply.
Team feedback grouped by theme
PART OF A WIDER PROCESS
PART OF A WIDER PROCESS
The Ticketing app itself (and the HHT gun before it) use John Lewis' ticketing API to retrieve product information and to retrieve tickets. I had to keep this in mind at all times:
The ticketing API had a limited set of functions to work with e.g. no ticket previews
Partners accross the country were used to the 'HHT way' of doing things so any new approach could not be wildly different as organising training was difficult
TEST CARDS, PROTOTYPES & TESTING
TEST CARDS, PROTOTYPES & TESTING
We formulated a series of assumptions and hypotheses around menu tickets which we then used to develop interactive prototypes. The basic idea revolved around adding products to a list - like a shopping cart - re-ordering them if necessary, and sending a print request.
We tested the prototypes with In-Store Partners which helped us to refine the approach. In general it was very well received - creating menu tickets with the old HHT gun was slow and laborious, so a change like this was very welcome.
Some early sketches of the feature's main journey
Suggested testing route with screens and hypotheses
Suggested testing route with screens and hypotheses
FINAL APPROACH & RAPID DEV
FINAL APPROACH & RAPID DEV
The results of Discovery, brainstorming and testing were brought together in a final specification document. Internal schedules meant the project was delayed by a few months but when it was started up again the robust documentation allowed it to pick up speed quickly.
As an added bonus, I worked closely with the UI Designer and Devs on a daily basis to tease out any snags and limitations with the technical implementation, which meant we were able to deliver the finished product quicker than expected.
We incorporated analytics into the feature to help us track a number of key metrics:
number of different Partners using the feature
regularity of use
error messages e.g. unknown product
most commonly used ticket types
The final Menu Ticketing feature went live to acclaim and thanks from Partners!
SO how did design thinking help?
SO how did design thinking help?
The discovery process revealed current processes and tools, and the problems (and opportunities) they presented
Brainstorming with the team, which included BAs and Devs, gave us a wider range of perspectives on what was possible
Quick-fire drawn prototype screens helped us iterate designs and ideas quickly
Tools like Test Cards helped us to formalise our assumptions and gave us more to test against (and measure)
In-store qualitative testing meant test subjects were able to spend time using the prototypes in a realistic and familiar environment, giving the results more credibility
A close working relationship between Design and Dev meant the build process was an iterative series of optimisations and improvements
Page updated
Google Sites
Report abuse