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 :
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.
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 :
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.
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.
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 :
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.
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..
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.
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.
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.
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
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.
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.
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.
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
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.Communication
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.Bring the data
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
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.