HSBC's core brand values gave guiding direction to the creative process.
As one of four in the design team, our process was extremely collaborative from concept through to crafted pixels. Each feature within the app began with a kick-off meeting with business and tech. This set the scene and defined the problem we needed to solve, covering business & customer requirements, user research data, and any technical constraints.
Having true collaboration with everyone at the table from the outset helped us quickly identify and solve problems. We were able to move forward and create a better outputs for both the business and our customers.
Sketching sessions with the cross-functional team generated solutions for the problem previously defined. These ideation sessions were a great way to produce as many ideas as possible.
Workshops would be based on personas, scenarios or tasks/goals depending on what we were trying to achieve. The format of the workshop would also be led by the intended result. For example; for blue sky sessions we found individual time-boxed quick fire sketching which then got swapped with a neighbour to build upon worked really well. But when it came to solving a particular issue or identifying new opportunities we got more results having people working in groups where ideas could be bounced around.
A huge positive from this collaborative approach meant that ideas were not owned and therefore people were less precious about the ideas being taken forward or binned.
After each workshop the design team would collate the ideas. If necessary these ideas would be supported/ fleshed out with extra sketches or notes to fill in gaps. Then they would be critically reviewed and checked against requirements to see if they would help solve the problem. A quick pros and cons list would be created for each idea to facilitate further discussions.
We would then regroup and review the ideas as a wider team. It was here that ideas would be ranked based on the business and customer value, which would determine which solution or solutions would be taken forward.
Depending on the complexity of the concept, we would then mock-up the solution in whichever format best communicated the idea. This could be in the form of simple storyboards, sketches, screens, low fidelity prototypes...anything which would help us to identify edge cases and verify ideas.
Once the feature had been mocked-up the project team would regroup. Outcomes from this collaboration would be to; determine the value of the feature to business (how many sprints worth of effort would be required), and to define both the MVP and Post MVP solution. It was important define this here so that we could future-proof the design in a way that meant the next iterations would be less impactful on build times.
To validate the solution against customers needs we would create prototypes to test. It was during this time that we would be simultaneously contributing to, and refining our UI pattern and symbol library. The knock on effect of this was that as our component library grew, our ability to mock-up high fidelity screens and prototypes got quicker and quicker.
With less effort required to put prototypes together, we were able to rapidly explore and test more options, gaining more insights and getting to the best solution faster.
Designs were first guerrilla tested internally, to catch any obvious holes or issues. Features would then go through formal user testing sessions. For security reasons, these were facilitated through an external testing agency. However, we provided documentation about the feature, defined participant criteria and created testing scripts and objectives along with the prototypes.
Depending on the feedback, the feature would be refined/updated and prepared for build, iterated on and put back in the loop for another round of testing or dumped.
Once a feature was ready to be built it would be given to a scrum team. Having buy-in from the tech leads early on in the concept and refinement stage really helped here.
A designer was embedded into each scrum team, and was responsible for the final output. Our role was to support the team during sprint and provide any clarification when needed.
We would join daily stand-ups, and were on hand to work alongside the developers, actively reviewing flows / functionality / interactions and animations to ensure pixel perfect quality before the ticket was done.
To aid this process we created a UI checklist for dev so that they could do a pre-review themselves before a design review. Essentially this sped up both the review and sign-off process for everyone involved.
Once the feature was released into the app its success would be monitored through MI learnings, app store reviews, direct feedback from call centre staff and social media groups. This feedback was regularly collated and reviewed by a cross-functional team and stakeholders, where we would assess and make action plans to iterate on and improve upon our solutions.
With the building blocks of the design language from the core HSBC brand, we took a step back and started to identify the current issues with the UI and define possible routes the visual style could evolve into.
Not having a component library or design system in place meant that mocking up features was not a quick task. Designers were having to worry about making decisions on paddings and font sizes rather than focusing on the feature experience. With four designers working on different features we had been creating slightly different layouts and interactions to answer similar problems. This not only wasted designers time, but had a knock on effect to the development teams.
We created and tested a bolder messaging pattern based on Apple UI, which gave focus to screens. Re-using a known and expected pattern instantly created consistency and a feeling of trustworthiness to the UI. This pattern also helped with our issue that customers were scanning headlines rather than reading feature descriptions.
Our initial design process was about quantity not quality. We wanted to get as many different styles out on the table as quickly as possible for discussion with stakeholders and HSBC's brand guardians. Collectively we then chose three routes to refine, mock-up and test.
Emojis were freely and widely used by our millennial demographic, and were a quick way to bring colour and life and a personality to the UI. A big bonus with using emojis was that their meanings are already widely understood, and in terms of effort they were free & easy to implement in code.
With previous testing showing that the majority of customers weren't reading feature descriptions, illustrations were a way to quickly transfer the necessary message or concept. While illustration was not widely used by HSBC in digital, they had an already established illustration library within their design system.
HSBC is a predominantly photographic brand, and so they had a huge library and budget for photography. While photography definitely brought more colour and life to the UI, it was less helpful in areas where we needed to get across a concept or theme which was less tangible.
The testing results clearly favoured route two; a simple clean UI supported with illustrations.
In a nutshell, the use of emoji’s came across as unauthentic and 'a bit too much' to be used by a bank. While photography was seen as a nice touch in some areas, many found it didn't reflect them or their style personally, and tended to put them off.
Refinement on the illustration route was agreed as:
Before hiring an illustrator, the design team had a workshop with HSBC marketing and brand guardians. Here we discussed why the current HSBC style (featured below -left) wasn't working for Connected Money, and together established a theme and the direction of visual style of illustration we wanted to achieve.
The concept behind the illustration direction was built upon HSBC's brand message 'Together we thrive'. Using this theme as a starting point, we created a suite of illustrations that always portray two characters: HSBC and the customer.
In every scene, the HSBC character is assisting the customer as they are using each feature of the app. The main concept of the features are shown through oversized ordinary objects. The magnified proportion highlights the functionality of the feature at first glance, while capturing the emotional response of the miniature characters.
The thing with a very simple, stripped back UI, is that every pixel really counts. Alignment, spacing, typography all need to be pixel perfect to achieve this. To make sure this happened we invested a lot of time in creating a component library and design system.
Creating an in-depth design system and component library enabled us to rapidly prototype concepts and iterate designs.
Time invested in this process ensured that:
Even though the implementation of the design system was a big win in terms of the speed in which we could mock up and test features, we missed a trick in how it was created...we didn't included development in the process.
Unwittingly we had created a component library in which components were defined by Sketch capabilities rather than how they could be built. This lead to frustrations on both sides, especially when getting pushback on solutions which the design team thought were effortless (as in our heads it was already a component) but to the dev team it was a new and chunky piece of work.
To resolve this tension we worked with development leads to create a 'toolkit' which defined components based on how they could be built. While this solution definitely helped, it was a bandaid that created it's own issues. The main problem being that design was now working from one library and dev the other...this meant duplication of work for the design team having to update and maintain two documents.