Holt Lloyd are a global leader in the manufacture of car care products. Their brands are recognisable to the automotive markets all around the world.
The existing website was over 10 years old and had all the hallmarks of a 1990's website including bad animations, sound effects on buttons and a static layout designed for the desktop.
With a new marketing team in place I worked with them to revive their website as a place for expert knowledge and advice that would compliment their product catalogue. The new site was also an opportunity to tell the story of their heritage dating back to 1919, and in contrast show how products are developed in their labs in the modern day and the people behind the science.
The project involved several UX workshops exploring the business requirements and the user goals (based on very specific personas). The goals were then prioritised and translated into wireframes and interaction designs fulfilling the business objectives and delighting the site visitors. A new website. A renewed level of expertise. A new way to learn about the past, present and future.
As a side note, Holt Lloyd do not sell their products directly to the public. In order to increase sales of their products I did suggest linking product pages directly to supplier ecommerce pages. For example if Halfords sold a product, we could be clever with location based services in the browser and on mobile devices and when a visitor to that page looked at the product, we could link them directly to the online sales page at their local Holfords store. It would be an opportunity to work with suppliers to create dedicated branded Holt Lloyd product pages within partner and retail sites.
This would create a seamless experience for the customer journey, from discovery through to purchase and it would also benefit the business with increased revenue.
It meant a lot of time and investment in reaching out to suppliers and so, unfortunately only ever remained as an idea within the wireframes.Visit holtsauto.com >>
Several high level problems were identified.
The site required a full content inventory so updated assets could be created. There needed to be an easy way to keep the content fresh in the future. The site also needs a brand new responsive layout.
The website contained outdated Flash technology and legacy code, which couldn't be viewed on some mobile platforms. It wasn't SEO friendly and above all, the content drained bandwidth and data plans.
Favouring special effects over legibility made the site hard to read. The colour contrast added to the distraction. Under the hood there was no consideration to engage with visitors who may come to the site with impaired vision.
After the kick off meetings had taken place, my first contact with the client team at Holt Lloyd was the assumptions workshop.
As the name suggests, the workshop is aimed at revealing everbody's assumptions so they can be tested and checked against real findings and research throughout the project.
The workshop also helps to uncover any bias in the project from within the client team and across their internal departments.
The workshop begins by allowing each stakeholders to have their say, effectively getting everything off their chest. At the core of this are the underlying business pains and problems.
The participants then step into the users shoes, empathising with the needs of the people that interact with their product or service.
I have found it to be one of the most effective ways to align the business and user goals and stop the client providing a list of technical requirements without understanding the true problems the project team need to solve.
There is quite a lot of preparation that takes place before the workshop begins to make sure that the days runs as smoothly as possible. The participants time is valuable and I want them to leave with a feeling of contribution towards to the project and confidence in the project team's credibility.
Because I have run many workshops in the past I have a rough idea of the time scales involved, and pretty much like a teacher in a classroom, I create a shedule of activites for the day, each with a specific purpose and end goal in mind.
I ask the client team to provide any analytics, KPIs, marketing material, company brochures and documentation such as vision reports and spend time analysing the information and understanding the business, the goals and their customers well before the workshop takes place.
Most of the clients I have worked with are able to provide a market segmentation document which describes their target audience in detail. The document usually contains a lot of 'marketing noise' and so I recreate the personas eliminating all the distractions. For example, rather than using a persona that says "Mary has two children, a cat and likes a cup of tea in the mornings" I am more concerned with Mary's congnative behaviour. What motivates her to interact with a service and what pains or barriers prevent her from fulfilling her tasks. What will delight her, keep her coming back for more and tell other people about the service.
My next step is to reach out to customers who match the personas. Interviews are arranged, recorded and edited. (The voxpops are presented back to the participants of the workshop so they hear real customers talk about their needs and pains).
If there is no market segmentation documentation from the client team, I will still reach out to their customers, interview them and use this as part of the workshop along with the persona profiles.
Workshops are a great way to build client relations. They are the one day when participants get to step away from their computers and express their ideas and opinions. The materials created are low-fi, usually creative materials - paper, crayons, cards and determined by the activities. Whatever it takes to facilitate the workshop and make it as easy as possible for the participants to contribute their ideas, these material are prepared well before the day of the workshop.
This is just a small touch I've added over the years. I create a very simple invite which is sent out to all participants with a 'save the date' notice. This makes the workshop feel more like an event. It includes a brief overview of the day and it removes any prior anxiety that participants may have, if they feel like they are being examined rather than being invited to contribute to the project.
I always arrive well ahead of time to set the room up and am often accompanied by members of the project team or account management who help facilitate the workshop. Whoever comes along to help, they are given a copy of the days schedule ahead of time and I brief them on the format of the day and the desired end goal so we are all in the same frame of mind before the workshop begins.
As participants enter the room the first slide on the screen asks them to fill in a survey. The arrival is a little disruptive, there's a buzz of energy in the room, participants may stop and chat with people they know. I prepare a screening survey that stops others that have settled in from becoming frustrated. The survey get everybody's brains warmed up and provides the first piece of research I can take back for analysis after the workshop.
I also leave workshop feedback forms which can be completed during the day because just as I am trying to create great work for clients, it's good to know where I can improve too.
Once the participants have settled in I begin by introducing today's session with an overview of the day's activities and rough completion times so everybody knows we have deadlines for each activity. I then set out the rules of play.
The rules of play are simple. Everybody must participate in order to get the best out of the workshop. No ideas are the wrong ideas. Everybody has a voice - listen to each other, add your comments, make constructive criticism.
Usually within the workshops there are a wide range of personalities from the shy and quite thoughtful types to those that dominate by shouting the loudest. Setting the rules puts everybody on an even plane for the remainder of the day.
The activities I plan have the following format: existing status, business goals, user research and user goals. I use a mixture of divergant and convergant activities that are scalable depending upon on the number of participants. The activities chosen depend on the desired goals and outcomes of the day.
For Holt Lloyd the workshops activities (explained in detail in the following sections) include:
As the day draws to a close. I end the wordshop by summarising the days activities. I tell the group what will happen with the work produced, that it will be used for further analysis, so that they know it wasn't an arbitary exercise and that there was real purpose to the day.
Finally I ask the participants to review the workshop and go around the table and give every single person a chance to have their final say answering three questions. What they did or didn't like about today's workshop? What they found most useful? Was there anything we haven't covered which needs further exploration?
In summary the workshops take a lot of preparation and facilitation to run smoothly. They take a lot of energy and it's quite exhasting to keep everybody's momentum going for the entire time. I plan the less demanding activities towards the end of the day so I get maximum participation out of every hour.
As demanding as the workshops are to run, they are extremely good fun and rewarding. More importantly, I end up with a wealth of material to take away for analysis which enables me to carry the project forward with the project team.
The problem statement is a way of exploring the business goals for the project. It is a divergant activity where participants work alone. The activity also has several other purposes, first it allows every participant to have a voice and literally get things off their chest. It is a warm up exercise for the brain to prepare for the more demanding activities that follow. It is a way of determining any bias in the project and to see if the participants share a common goal. It is also a way for me to find out who are the extroverts and dominant characters in the group and which participants are shy and need support or encouragement.
The statement is made up of 3 questions:
The participants are given a stack of cards and must write one answer per card. They can come up with as many answers as possible for each question.
The timer is set and rapid thought is encouraged to generate as many ideas as possible no matter how high level those ideas may be. When the timer ends each participant presents their ideas back to the group. If anybody else has the same idea we play a game of 'snap' and the same ideas are piled together.
Next we eliminate any functional requests from the true goals and problems (eg. a card that states 'we need a contact form' would be removed compared to a card that states 'increase email sign up for marketing activities'). If the group is small enough we will organise the cards in priority order. If the group is too large, the finidings are pinned up on the wall to be used as inspiration for the remainder of the workshop.
We now have a range of business goals and user problems to explore throughout the remainder of the workshop and some high level ideas on how we may measure the KPIs.
Personas and empathy models are used so that the workshop participants can really explore who we are creating digital products for by stepping into the 'users' shoes. This is a group activity because there is often more than one target audience for the product - the main target audience and secondary audiences. Splitting the workshop participants into small groups means that each group can fully explore a given persona and look at the product from their point of view.
I begin this activity by playing a video (voxpop) of any interviews I have done with customers from the target audience, this allows the workshop participants to hear first hand what problems their customers face, what barriers and frustrations they may have, their emotional response, their goals and how the product may fit into their lives.
Each group is given a persona card representative of their market segment. These have been created prior to the days workshop and are based on real research. They show a photo of the person so the group can connect with the 'character', and around them are statements which represent their cognitive attitude towards the product or explains their behaviours in order to understand what motivates them or prevents them from interacting with it.
Each group is then given an empathy model to complete for each of their personas which asks them to consider how their persona thinks, what they see, what they say, what they hear and what they feel. It also asks the group to consider any insights or opportunities.
The empathy models are presented back to the rest of the workshop so that everybody understands that there may be similar patterns and problems across the personas that may need to be solved in the project or that there are very specific niche problems to their persona that may not be high priority but shouldn't be forgotten.
This activity delves deep into the mind set of the user, it begins to eliminate any project bias so the participants really get to grips with the real needs and goals of the project. By understanding the target audience that interact with the product, we can begin to generate ideas and solving some of the problems, barriers and frustrations they may be facing.
This activity follows directly on from the person and empathy task. It is a group exercise exploring the expectations a customer has when they interact with the product, what they require in order to achieve their goals and what would be desirable to make that experience the best it can be. This activity is about idea generation.
The group remain in the mind set of their explored persona, empathetic to their needs, frustrations and coginitive behaviour. They then go on the journey of their persona from the moment they arrive at the website, exploring the decisions and interactions their persona may make in order to achieve their goals. There will be a number of goals a persona needs to complete, the primary goals (the reason the person interacts with the product in the first place) and secondary goals (such as enquiries and engagement).
The group are given a stack of cards and are asked to write one idea per card.
The first mini task within this activity is to write down all the things a user absolutely expects to be able to do when they arrive at the website as standard. This is a way of looking at the current state of the product (or at least what the current state of the product should be).
The second mini task is to write down (using a stack of card in a different colour) all the required things a user needs to do to be able to complete their goals. At this point the group may look at competitor products to see how they are solving some of these tasks and may include them as ideas. This task is used as a mini competitor audit to understand where the product should be.
The final task (again using a stack of different coloured card) is to write down all the desirable things a customer would expect to make their experience of using the product the best it can be. The teams must imagine an unlimited budget and unlimited time scale and let their imaginations run free. This final task is aimed at creating a development plan for the product and vision for the future.
The assumptions are presented back to the rest of the workshop for feedback, further ideas may be generated. Patterns may be seen across assumptions from each persona. Workshop participants may challenge whether an idea should change category and become a requirement rather than a desire, for example. The outcome can either be a straight forward presentation or a friendly debate depending on the energy and dynamics of the participants in the workshop.
A note about this workshop - as users of interactive products become more savvy their requirements become their expectations and their desires become their requirements. If this same workshop was repeated in a years time this progression would be clearly visibile if their expectations, requirements and desires were compared.
The priority matrix follows on from the assumptions workshop. This is a convergant activity. Depending on the number of participants in the workshop, I may ask everybody to prioritise the assumptions as a collective or split in to two 'super groups' that will prioritise their own set of assumption cards. Either way, the point of this activity is to uncover the main problems the project team will need to deal with when we begin to work on solutions. The activity is also a good way to create a roadmap for the project and may highlight the need for further exploration and indepth research around specific tasks and requirements.
The matrix is a simple graph (either a large format poster or drawn up on a whiteboard) made up of four quadrants; known low risks, unknown low risks, known high risks and unknown high risks. The assumption cards are then allocated to one of the quadrants organising them into priority order. The outcome is that the unknown high risks are areas that need further exploration or become high priority for the project team to look at.
As the assumptions are prioritised they are formed into agile user stories and logged in a Google document to be taken back to the project team.
As an example a known low risk may be: 'As a customer I would like to contact the company to make an enquiry,' an expected task. An example of a high unknow risk may be: 'As a customer I want to see price comparisons of products so I can get the best deal when I decide to purchase,' a desired task. This would be considered high risk because we may lose the customer to a competitor and also at this stage we don't know the technical implications of adding this functionality until it has been fully scoped.
A number of workshops took place with different departments involved, but once complete the work was taken back to the studio for analysis ready to turn into solutions for the website.
The solution for the website was that it would become a 'problem solved' site. The main call to action on the home page (and at any point in the site) was to type in a question about a product or vehicle maintenance in natural language and be taken straight to the answer
As the system learnt about the type of things visitors were asking, more of this content could be created or existing content could be improved upon to answer their questions completely.
The work began by mapping out the architecture of the website using the user stories to inform the flow and connections between the pages and content sections.
The architecture changed several times as the wireframe sketches evolved and new ideas and iterations of the work was created.
Before beginning the sketches for the wireframes the content strategy guy I work with gave me models for all the required content across the site. These models are incredibly valuable because they ensure nothing important is missing as the site is designed.
In the same way that I would work on a whiteboard (or wall), I sat with the lead designer over several days while we quickly sketched on glass tables different versions of the page designs. We had continual discussions considering how the content would be linked to create seemless journeys, the hierarchy of the content, how the user may interact with the content and separating tempate pages from unique pages.
At several points during the wireframe sketching the lead developer would also catch up with us. This is always a good chance to discuss the technicalities of an idea and get a different point of view in particular with the interaction design.
Developers are constantly looking at interactive solutions so it would be detrimental to not seek their input. Collectively with everybody being involved from the beginning it makes the solution much better. Each discipline brings a different point of view and it means when it's time for the designer or developer to take ownership of the project they know why decisions have been made and have no nasty surprises so know what work to expect in the pipeline.
Some of the table sketches were photographed and made into instant prototypes using keynotes to test and discuss the ways in which some of the interactions may work. It is really nice to do these prototypes, they're quick and easy to make, but show proof of concept much better than any explanation could ever do.
The delivery for this particular project was extremely tight and took place over the Christmas period. I had 5 days to formalise the wireframes. I had to get them into a state that was clear to the project team and would enable the lead designer to take ownership and continue into the design phase.
During other projects I have been completely dropping formalised wireframes and going straight into prototyping tools. Formalised wireframes do not show the interaction design, they also add unecessary documentation to the process.
Dropping the wireframe stage makes the process leaner. Prototyping software is very similar to design software and it is easy enough to output vectors and PDF's for the design team to work with. The dev team can also begin coding based on the prototype at the same time as the designers working on the UI.
In my current work process, the only times I draw up formalised wireframes are to explore something in more detail or because I need to document something that has the potential to be missed.
There wasn't a complete prototype for this project.
In fact, another way that I am trying to make the process lean is to avoid complete exhaustive prototypes that need a lot of work to update.
Instead I now prototype a specific journey or a focused interaction. This allows for quick iterations and early testing. When it comes to user research incomplete prototypes are not a problem because I am testing specific goals as opposed to allowing a test participant randomly explore the prototype.
The work goes through several rounds of research and feedback during the initial wireframe and prototype stages because this is the time to explore ideas quickly and iterate through solutions.
In the first instance there is project team feedback. This allows for different perspectives and input between strategy, design and development. It surfaces any questions and helps challenge assumptions, but it also helps with any solutions that may need some extra thought.
Following this, the work is shared with the studio team through peer review of each others projects. This allows for an initial outside point of view with constructive criticism from people that do not have pre existing bias towards the work.
Finally, and most importantly, the prototypes are researched with real users.
As the client is involved all the way through the project, they not only understand how the product has evolved, but also where we're heading. Involving the client throughout eliminates 'design by committee thinking.'
During projects I am often faced with little time or budget for the user testing of prototypes.
To overcome this, I sought out people from the target audience and asked them to perform specific tasks with the sketch prototypes. The people I spoke to ranged from a friends husband who was a mechanic, to another 'friend of a friend' who's hobby is to spend her weekends reparing VW Beetles!
The outcome of the research was that most users would probably ask in stores if they needed advice about a product or do a quick Google search.
This built a case for the content structure of the pages to be written and created in a way that they would surface in a Google search. They also had to be capable of standing alone as complete pages of product knowledge, advice and guidance because it was unlikely that once a user had found the information on the page they would be likely to explore the site any further.
The deepest we may get visitors into the site is through ongoing engagement. Similar products would be shown against the product they were currently looking at, so if they couldn't find what they were looking for we could at least give it another shot before they left the site.
The handover between UX and design was relatively smooth. In fact, if anything there was too much 'over documentation' of the wireframes.
Due to the Christmas period (I was about to go on leave) I probably went a little overboard because I wanted to make sure that there would be no unaswered questions, no uncertainties around why decisions had been made.
The downside of this complete handover is that I was now out of the loop as the project neared completion. In fact, when I returned to work I was scheduled on another project so couldn't check the original stories against the acceptance criteria before the go live date.
Very high level KPIs, set at the beginning of the project remained in place as the project went live.
The accounts team hadn't finalised specific targets with the client to be measured based on the suggested KPIs. As a result of this all analytics are being tracked and no specific goals or funnels are in place in Google Analytics. The approach that has been taken is 'it's better to capture everything rather than nothing'.
Whilst I agree that tracking everything is better than nothing, I still feel that some time needs to be allocated to putting proper event tracking and measurements in place. It makes it very hard to build a case for multi varient testing of pages in the future. I also feel we will be creating vanity reports rather than consultation reports with suggested ongoing improvements to the website.
A lot of collaboration took place on whiteboards and glass tables because of the tight deadlines.
Having stepped away from the project and not seeing it again until the site went live I was a little dissapointed that the final result didn't have the polish I expected to see. As the project team had neared the deadline some decisions had been made taking short cuts in template pages and diluting the user experience.
The biggest error in the project (and which is currently being corrected) was the development of the main call to action 'problem solved'. Despite all the project team meetings, the regular updates that took place and all the work leading up to the launch date, in order to meet the deadline the development team implemented a bog standard wordpress search instead of the bespoke 'problem solved' search tool.
The whole concept of the site is based around problem solving and until this is corrected the heart of the website doesn't exist. The user journey isn't as seemless as it was designed.
Over on the clients side, they underestimated being able to transfer content to the new site (which is also being corrected) in time for their strict launch date. Parts of the site still have missing sections.
Until the basic fundamental user experience is corrected I don't feel we are in a position to offer advice for multi varient testing or improvements because complete journeys are not in place.
I don't want to end this case study by sounding negative, but I do want it to be an honest and frank account. Despite the need for ongoing improvements, there were many great gains from the project.
The UX workshops that kicked off the project went a long way to building client and project team relationships and truly understanding the purpose and goals of the website so that it could be designed in a way that fulfilled the business goals and created a great user experience.
The added pressure of the Christmas period meant that the project team had to absolutely work closely together with strict updates and quick feedback sessions, all of which have improved the way we continue to work today in other projects.
The site is by no means perfect, but it has been pulled out of the 1990s. It works across different mobile platforms and is focused around content rather than superficial design.
Once the other problems have been corrected, the site will have an even better user experience. Suggestions for iteration and improvements can be proposed, KPI's measured and further user research can take place so the user is always at the centre of the sites evolution, therefore fulfilling the business requirements.