UX/UI as a design team of one for B2B Business Travel Booking app
My Role: UX/UI Designer supporting the Product and Engineering team as they transitioned £300 million of business onto their new platform.
Click were building out features for their new platform ready to migrate their customer base. The platform used the latest tech and thinking to maximise efficiency, speed, scalability and reliability.
The Head of Product and Engineering recognised the need for design and brought me on board to improve their UI and develop their style guide, as well as help solve more gnarly UX problems as the product teams rolled out new areas of the app.
The Team
- Head of Product and Engineering
- Product Owners (5)
- Engineering Team Leads (7)
- Full stack engineers (30)
- UX/UI Designer (me)
Usability research
In my first few weeks I organised some Contextual enquiry/field research with one of Click's larger and more vocal clients. I spent the day with their staff and ran a set of moderated user testing sessions. The research exposed a number of weaknesses in the current product areas.
With all research I shared and presented and shared as widely as possible. Issues are plotted on an Impact /Frequency Matrix which prioritised issues from Low to Critical.
The user research regarding the UI as a while seemed to suggest that it didn’t create any direct usability issues, although a number of smaller but critical issues were picked up around consistency in navigating backwards and forwards in search results.
Qualitatively we were also getting feedback from customers using the new system – in the form of NPS scores. I spent some time analysing the NPS feedback and found that we were frequently getting comments using the phrase ‘clunky’. Whilst these customers were clearly dis-satisfied, there was no clear usability problem they had encountered. My hypothesis for this was that there was an Aesthetic/Usability Effect coming into play with our customers.
Understanding our customers
To understand our users a little better I organised an empathy mapping sessions with stakeholders. We identified 11 different customer profiles through these sessions (4 key customers).
I was surprised but how complex it was! Through the sessions I was able to flesh these out into user personas which we were able to use for all future product development work.
Establishing the pattern library
The engineers had created a living style guide but there were no design assets. I quickly sought to understand how to use/edit and update the html style guide and set to work recreating the components we had in a Figma pattern library.
Providing a vision for the future
So that we could get an idea of where we wanted to get to I worked with a small team of senior stakeholders and PMs to product a set of screens – which could highlight where we want to take the product in the future, both from a UX point of view and also a UI point of view. See the prototype on Loom
Evolving the pattern library
As a single designer – and without a dedicated team we weren’t going to radically overhaul the UI overnight. The engineering team were busy shipping features, and they needed my support for that too. This may not have been such a bad thing because users dislike change. Instead I planned to make small incremental improvements to the UI, improving over time. I created a Trello board with potential changes/improvements and rates each based on a combination of Impact, effort and confidence. Those with the highest score were tackled first. I invited engineers and Product Managers to feed into this list too. As the incremental improvements were made so the pattern library and Figma component library were updated an evolved.
Assisting PM's in larger areas of product development
When the product teams had more gnarly problems to solve I would be involved to help them form design solutions. An example of this was the trains search and book redesign. It was combined with the introduction of e-tickets.
Example: Trains redesign
We knew from our usability testing/customer research that our trains search results was a source of significant struggle for our users. So we set out to address some of the problems customers faced.
Problem areas
- Customers were To-ing and fro-ing in order to find out the best train options
- This was causing significant friction and we even observed customers researching the best trains using other websites to find the best train for them and booking it on Click.
Approach
Sketches
I initially make a series of sketches and share them with the CTO. The approach is to provide users with a UX they are more familiar with, whilst working within our own constraints.
Prototype
We then created a medium fidelity prototype to show how the interactions and filtering could work. The prototype was tested with customers and we make a couple of iterations.
Final designs
Through a series of Sprints we create high fidelity designs for the engineers working on the trains team to start building out the new design. The designs certainly included quite a lot of compromise. But it was more important to get something achievable and then iterate than to go for perfection.
Outcomes
For the trains redesign we were able to observe that the problems encountered with the previous design had been completely removed with the new design.
As a general rule saw through the iterative development of the design system we observed that comments around clunkiness disappeared – giving confidence that we had addressed the Aesthetic Usability effect issue we were previously seeing During the time the incremental improvements were made we saw a three fold NPS increase for platform users.
Learnings
Having a style guide codebase separate to the main codebase ensures a safe sandbox environment but causes lots of synchronisation issues. We could have save a lot of time by addressing this. Whilst we couldn’t address some of the more systemic design problems the incremental approach did provide great design value and with very little pushback or resentment from users but it would have been great to have pushed it further. Using Bootstrap really did limit us design wise – particularly the 12 column setup.
Back to case studies ⤴