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 simple 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.
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.
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.
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.
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.
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.