The Punch Buying Club is a thriving B2B online ordering platform taking over £250 million per year. Over the period 2012/13 we watched our mobile traffic increase dramatically to the store. Predominantly from the then new iPad but also from its multi-sized Android cousins.
|My roles & responsibilities:||Product Management, User Experience, UI Design|
|Techniques I used:||Heuristic Evaluation, Stakeholder Interviews, User Interviews, Task Modelling, Sketching, Prototyping (HTML,CSS,jQuery), Responsive Design, Style Guides|
|Tools I used:||Pen & Paper, MacBook Pro, Balsamiq, Adobe Photoshop, Panic Coda, CodeKit|
Our existing fixed-width website was showing its age. In order to give our customers a better experience across a quickly fragmenting device landscape we agreed to design and develop a responsive site as this would allow us to utilise one codebase to cover all screen resolutions and emerging platforms, rather than putting all of our development resources and budget into multiple app platforms for example.
Research & understanding the problem:
From a cost and business perspective we would be looking to replace like-for-like functionality, however this did give us opportunity to refine the customer journey where our analytics had been suggesting points of friction and under optimised opportunities.
To make the design challenge more interesting, every customer could potentially have a different price list and product set with different delivery windows and product availability. All of which had to be easily understood by an audience not always used to digital devices and shopping online.
To better understand the problem I used a selection of standard techniques including stakeholder interviews and user interviews, to understand unmet needs and more about the context in which our product was being used, Hotjar journey recording to see current issues first-hand and comparative analysis was used to see how many of the same problems had been tackled elsewhere. Later, task modelling was used to define and refine our journey through the store, until we where comfortable with our hypothesis for the design work.
Design and prototypes:
Design moved between rough pencil sketching and lightweight task flow creation, to more fully formed Balsamiqs and polished HTML mockups through iteration. Defining key modules, such as the basket, product listing and site navigation to understand how they would respond at different break points within the overall design.
Once these HTML prototypes had been produced we had a great opportunity to get the designs in front of our audience to validate and refine our thinking and get final sign-off from the business.
The production of the site would be handled offsite via our partner developers. Much discussion had been had with regard to how the new designs could work and how performance could be improved (e.g. for mobile networks). A plan had been created to move away from the existing .Net webforms to a modern MVC architecture separating concerns. After much discussion and taking our specific needs into account, Angular.js would be used for the front end - the base functionality wasn’t changing and the complex overall business logic would remain. A set of Balsamiqs (pictured above) would show end-to-end journeys, and how the different modules would be surfaced at different viewport sizes. This would enable the developers to understand how they needed to translate the existing code.
I produced the key modules in HTML/CSS/JS to show how each would function on its own at different sizes. Adding these modules to the grid would create prototypes of key pages and show pixel perfect final designs. The talented front-end team could use these HTML modules with the Balsamiq wireframes I produced to easily create any of the pages within the site.
However as with every project, we've found that simply throwing documents and design over the fence isn't always the best idea. In order to make the project successful I always make myself available via Skype for morning stand-ups and general questions or discussions at other times.
Occasionally, where a piece of functionality had multiple states and dependant logic I would supply more technical process flow documents in order that the developers could write for different edge cases.
The site is currently in development and is expected to go live in the second half of 2015