Used Cars Sales Portal

A UX Study Case by Martino Liu 

Product Manager at iTexico

Since 2017 the new car market saw a steady decline in sales. Worried about this situation the Dalton Group started paying more attention to the used cars market to realize that new competition was thriving under their radar. The client approached us to help them understand the users and define an innovative used cars portal and implement the solution to achieve the new business goals: to double the used car sales within 18 months.

Framing the problem

New car sales are dropping and the business needed to pay careful attention to the previously unattended used-cars market. The used-cars portals were many, disperse, inconsistent and unliked, making the offer very limited to the potential customer. The client needed a well rounded, unique, efficient used car portal that could help revamped the sales for the upcoming 18 months.

Users Persona

Juan, a 30 year old professional looking for his first or second car withing budget and smart spending in mind.

Roles & Responsabilities

Product Manager in charge of the vision of the product, the product backlog and the release plan. Collaborating hand in hand with the Product Owner from the client-side and coordinating the development team hand in hand with the Project Manager. Collaborating on a daily basis with 2 full-stack developers, the UX designer, a DevOps engineer, and a QA tester. Also coordinating and participating in meetings on a daily basis with marketing, innovation, IT stakeholders, and the President of the company.

Scope & Constraints

There were no preconceptions about what to do and how to do it. All they needed was an easy to adopt mobile application since this was going to be the first official app for the SGI community in America. There were some constraints like the diversity of devices the practitioners had and the budget and time of the project. We opted to do a native Android first and then and iOS native app later for both smartphones and tablets.


Although there was not an explicit budget for user research, that was one of the first things I corrected since they wanted to jump to the whiteboard before getting a clear understanding of who they user persona was exactly.


We also needed to do some competitive analysis first to see and look at what was already out there and working for the community.

The Process





Information Architecture







User Research

The first thing I did was to do some stakeholders interviews to get to know the practice of Nichiren Buddhism, I also needed to understand what SGI is, what their practitioners do and get familiar with the practice in general. There was no specific budget for User Research but still I had to take a weekend off to do a brief field study and explore the practice by going to the local SGI center in Guadalajara (I didn’t know there was one) and meet some people, do some contextual inquiries, some interviews, and immersive observation. I even got a book, the Lotus Sutra, from a coworker that I knew was practicing Buddhism and he actually was an SGI practitioner years before so I got to get more insights face-to-face, all this help me get acquainted with the practice and help resolve the design challenge in a better fashion.

User Stories

I got a concise list of requirements from the stakeholder's interviews. The main feature was to keep track of the Daimoku, which is a unit of measurement in their chants or prayers, and to have access to a whole range of other secondary features. 

Information Architecture

After taking a look and doing some competitive analysis with other apps in the market, I came with a better understanding of how the application should be organized and what feature it should have, so I started putting together an information architecture map and discussed it with the stakeholders until we came about a final distribution of the information.


The next needed step was to start putting some wireframes together to stat visualizing how the actual screen to screen interaction was going to work. Specially to start understanding how the layout of the app was going to be on each screen size and platform.

User Flows

Pencil and paper in hand I started generating some ideas on how to better solve the problem. Soon after a few iterations on the wireframes presented in Balsamiq, we realized that the sound of the Bell was key to the design of the main feature, the Daimoku tracker. So this concept of listening to a bell while chanting was incorporated at the early stages of the sketching phase thanks to some of the answers provided during the stakeholder's interviews that were not presented as a feature in the beginning. During this phase of the design process, the stakeholders iterated in as many as 3 times a week in order to sign off all the low fidelity wireframes until the completion of all features been sketched out and wireframed.


Almost at the same time that I was presenting the wireframes, I needed to present the actual user flows for the stakeholders to understand how the users will be performing tasks within the app. In this iterations, we were defining the features while gaining a deeper understanding of the actual user flows. I created 4 prototypes, 2 for tablets versions and 2 for smartphones for each platform (iOS and Android). This helped the team and the stakeholders to come around the actual visual interface, it helped them see the actual final look and feel and we kept iterating over these prototypes to polish the design. The prototypes presented in InVision were a great tool to showcase every feature of the app, this helped us also to make better decisions by reducing the features in the app or mixing them in different ways, but we also needed to validate those decisions with users.

User Testing

Round # 1

As we were discussing the many features of the apps, I suggested the next effort to validate design decisions with user testing. We didn’t have a budget for this but we manage to get 3 internal users to go through the app and observe their behaviors, listen to their questions and thinking out loud sometimes. What we found after this internal user testing is that we needed to make the primary feature of the app, the Daimoku counter, more precise. 


The 3 users provided negative feedback regarding how confusing it was to sing or pray along the Daimoku counter. While they were singing or praying at their usual pace, they were getting a faster or slower count, therefore the friction. We had to include a setting to the counter in order to calibrate the count with the user's own speed. This helped bridge the gap between beginners and experienced practitioners and it helped get the foundation of a first-time app. 


Round # 2

We still needed to learn whether to have the counter visible all the time was, in fact, useful since all practitioners do all the time is get their eyes closed while praying. So we did another round of user testing with different people, this time the feedback on the counter was neutral, but we realized that the setting of the counter was difficult to access. 2 of the 3 users showed friction while trying to set the counter. 


This time instead of hiding the setting in the settings section, we had to come up with an idea to set up the counter directly from the counter screen, we decided to make the setting come up after tapping the counter making it also easy to decide whether to use the timer or the stopwatch mode of the counter, therefore removing that option from the settings section making it more intuitive and adding discoverability to the feature.

Final Design

After four months of design work, the app design was completed in 2 platforms; iOS and Android for both smartphone and tablet use. At the final cut, the app had 6 out of 10 original features making it easier to adopt an enabling the users to engage with it in a more focused manner, an important aspect for easier user adoption. One of the fine aspects of this final design was about the way the app was showing the successful achievement of goals within the app, they wanted fireworks. Yes, the request was very explicit and direct: “we want fireworks in the app”. I knew this was going to be a challenge since is more in the realm of game design, still I had to manage alongside one of the mobile developers to come up with a final proposal, in short, they liked it and we stick with it knowing that this, being outside of our skillset, could have been an opportunity to say no, or simply get an expert on this specific requirement and see how the stakeholders could have reacted, but pretty much we did get through.


Deliverables. A Design bundle including all original design files, notes, and digital documents. All product specifications were delivered to mobile developers using Zeplin. The prototype was delivered using the Invision app.

Outcomes & Lessons

We completed the challenge in time and in good form. It was an incredible experience to go through the whole process and give the development team a clear look into what a product design process should look like, definitely moving the team forward to become a user-centered product team.

Martino Liu - Membership Certificate.jpg
  • LinkedIn - Black Circle
  • dribbble-icon
  • Behande