In Autumn, I was offered the opportunity to work on an exciting design challenge for the Brixton Customer Centre which operates under the auspices of the Lambeth Borough Council, London. As the point of contact for all borough residents, the customer centre experiences extremely high visitor volumes. This leave staff struggling to cope and vulnerable residents awaiting help.
We were asked to explore alternative solutions which would reduce the number of daily visitors to the centre, and adjust customer expectations by encouraging members of the public to self-serve. Specifically, we needed to reduce the frequency of the simpler time consuming queries so that more time is available for staff to focus on complex, sensitive cases.
Disclaimer: This was a team project, therefore, credit is also due to the classmates I worked with.
User Research
We began our design process with a thorough investigation of the design context. Passive observations were used to understand the volume of visitors and the basic council services available in the centre. We also examined the layout of the centre and the resources available which were aimed to encourage visitors to self-serve. I found observation a really useful approach because we captured very honest information, for example, whether people even approached the self-serve desks at all. We also used the observation data to shape our interviews and questionnaires.
I realised that not everyone is comfortable talking about their technology use. Observation helped us capture nuances in behaviour, and details which visitors may find hard to admit or explain.
Observation also gave us the opportunity to learn about how the council systems worked. This included the work-arounds staff employed to help visitors who didn’t have everything they need when they visit the centre.
Staff interviews were used to gain more in-depth knowledge of the services and service demand. We collected the bulk of our information about the visitor problem with this method, probably because interviews are a very flexible approach and staff offered us a lot of their time to help us. We covered a broad range of topics including those which I hadn’t initially thought would be relevant, for example, visitor attitudes about what the council should provide. It definitely highlighted to me the importance of open ended questions and to follow through on comments which spark your curiosity.
“Some of them don’t want to try it [online service], they prefer the old system and have the feeling that you have to provide the service. This is why we’re here.”
Lastly, visitor questionnaires were used to find out the services peoples were after and to build a greater understanding of user’s technology profile. It was a really quick method to help us determine the paradigm of our interactive solution and the attitudes of visitors with respect to different forms of technology. Although we used closed questions, visitors made comments on a range of topics ranging from issues with trust to accessibility to online services. This also varied depending on the council area being discussed.
Interpreting the data
We wanted to organise the data somehow to help us get a sense of service demand, and to decided where our interactive product could have the biggest impact. The results from all our data collection methods agreed that housing and parking related issues led to the highest number of visitors to the centre, We decided to focus on parking, however, because these tasks were far less delicate in nature and more appropriate for an interactive system. Specifically, the purchase and renewal of permits and the payment of parking fines.
User Journeys were really helpful because they helped provide us with a context for our design process. We draw up a user journey for every type of parking enquiry, including their possible outcomes. By understanding the ‘flow’ of various tasks that members of the public should undertake, we could start to think about the sort of taxonomy that could support those tasks.
We also drew up a number of personas which were grounded in the data we had collected from the staff interviews and visitor questionnaires. It was great to have a visual representation of who we were designing for and I often referred back to them throughout the conceptual and detailed design stages to test how convenient the design would be for them.
Finally, using a user centered design process we were able to extract functional, non-functional and data requirements straight from our user research. Although these were described in Volere format, we wrote them into the a simple requirements table for easy access. Writing the requirements also helped us identify 5 key themes which frequently arose when we analysed the staff interviews and visitor questionnaires: Immediacy, accessibility, flexibility, learnability and the promotion of trust. We used these themes and the requirements to guide our conceptual design.
Conceptual Design
After independently thinking of some designs, we used storyboards to depict our main three concepts. The storyboards were very effective in helping us to identify further real life requirements for the interactive product, and to contrast the concepts against user needs. I found it useful to have a visual depiction of user behaviour to identify general system features that would be needed.
This is an example of one of our concepts. It depicts the permit as a plastic card that can be bought in a store and registered online. As we compared our storyboard concepts against each other we began to synthesise and combine features of the designs. This eventually led to towards a more detailed design.
Throughout conceptual design we referred to our requirements closely to ensure that every design would be a feasible solution for both visitors and staff to use. As we also wanted to ensure that our final design agreed with the five themes we had identified in use research, however, we decided to compare each concept against the existing solution for parking permits to assess whether our design would be an improvement for each theme. This process also helped us decide which concepts would be the best to carry forward.
The datum (the solution compared against) was the current solution for resident on-street parking. ‘+’ (plus) meaning better than, less than, less prone to, easier than etc, relative to the datum ‘-’ (minus) meaning worse than, more expensive than, more difficult to develop, more complex than, more prone to, hard than etc., relative to the datum ‘S’ (same) meaning same as the datum
Detailed Design
We reached our detailed design through an evolutionary design process, whereby our initial designs served as a basis for iteration. In our final design, the plastic card would be purchased in store and registered on a ordinary self-check out machine in any supermarket. This was off the back of user research which suggested that visitors didn’t like to complete council tasks online, and they would feel more comfortable completing the transaction with the assistance of a human facilitator.
The wireframes depict the interface that would added into the self-serve checkouts for members of the public to purchase, renew or pay for a parking fine. They would either scan in the plastic permit which can be found in store, or scan the barcode of the parking ticket they received. We liked this idea because it is hugely flexible and it can be completed along side ordinary shopping in the same transaction.
We decided to name our product ‘1Permit’ to highlight the flexibility of our design. For example, our research had shown that users often needed to purchase multiple permits for different areas of the borough depending on where they lived and worked. We decided that our interactive solution would allow the purchase of multiple permits on one card, this would avoid users waiting for multiple items to arrive in the post and require traffic wardens to scan one item only.
‘1Permit’ can be broken into two pieces so that it is reusable and flexible. The larger of the two parts can stay permantly in the user’s card, the smaller part can be attached to a keyring so that it is easily accessible when users need the renew their permit in store.
Evaluation
After planning our evaluation closely, we decided to employ two methods of user testing. First we used direct observation of the wireframe prototype. We asked drivers to be our participants for this process as they would know what they are trying to achieve and have a baseline process to compare our product against. We also participants to complete a questionnaire after reviewing the prototype consisting of user experience questions. This was the most effective method to capture usability problems with the detailed design.
Generally our feedback was positive. The wireframe prototype demonstrated learnability and effectiveness. Issues were experienced with the efficiency of the product,however, this was with respect to labelling in the interface. In a future version we would look to fix these issues and explore whether this interface could also employed as a mobile app for more tech-savvy users.