kelisto.es

Overview

skills I grew in this project

I worked full time as product designer for kelisto.es. kelisto is a price comparators for insurances, energy, finance and communication. Each of these area was a specific product including its own vertical subproducts. Alongside the comparators was a solid news platforms, a community of users designed for traffic generation and a customer account. I joined the project in the very early design phases. I accepted the challenge of designing multiple and various products in a short spare of time and setting up a process for design involving both business and development.

List of the products designed for kelisto :

• 8 responsive price comparision products + own products vertical subproducts
• Responsive Customer Account Dashboard (CAM)
• Responsive Community product
• Responsive News Content Management

Strategy for multiple product launch

It is always difficult for me to answer when I am asked to describe my design process because it depends on the actual company setup I am working with. The overall phases I follow are the same in most projects but evil is in the detail. In Kelisto I have been the only designer within multiple business and dev team members for more than one year during the most critical moment : official launch. I have learnt to adapt my process to this very specific context and diverse teams involved. I knew it was not going to be easy so I did my best to deliver well designed and conversion-optimized products. Alongside I was working on setting up a lean design process with the company.

car insurance product

Design Process

This is the process I am following in most of my projects. I like to get to code early as it facilitates prototyping and hand-off to developers.

1/ Research and KPI's

Just before landing in the price comparator business, I finalized a conversion-increase project for a retail ecommerce website in London. Price comparision was way more complex but I somehow felt challenged by the huge scope of this project. For every product I designed in kelisto, the very first step was to sit with the product manager in order to understand the purpose of the product and how success will be measured. I basically learnt to ask the correct questions :

• What’s the story of how this product got to this point?
• What are upcoming goals and risks for this product?
• What information or element will be the top priority in your product?
• Who are your target users? Why?
• List the products/process inspiration
• How will we measure performance and success of this product? What are the kpi's of this product?
• What are the closest competitors to Kelisto? What would be your strategy ?

Deliverables / Methods

2/ Information Architecture

During this phase I explored and assess multiple solutions. Alongside with the product manager we decided on new design directions and opportunities. Most of the time our goal was to offer our users a process similar to most of the competitor and try to identify one killer feature to prioritize. After a couple of session working on wireframes I eventually started to code early a potential prototype. I liked to start coding as soon as possible because it is way easier to make decision with a product in context and I would also save time in development (I was also in charge of implementing the solution). One of my priority was to get the copy as soon as possible, it is not as easy as it seems. Working on a prototype will make this first priority.

Once we agreed on the beta version with business stakeholders, we started to prioritize and plan features development with the engineers (yes, dev stories). The prototype allowed us to discuss technical feasibility, performance issues, which third party frameworks to use, what types of animations were possible... At this point, we usually iterate again including technical contraints in our plans and adjusting the prototype.

I validated flowcharts with business and started mocking-up products on this basis.

Wireframes

Deliverables / Inputs

tools

3/ Visual Design

Final design ready to be uploaded and shared in Invision for feedback! Once validated I quickly move to HTML/CSS/JS protoyping

Having the features priorized and planned gave me the opportunity to spend more time working on the prototype. Prototyping present your work in a more dynamic and iterative way. Once I finalized a realistic version of the prototype I liked to run some usability testing with friends, colleagues or directly running guerrilla testing. At this time more iteration are required with business stakeholders and engineers but we were getting closer to what the final product would be. In this phase I usually worked thinking in what will come next : development and the hand-off of the prototype to the dev team. I therefore tried to be as specific as possible with the design requirement so the development hand-off would be smooth and straightforward.

Designing for data-heavy products

The products I designed for Insurances, Energy or Communications involved a lot of information to be displayed to the users. To do so I had to consider and implement basic design principles for every single page :

• Visual Hierarchy, repetition and pattern breaking
• Data-visualisation
• Responsive-ness
• Hick’s law
• Getstalt principles
• Affordance
• IxD
• Copy

Forms and tables design

Most of the products I designed were made of a form and a result table. As the amount of data to be entered by the user was huge I have focused in implementing forms best practices (keeping them as short and logical as possible, grouping fields, using a single column layout and inline validation, displaying clear call to action, providing visible and clear error messages...) so the user could provide the required information without leaving the process.

Forms and tables

Most of the products I designed were made of a form and a result table. As the amount of data to be entered by the user was huge I have focused in implementing forms best practices (keeping them as short and logical as possible, grouping fields, using a single column layout and inline validation, displaying clear call to action, providing visible and clear error messages...) so the user could provide the required information without leaving the process..

energy product form

Tables were designed to provide price comparison results. All the entry process was meaningless without the ability to visualize the results that fits their needs. These tables had to convert and be responsive. When designing the tables, I paid attention to various factors that made easy to use (density display, quick views, basic filtering...) so we could make sure user would find enough information to make a decision.

Deliverables / Methods

4/ Development

Getting to work. I always liked to work closely with engineers. They have blunt statements about the product. Their inputs are always valuable and we can directly explore design possibilities.

Breaking the classic design waterfall process

I did my best to integrate design in agile methodology by getting to code as early as possible. Static designs waterfall makes less and less sense in this multi-devices age. I still use static Sketch design to solve specific problems but I definitely like to code as soon as possible. Once the final prototype was tested and approved I started to implement it with a back end developer. In the case of having a back-end developer working on both front and back development I provided as much information as possible with regards to design specs. At this point, iteration was still necessary for small details. I learnt to share design feedback early and often with engineers and stakeholders. I also allocated some time to do front-end work as well in order to make sure the product was fully responsive, fast, accessible and compatible with all the browsers.

Facilitating design hand-off to devs

As our products launches was constantly growing, I considered how we could potentialy help engineers with design tasks and save time when shippping product to production. We needed to think about enabling engineers to continue scaling the design on their own. I started to design a styleguide that would become later a design system. I also tried to document as much as possible the rationalization of design decisions or data inputs. We tend to forget the steps we followed when designing and monitoring various products - documentation is key, kids !.see the styleguide

styleguide - first step toward a design system

Deliverables / Methods

5/ Testing & Iteration

Front-end testing for compatibility was the last step of the development phase. Once the product passed all our tests in the testing environment we shipped it to production. It was just the beggining of a new phase : the post go-live iteration. At this point we run more guerilla testing, getting feedback from everyone : customer support, content team, sales, users...

I then priorized changes or features that popped-up during the development phase or the testing. Monitoring conversions with product manager allowed us to list some improvements to be implemented (visual design, bugs, new features...). The list was prioritized by putting the easy tasks that result in quick wins at the top.

Guerilla testing / Field Studies

In order to gain insight on existing product about to be redesigned or brand new products, I run a couple of interviews and testing sessions with final users. I basically asked each participant to complete a series of tasks while verbalizing their thoughts. I observed, took notes, then produced a consolidated document to be reviewed with the product managers. My goal was to validate some of the pain points I observed from testing the product myself.

Increasing conversion

Once the products were launched a new iteration phases started in order to make sure the conversion was optimal. To do so we validated assumptions by setting up a/b testing. Each product or sub-product launch was combined with a specific landing page optimized for SEO and conversion. We monitored closely the landing page conversion and prepared a couple of a/b tests.

Helping users to make a decision

Insurance or Communication buying decisions are consided as pondered decisions. Users usually need the right amount of information in order to make a decision. When working on results pages for these products, I made research on how we could help ease the mental processing and help user make decisions. This research process involved both psychologic tendencies and design research. When designing solution that could potentially increase sells, I took into consideration the following points:

Customization leads to better conversion. User need to get the offer that suits their needs. This as also an impact on the number of choices displayed = less is more conversion.

Real time support and humanization lead to better conversion

Social Proof definitely leads to better conversion

Authority through expert advices and high-quality content leads to better conversion

Completion status leads to better conversion

Round pricing for complex products (e.g : health insurance) leads to better conversion

Scarcity has to be used with caution but it also leads to better conversion

Selling ux enhancement to stakeholders

Unfortunately I quickly realized that it was hard to sell UX improvement in an already busy features list to be developped. How to deal with UX design as polish on a finished product?

It makes integrating UX design into the lean/agile process very difficult, but it's a pretty common situation most designers have to face. How to deal with it ? Communication and metrics.

Communicating conceptual ideas, detailed designs, and design rationale both verbally and visually to exec team helped demystifying design process. To do so, I created a lab in order to sell ideas, always focusing on the value these new features would bring.

when selling ux improvements to product stakeholders communication is key. to do so I created a dedicated page for improvements always focusing on the rationalization and the value these new features would bring.

structure was the same for every single improvement : as-is; to-be and improvement rationalization

it is sometimes easier for stakeholders to take decision in context. I sometimes prepared interactive images mixing current page and prototype. before (as-is) / after (to-be : prototype)

Following-up and iterate the design solutions you offer will also create trust with stackholders, showing that you also aim to generate more revenue, not just paint a shinny product. In this particular situation, being a UX designer with code skills made the process not easier but faster. The very first step of dealing with business stakeholders is to bring the data. Not only conversion but also converting UX to tangible metrics as much as I could.see the idea lab

Deliverables / Methods

this project also included Customer Account Management design

Where did this process fail?

The scope of the project was so huge and despite the fact that an additional UX designer joined the team at some point I realized I was facing an bigger and common issue : the organization was not design inclusive. We had to fight (a lot) for small improvements and get the organization understand that don't only care for how product look. We launched so many products in a short period of time that our engineers were sometimes left alone with the design. The styleguide needed to be turned into a design system which required much of a time I did not have. There were little room left for iteration (optimizing current products and fixing design mistakes I made). Design was somehow lost between business and back-end teams. If I were to start all over again (and I happily would!) I would make sure we take time to setup a consistent data-driven design system and process from the very beggining. I learnt that before setting up a design system it was important to grow a design culture within the organization first.

skills I grew in this project