Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Quick links


In my previous post ‘Stop doing upfront design, it’s a waste of time’ I mentioned I’d give a practical example using one of our existing client projects to demonstrate how we try to design as much as we can against user stories. The article I wrote gives some good reasons why designing for user stories and minimising upfront design is a far better way to go about a project that requires a multi-disciplined approach so I won’t go over this ground again and instead just try to give a sense of the how we do it as opposed to the why we do it.

A quick note: this approach requires a re-programming of the ‘standard’ model of thinking about design being done first, presented second, signed off third and then handed over to the development team and walking away. It requires you to consider design and designers as an integral part of your sprint team, collaborating with developers (frontend and backend), project and product managers and anyone else deemed necessary to complete a user story. This means design has to become part of the sprint workflow and importantly (and this is the biggest barrier to entry for some creative types to understand) subject to refactoring in subsequent sprints the same way as code is refactored.

The ability to refactor design is fundamental because it accepts that design, as with anything else involved in the delivery of a project can only accurately be done with the information we have to hand at any given time. If it’s therefore sensible to delay some development decisions and refactor code when new information comes to light (and in Agile it’s paramount to the success of a project) then it’s as acceptable to postpone some design decisions and refactor design in the same way.

Havells Sylvania website

Havells Sylvania is a multinational lighting manufacturer and whilst you may not have heard of them you probably have their products in your office/workspace. To put it into context, their main competitors are GE and Phillips. In December 2012 we released their new website that amongst many other things consisted of a rebrand.

We had 2 very high priority business goals on the agenda:

  • Improving their online image (the site re-design) – the main drivers behind this were the business owners and sales and marketing departments
  • Being able to find product information via a unique product SKU code – the main drivers behind this were their customers and their sales team who more than anything needed access to product data

I’m not going to get bogged down with how we validated the above, just to say that we did and a Minimum Viable Product with associated high level user stories and then later more detailed user stories resulted from several activities.

Some design and creative activities were performed prior to the first sprint enabling us to move firmly into design for user story mode when we hit that first sprint. It’s also worth mentioning, whilst the original website was truly awful, their offline material and actual brand is very well defined and provided a useful yardstick so we had a good starting point for the look/feel of the website: what we needed to do was take the brand guidelines and create an online brand to match their offline image.

For simplicity, I’m only going to show the desktop version of the site and how that changed through each sprint but in practice we started with mobile and worked up to desktop in a Mobile First style.

Sprint 1: homepage and content management system

We decided to tackle point 1 of the high priorities because having a first template and the start of a style guide whilst getting the nitty-gritty of the CMS up and running seemed like a sensible platform to build on and importantly it meant all resources in the sprint team would be utilised (and as I’ve mentioned, you get way better results if you work as a multi-disciplined team and not as a bunch of siloed resources). We pulled in a couple of user stories to achieve this:

As a senior manager and a member of the sales and marketing department,
I want to use our brand guidelines, imagery and brand tag line,
In order to have an immediate and positive impact on visitors to our website.

As a specifier or architect, whilst browsing the Havells Sylvannia website,
I want to see a Terms and Conditions of Sale page,
In order to understand the Havells sales policy.

On looking at the first user story it might initially appear that a developer is not required anywhere near it and that a designer should simply provide a few Photoshop files to the client at the end of the week. This is the defacto creative agency mode. But scratch beneath the surface and you’ll discover more than you bargain for. The story references ‘imagery’ and ‘tag line’ – are they content managed? If so who manages them? Where does the content come from and in what format? Are we thinking about several images on one page or one image and if several, how are these ordered and prioritised? How will we handle large images on a mobile device?

The point about the above is nothing is as simple as it looks and what might seem like a simple Photoshop > presentation > sign-off > build process is anything but. The questions above are only elicited when the right people (for instance designer, front-end developer product manager and developer) are all discussing the user story AT THE SAME TIME. If you do the design first, the designer is simply making assumptions about all the questions (and more besides) = WASTED effort.

Look down the road, not at your feet

It’s important not to treat user stories in isolation. That’s why user stories should be born from business goals where customer journeys or high level user stories (or epics or whatever else you want to call them) outline our assumptions on how, given a particular actor (user) we can affect a change in their behaviour (have an impact) to meet the business goal.

Having a better understanding of the whole before diving into the granularity of individual user stories allows us to pull appropriate user stories into a sprint even if at first they might appear insignificant. That’s how our second ‘terms of business’ user story ended up in the first sprint. Because we knew that a content management system was required, and we know that to get our JellyBean CMS up and running with it configured correctly and deployed to a live environment will take a sprint (including commissioning hosting). It also means that once it’s up and running, any further user stories related to the CMS will easily bolt on. To round it off nicely it means that our sprint team will be fully utilised and at the end of the week we can deploy a working and tested version of the site thus taking one of the risk factors out of the equation early on because we were deploying our CMS (which requires the superb Elastic Search) to a third party web server and not our own (Havells manage all their own webservers so we weren’t hosting or providing a service level agreement in this instance).

At the end of the week we deployed a working website, albeit only addressing the 2 user stories mentioned above:


Sprint 2: Search for a product by SKU code

As a member of the Havells Sylvania sales team,
I want to be able to search for a product by SKU code,
In order to access specific product information in preparation for a client meeting.

This high-level user story delivers a large amount of value because allowing users (specifiers, architects, installers and the Havells sales team) the ability to access specific product information was something they’d been crying out for; in fact it was the main reason why the project went ahead in the first place (more sales). In fact about 80% of the overall website spend is focussed on making products findable and providing accurate and useful product information to the end user.

As I’m only focussing on the homepage design and how that got refactored for each sprint I won’t go into any more detail about the other aspects of this user story but suffice to say there was a lot of complexity beyond the search panel on the homepage.

Here’s the refactored homepage for this sprint:


Sprint 3: Content and sub brand pages

This is the point where our JellyBean CMS work in sprint 1 really paid dividends because we can quickly rattle through some of the more content oriented user stories:


As a specifier, architect or designer,
I want to see how other customers are using Havells products,
In order to understand if the products are appropriate for my application.

As a specifier, architect, designer or end-user,
I want to find out about Havells history, company background and credentials,
In order to give me confidence when choosing Havells products for my application.

As a specifier, architect or designer,
I want to be able to access a glossary of technical lighting terms used on the website,
In order to be guided through some of the decisions I need to make when choosing the correct products for my application.

As a member of the press,
I want to read press releases and latest news articles,
In order to research articles I am writing about Havells Sylvania.

As an end-user,
I want to be able to be able to access information about a specific Havells Sylvania sub brand (for instance Concord),
In order to understand if the products recommended to me by my architect are appropriate for my needs.

For the final user story it’s important to understand a bit about the Havells Sylvania sub brands – Concord, Lumiance and Sylvania – which are all managed by separate brand owners who mostly act independently. It was very important for these brands to have their own space because their brand values and customers can be very different. For instance, Concord is their prestige brand born from high-end lighting for museums and this is very different from the bread and butter brand Sylvania that consists, amongst other things of a lot of bulbs. So the requirement here was to make sure each brand had it’s own space and opportunity to communicate its own values without being diluted by the other sub brands.

Also worthy of a note is that some of the users stories in this sprint justified the inclusion of a global navigation. A lot of designers would by default design global navigation up-front but with our approach we design one only when it’s required and not before.

Here’s how this sprint changed the homepage:


Sprint 4: Browse for products

Next up came the ability to allow users to browse the product range via category (e.g. ‘Interior lighting’) and sub category (e.g. ‘Downlights’), as opposed to searching directly by a unique SKU code. Prior to these stories, we ran several activities to ascertain an appropriate product categorisation. I won’t go into these activities now but suffice to say at least half our effort went into determining an appropriate categorisation and taxonomy that didn’t previously exist (data was pretty sporadic and unmanaged).

As a specifier, architect, designer or end-user,
I want to be able to browse by categories of lighting,
In order for me to find product lines within that category.

And here’s how the homepage design was affected by this story (note: this was a global navigation change so I’ve supplied a version of the homepage with the product finder navigation item expanded):


And we have minimum viable product! The site was launched at this point as MVP just before Christmas 2012 and in the New Year we moved into the ‘continuous improvement’ phase….

Sprint 5: Better communicating sub-categories

This sprint saw a fairly minor addition to the homepage design through a desire to better communicate the product sub-categories because from some of the names (eg ‘post tops’) it’s not exactly clear what they are (for anyone who’s interested, post tops are lamp posts).

As an architect, specifier, designer or end-user,
I want to see a visual of a lighting sub-category when I am browsing for products,
In order to help me select the sub-category I am looking for.

And here’s the result (again, this was a global navigation change so I’ve supplied a version of the homepage with the product finder navigation item expanded with an active sub-category):


Sprint 6: Multilingual support

We ran 2 sprints to create a multilingual feature within our JellyBean CMS and there were many user stories associated with the work. However, only 1 user story affected the homepage design and this was part of sprint 6:

As any user,
I want to be able to be able to choose my language,
In order to view the website content in a language I understand.

And here’s the homepage:


And that’s pretty much how the homepage has stayed in recent months.

I hope you’ve found this useful and are able to see how designing within user stories and sprints helps to have a positive impact and achieve better results with less waste. It’s an approach we’re forever tweaking and I’ll sign-off with the words of Natalie, our digital designer whose embraced the process with open arms (and is originally from a graphic and branding background):

Working from user stories really helps me to keep focussed on the necessary elements to fulfil user requirements. I know I’m able come back and refactor at a later stage to bring the user story in context with other design elements so it makes decisions easier and helps me to keep track of what (and who) I am designing for and what purpose I want to fulfil with my design. It’s like a building block concept, where you design particular elements, make them work for themselves but then you start building them up and refactoring to accommodate other stories until you have a whole, cohesive product.