Challenges & Solutions of My Client Project

My first client project & how I tackled it’s challenges.

My first client project was with TransX Systems. They provide various self-patented technologies to help brick and mortar retailers execute merchandising strategy & in-store consumer engagement. They help provide contactless payments & frictionless shopping experiences to their retail clients. Using their technology, we were tasked to create a simplified contactless payment process for one of these 3 use case scenarios:

• Curbside Payments
• Drive-Thru’s
• In-Store Payments

We were a team of 3 UX designers tasked to complete this project in 4 weeks. We started off with the domain research and competitive analysis to understand a bit more about the market. This helped us understand the contactless payment domain and where there are gaps & opportunities in the market. We wanted to make sure that the solution we eventually come up with not only helps create a seamless shopping experience for users but also holds a unique value proposition in the market.

Having a tech background of my own, I was aware what IoT technology was but I knew I needed more in depth knowledge. As this was the technology primarily used by the client, understanding how it works was crucial for the ideation phase. As a team, we did our research on this technology until we were satisfied with the knowledge we had gained.

After completing our own research, the real challenges began from the user research phase. Below are the challenges we had and how we solved them.

Delayed Communication.

The client was under lots of pressure as all his clients were eager to have a contactless solution as soon as possible because of the current situation of Covid 19. He was constantly busy with his own meetings and therefore was not able to respond to our emails in a timely manner.

Solution:

1. We became persistent and gave the client a time frame in which we expected a reply. We would move forward with a certain query/solution on our own accord if there was no reply in that time frame. (Luckily it didn’t come to this!)

2. We asked for alternative means of contact so that it’s easier for us to reach the client in a prompt manner when required.

3. There was limited information in the documents that they had provided to us and emails were being exchanged at a very slow rate. So we held a ‘how might we’ ideation workshop with the client to better understand how they expect their technologies to solve specific problems.

Users of The Same Demographic.

The client sourced his own users for us to interview. He believed it’s necessary that the users did not have much experience with contactless payments. However, we knew we should interview people with various shopping experiences. It’s important to know what users might be frustrated with or would like improvements on with contactless payments to help us build a better solution. Most of the users were also the client’s friends or colleagues which could lead to biased opinions. They were all generation X or older (40+ yrs.) with many users not responding to our interview scheduling emails.

Solution:

1. We sourced some of our own users to interview, with different demographics. We managed to interview 14 people in total (including two subject matter experts) within one week. It was definitely a hectic week with back to back interviews!

2. We found that the data from the interviews were still skewed with similar user responses, so we decided to create a last minute survey. We sent this out on various channels and managed to receive 129 responses overnight which was a great success! This really helped us gain quantitative data from a much wider user demographic.

User Testing Without Wireframes.

Another challenging, but interesting, part of the process was carrying out the user testing for one of the two concepts I had come up with: the concept of the car registration process. Let me firstly explain this concept before moving onto the solutions we came up with.

During the ideation phase I came up with a concept which had the fastest payment process with no steps involved for the user. The users would just have to register their account online, adding their payment details and their vehicle’s registration plate number. Once their account details are saved, whenever they go to a drive-thru, they will have an automatic payment system enabled. A camera would detect their registration plate and charge the card registered to that vehicle, according to the billing amount the cashier enters into the system. The user would just receive a text message informing them of the amount that they have been charged with.

Hoping that this concept is clearer to you now, here are the solutions we came up with for the user testing:

Solution:

1. I did an obstacle course for a couple of users, which was quite fun! I printed out images of Panera Bread’s drive-thru, their menu board and a camera and I had a fake parcel of the order. I placed the images in a physical space to create a drive-thru scenario and asked the user to role play the test case scenarios. I also pretending to be the cashier and handed over the food. Unfortunately for the users, it was an empty bag with no real food!

2. As it’s the time of Covid and meeting most people in a physical space was not possible, we also had a solution for remote testing. We created a PowerPoint presentation of the same images used for the obstacle course and shared our screen over zoom conferencing. Again, we did a role play of the process by showing them one image on the screen at a time. This time, we used an image of a cashier handing over the food, making sure they also had a mask on!

Legal Restrictions.

The concept of the car registration process received the best response from the users and had a unique value proposition. However, once we presented this solution to the client, we were told they cannot legally use the registration information of users in their business.

Solution:

1. During the meeting with the client, after being informed that our solution cannot be used, we decided to discuss the process flow with them. We already had a task flow in place for the concept that was rejected. Using this, we discussed how we can incorporate another technology aspect into the same flow. We managed to come up with a solution (during the same meeting) which still had a reduced number of steps for the user and was feasible for the client.

Although, as a team, we had the above challenges, the project was overall very interesting. It helped me experience agile UX as there were constant iterations during the process. The client also had a very big project scope to start with but as designers, it was our job to scope it down to something that was feasible in the four weeks. Another interesting lesson for me was how other factors (legal restrictions in this case) can act as a road block in the design process. Therefore it is best to have regular communication with the client and developers so that feasibility can be discussed during the design phase.

(For more details on this project & the final solution, please visit my case study here: https://www.anitachauhan.net/transx)