Designing Tesco’s new grocery app.
There are a few posts floating around about Tesco’s new and more accessible grocery app. With this post I’ll reveal some of the stages we went through in order to create this product and the results we are now seeing from it.
The why.
The existing grocery app was responsible for a large proportion of the online revenue and saw continued growth. However, both iOS and Android apps were built on the Xamarin platform. This had become fragile and was no longer sustaining the requirements of our users or the needs of the business.
The plan was simple, re-platform to a fully native app, implement Tesco’s Digital Design Language (DDL) and align the app with the new brand expression.
If you are wondering what Tesco’s DDL is, it is a continually updated toolkit that designers across the business consistently use to design and build Tesco digital products.
“We want the new app to innovate grocery shopping.”
This was the ambitious ask by the leadership team. Before joining the project and the reorganisation of the business happened, the project was being lead by an external agency. The team had already spent 6 months in a discovery phase looking at innovation using a 1–2 week sprint method.
The ideas generated in the discovery phase solely focused on new features, navigational approaches and bespoke interactions that, fundamentally, steered too far away from the existing app. There was never any focus on what was performing well on the existing app and if any areas needed to be redesigned.
Visually these designs looked appealing, but in practice they weren’t suitable or accessible for Tesco’s wide range of users, and in many cases weren’t realistic. The designs also failed to implement Tesco’s Digital Design Language (DDL) and follow any native patterns. In many instances these new concepts and approaches also tested badly, e.g. in some cases users were unable to discover the location of the basket!
With no clear objectives or design principles, the discovery phase had become disjointed and had moved too far away from the existing app. Towards the end of this phase it lead to individuals working toward their own ideas, rather than an holistic approach, and began to form some tension within the team.
Another reorganisation.
With only a small amount of time on the project currently, Tesco announced it was to go ahead with another reorganisation of the business. With this decision, myself and Rob became the only surviving designers of the project, with some members moving to other teams or to another part of the business.
Justin was now heading up app design, bringing Chris along with him. We were then extremely fortunate to have Iain and Jay from The App Business (TAB) working with us to complete our small design team.
To begin with we set clear and measurable objectives.
After picking up from the discovery phase it was important for the team to now have clear and measurable objectives. We had to keep them simple and easy to follow. Together with our product managers, Megan and Matt we came up with the following:
- Re-platform to native.
- Design using native elements and components first.
- Align designs with the updated Tesco brand (DDL).
It was important for us to now establish standards, and our objectives would be the basis for us to critique our designs and our final output against.
‘Every Little Helps’.
Along with our objectives, it was also important to establish the principles for the product that we wanted to create. Rob spotted a way of linking these to Tesco’s ‘Every Little Helps’ tag line.
Every: Design inclusive products — start with best practice and common native patterns.
Little: Iterate tirelessly to communicate intent — don’t over embellish.
Helps: Solve the right problems — focus relentlessly on customer needs.
We didn’t want to repeat the difficulties of the discovery phase, and by having easy to follow objectives and design principles it gave us a solid foundation to evaluate our designs and outputs against.
Thinking of accessibility from the start.
Tesco is a service that serves millions via the app on a monthly basis, so it was key to design and build a product which was accessible and inclusive to as many people as possible.
From the beginning, we collectively agreed that we wanted to build the most accessible product possible and focus on using native elements first.
“40% of Tesco’s iOS customers use non-default font sizes on their device”
Sam Dods, TABs Lead iOS Developer.
This compelling stat further revealed the scale and importance of the accessibility opportunity that was presented to us.
Every UI element and component we designed was ‘beaten up’ using varying font sizes. By doing this it made us consider how many variations of particular elements and components we would need and where else they could be used within the app.
This approach established thoroughness, rigour and consistency in our designs and fundamentally encouraged reusing well tested UI elements and components throughout.
As well as varying text sizes we also ensured that all colours met AA standards as a minimum, however, our biggest areas of focus were Voice Over/TalkBack and Dynamic Type.
“Getting everyone’s buy-in at the start of the project on these two accessibility areas allowed the whole team to get aligned. We found that after an initial learning period, and the right cross-functional conversations, our overall speed of delivery wasn’t impacted.”
Alex Newnham, TAB’s Senior Test Engineer.
After we agreed upon these areas, it was also essential that details of Voice Over/TalkBack and Dynamic Type went into every JIRA ticket and was tested vigorously. It was our moral obligation to build a product that could be used by as many people as possible.
Working with The App Business (TAB).
Tesco appointed The App Business (TAB) as their expert mobile partner. They were originally appointed to accelerate the delivery of a brand new mobile service – Tesco Now.
After the successful delivery of Tesco Now, TAB’s developers, testers and agile delivery lead were retained to help with the creation of the new groceries app. We requested the support of two designers from TAB, with Android experience, to assist myself and Chris on the project. They gave us their best with Iain and Jay.
TAB’s developers and testers also guided our off shore development team in India. They were our gate keepers of development, ensuring that the app was built to an extremely high standard, consistent with designs, functioned as intended and was, most importantly, accessible.
Clear and open communication throughout.
Sounds simple but this can be difficult to achieve. By having an environment where everyone felt comfortable sharing ideas and communicating openly was essential for the success of this product.
To begin with, we removed all silos. There were no longer separate working areas or stand ups for design, product and development. We then injected design into the developer process. We made sure there was a design presence at every engineering stand up and any other relevant meeting. By inserting design into the developer process, this illustrated that design were ready to support at any time.
Development is design. Including design in the developer process helped ensure that our designs were realistic and feasible from the start, and in some cases developers would suggest alternative solutions to our initial ideas.
It was also essential that we worked closely with the brand and DDL team. We had to communicate changes and alterations needed for the new brand expression to work on the app.
The work we were doing would also help define the design language for future Tesco apps. It was our responsibility to adopt and expand the language for the app and ensure that our additions would scale and work in the future. It was crucial we worked closely with our brand and our DDL teams in order for this to succeed.
How was it done on the current app?
This was a common question throughout the project. We had to concede that certain aspects of the existing app were done for a reason. Certain pages and journeys performed so well that they only needed to be aligned with the new brand expression.
Aligning with parity ensured our output would be flexible enough to withstand the numerous edge-case scenarios that come with e-commerce. Parity also helped ease concerns that users wouldn’t be confused by this redesign and reduce fears within the business that metrics could be affected.
Our design system.
The biggest, and most exciting change in the project happened in September 2017 by utilising Sketches new feature, Libraries. Using the Beta, myself, Chris, Iain and Jay created a centralised design system, for both iOS and Android using Sketch libraries.
Instead of designing first and then building, we worked with our lead developers to establish all the components and features that existed within Apple and Androids native design language. We then added Tesco’s design language on top, replacing fonts, icons and colours with those of the DDL. Working this way helped us to add to our shared design language and would later help to ensure that a cell in design matched a cell in code.
As a fundamental rule, we made sure that all components and elements we created considered accessibility before they made it into the pattern library.
How did it work?
The library has Tesco’s design language and native patterns at it’s core. The system encourages the re-use of components and elements when constructing pages or products. By encouraging the re-use of these, it resulted in reduced duplication, greater design consistency and fewer designs coming back for amends and checks.
We made a conscious decision that every component and element we made had to be re-usable, fundamentally speeding up our design and delivery process. The nested symbols and overrides feature encouraged the re-use of components. This meant that we had fewer symbols that were similar and gave us more power and control over individual instances.
We built in the padding and margin, following a 4px grid, to all components and elements within the system. Doing this made the design elements stackable, creating a LEGO style structure.
We also established two important rules when designing with the library:
- No detaching symbols from the library.
- No separate symbols page in the Sketch files.
If, for any reason, a symbol needed to be detached or a separate symbol created, it highlighted that the library needed improvements, new components and elements added or that designers weren’t fully aware on how to use it.
Following these two rules ensured that our library could constantly evolve and allow us to construct a system that would be flexible enough to cover the vast number of scenarios Tesco products face.
Developing a theming architecture.
A core aim was to ensure that our design system was flexible enough to withstand the numerous edge-cases with e-commerce. More importantly, we had to make sure that the system was malleable enough to work across tablet, future and existing Tesco apps.
Working with our engineers we developed a theming architecture which allowed us to change an app’s fonts, assets, colours and other styling options. This meant we could quickly and easily rebrand and restyle an entire app by changing just one line of code.
This also enabled us to use different fonts for each theme, and even have multiple fonts in one theme if necessary, with perfectly calculated font line heights allowing for pixel perfect design.
The theming work allowed us to create the Jack’s: Shop Smart app, a trial app for stores and gave us the baseline to release the groceries app to our international markets.
Going forward, all future apps we are responsible for will be using the same design system and code base as the new grocery app. Fundamentally allowing us to spend more time focusing on problems rather than pixels.
More than just a pattern library.
Our process was more than just a pattern library and open communication. There were two other tools allowed us to work more effectively and efficiently. Miro (formerly known as Realtime Board) and Zeplin.
Using Miro, a realtime collaboration tool, we were able to compare the existing Xamarin pages and journeys with the new designs. Boards could be shared with anyone involved in the project, allowing us to collaborate with anyone on the team and get instant feedback. Together we could identify opportunities, document potential problems and provide rationale behind ideas in an instant.
Zeplin was the perfect place for us to have up-to-date designs. It acted as a single source of truth for final designs that had been through design reviews and Amigos, and allowed developers to build the app to accurate specifications. All designs had to be sectioned and tagged so it could be discoverable by the whole team. The notes tool also helped the team work closely with our off shore engineers, by communicating directly on designs.
The Amigos.
An Amigos session is a way of refining a story or examining a piece of work. It is a form of workshop where a small group collaborates together to discuss the work and identify any final changes that may be required. The benefits of these sessions are that the team can identify a set of requirements, blockers and edge-cases.
These sessions usually involve an engineer, tester and a product owner. But for the re-design of the app we introduced the 4 Amigos, which added a designer to the mix. The 4 amigos would run through the final designs to help identify any potential problems, blockers or edge-cases that hadn’t been noticed beforehand. Accessibility was always a hot topic in these sessions, with everyone questioning and pushing the designs to be as accessible as possible.
If, for any reason, there were issues with the design, the designer would generate a solution for the next Amigos session. This was done in order to keep the sessions as streamlined as possible.
The Amigos workshop was introduced by the brilliant people at The App Business and you can read more about it here.
What did Apple think?
A few of us from the team were lucky enough to meet with Mike Stern from Apple to run through the designs of the app and get some feedback.
Mike provided us with some valuable improvements and points to consider. For example, our original buttons were too big as we were following the sizes from the DDL. After raising this point to the DDL team we reduced the visual size of the button and used Apple’s minimum tap target of 44px squared.
Mike also had an interesting point around the Home page. The term “Home page” is very uninformative of what it actually means. “Browse” may be a better term, or something else. We are still working on that one.
Overall, Mike and the team at Apple were very impressed — and needless to say, excited we were re-building the app natively.
Releasing to colleagues.
At Tesco we are fortunate to have thousands of staff in store and in our head office who are always willing to test new products. With this unique resource, we released early versions of the app to our head office staff in Welwyn Garden City.
So we could release a product of the highest quality, we needed our colleagues to shop using the app and provide us with honest and constructive feedback. We used this to identify bugs, concerns with the user journey and to assess the effectiveness of the design system.
These early releases were pivotal to the success of the final product. One of the biggest pieces of feedback we received was around the number of product tiles visible on screen, which was down to the size and design of the product tile. We acknowledged this criticism and spent some time refactoring the design to ensure users could see the maximum amount of products possible.
Accessibility really does make a difference.
Seeing reviews like the ones below show how important and life changing an accessible app can be. These reviews started to pour in after we had gone 100% live across iOS and Android. It’s further cemented our belief that creating accessible and inclusive products is our moral obligation as a design and product team.
The stats.
Since releasing both the Android and iOS apps, the analytics and reviews have shown outstanding results. It is clear that the efforts put into ensuring the app works well for everybody has had a real impact. The analytics show that users are spending more, and positive app store star ratings increased by over 1,000% after the first month of release.
As compelling as the increase in reviews are, it’s the accessibility stats that are the most meaningful and intriguing. Since releasing the new app we now know that 35.74% of our iOS users are using one or more accessibility feature that we support, which we think is pretty impressive.
This statistic demonstrates just how important accessibility really is, users from all walks of life are now so reliant on using digital products to aide with their lives and shopping is no different. There are no excuses not to consider accessibility when designing products.
The overwhelming feedback we are receiving and the positive data is something we are extremely proud of. We will continue to improve and champion accessibility with this app and all of our apps going forward. A huge thank you and congratulations to everyone involved in this brilliant piece of work.
