Whilst still in the role of Lead UI Developer at Ridgeway, I lead the wireframing process and front-end build of the new twinings.co.uk ecommerce site. Since launch the Twinings site has won multiple awards including Kentico's Site of the Year.
The Twinings team bought a great deal of insight and knowledge to the project with market research and personas already in hand. This, combined with a tight budget and deadline, lead to a stripped-down discovery phase which primarily consisted of information architecture generation, low fidelity wireframes, and high fidelity responsive wireframes.
Earl Grey is black tea?
The research that Twinings had provided showed that people didn't share a common mental model of tea categorisation with "the greys" being a particularly sticky point. People didn't think of Earl Grey as a black tea despite this being how Twinings categorised it. As we delved deeper in to the classification of teas, it became apparent that there were many different ways that users categorised tea. Supporting multiple journeys to the products would be incredibly important given Twinings' diverse range and relatively large catalogue of around 600 products.
To resolve this issue we needed to look at the problem at both the IA and UI level. A card sorting exercise with clients and users alike helped us to come up with a sensible categorisation structure.
The UI required a deeper level of scrutiny with a number of approaches explored through low fidelity sketching. Eventually, we decided on a "category index" page which would sit as a conduit for users in to the lower level category pages which provided product listings. The category index would support multiple journeys of tea discovery, allowing users direct access to products listed by product type, region, flavour, or any other product attribute that Twinings deemed fit.
Unfortunately, the administrative burden of product categorisation has meant that some of this work hasn't made the light of day. However, the time spent detailing the IA has shown its value with very few post-launch tweaks.
Twinings' brand is built not only on its heritage but also on the stories they can tell around why tea is so special. To this end, there was a requirement for engaging and visually exciting pages of content that would facilitate storytelling.
Taking inspiration from some of the longform content that was growing in popularity at the time, I came up with the idea of building a system of flexibly designed components that would allow Twinings to build these story-like pages in a way that wouldn't look repetitive but was still simple for administrators to use.
I called these pages "brand pages" and came up with 10 components (with additional configuration options) that allowed Twinings to execute on ambitious representations of content within a CMS environment.
I concluded the information architecture generation and low fidelity wireframing by conducting an in-person walk-through with the client, talking through the decision making process at each stage and taking on board valuable feedback from the Twinings team. Largely, the client was happy so we were able to move on and incorporate the feedback in to the high fidelity wireframes.
I used Jekyll and Bootstrap to build the wireframes out quickly. Because some approaches took longer to visualise in code, I often used detailed sketches and sandboxed prototypes to get a feel for different routes before incorporating them in to the wireframes. I found using web technologies to be the most effective way of communicating how the website would feel when built; although it takes slightly longer the on-going benefits to the project far outweight the time increase. The Twinings team found them very easy to understand — they still referenced them even after the project had finished — and it helped to bring closer alignment to the development team.
This was a pioneering project for a pattern-led FE build process at Ridgeway: every component of the site was built as a standalone piece of functionality in a custom-built pattern library. This approach allowed for for greater efficiency in the build process with less time spent resolving FE/BE conflicts and toe-stepping. I also believe it lead to a greater quality of both BE and FE code as each discipline was able to focus on exactly what they needed to do produce the highest quality solution before bringing the two together. Close teamwork before each task started was the key to the success of this approach.