I joined Aptixlab, an Australian company from the Cognixus group, as a Senior Product Designer for an upcoming product in the service providing market, named Niffty.
My main contributions to the business was to re-define the design process from scratch, resulting in a significant increase of velocity/deliverables and being in charge of adapting pre-existing app designs into responsive web.
The chat functionality (called Job Log) is one of the UX pillars set for Niffty. It serves as a hub for two key user actions in the application: communication between users and job-related updates (completed, pending payment, disputes, price changes).
To ensure that a dual-task section works intuitively and does not overwhelm the user with too many functionalities, the core experience (chat itself) must have zero friction for new users, be extremely intuitive.
It was decided to go with a very standardised and consolidated user experience for the chat part, blending functionalities based on WhatsApp and Facebook Messenger. That way, the path was clear for us to add two job-related components without compromising usability or learning curve.
Job Updates are actions that require an input from the other end. If they are not addressed in a timely manner, it might drag along the completion time and the UX gets affected by both sides (hirer and service provider). To avoid this, Job Updates shouldn’t be missed at all.
After quite a few low-fidelity attempts, the solution that worked on most scenarios was a dynamic sticky CTA bar. Placed in a chat's noble area (the bottom), it is hard to miss and yet not invasive, still leaving the chat fully functional to the user.
To reduce even more the cognitive load, universal traffic light colours were chosen for better classifying the type of alert that was being displayed. The colour logic was green for completions and agreements, yellow for data or price updates, red for cancellations or negative outcomes.
For the contact list screen, a reduced version of this component was added in a badge format, to help users quickly scan and check the nature of the alerts in the messages list, using the same colour coding described above.
We had to ensure that users could easily manage their transactions and stay informed about all financial activities and updates, without driving too attention and/or effort to this section (is not a financial app, after all).
To seamless allow users to browse into specific transaction details was the hardest mountain to climb. In the initial wire-frames, we struggled to find the best way of organising the information architecture to present itself simple and intuitive. There is a lot of data to display.
The difficulty relied on the fact that each job could have more than one transaction related to it, such as price updates and tips, which happen quite often in these applications. In wire-frames testing scenarios, this job>transactions multiplier effect made the transactions list lengthy and confusing in circumstances where the user had 2 or more jobs. Plus, by only scrolling through them it was hard to relate a price update transaction to the original price of that same job, for example.
The chosen Information Architecture arrangement was the Job > Order > Transaction(s) hierarchy. Each job has only one Order, which will have all transactions related to it, sub-categorised as price updates, tips or refunds.
Starting with the transactions list, brings a straight-forward and intuitive user experience, displaying only critical data: amount, date and type of transaction. At the transaction page , the User Interface presents itself simple and minimalistic, very familiar to a bank application.
From each and every transaction page, the user can go to the Order which that transaction came from. In cases where there are orders with multiple transactions, the user can easily differentiate them by the highlighted transaction type.
The order page was the hardest piece of the puzzle to conceptualise and design. A dedicated section which might have different categories of transactions can get messy quite easily. During the concept phase, complex orders were becoming too complex and just looking like a large list of data.
The solution was to take a modular approach to components and sort them by purpose and efficiency. From the top down, it summarises information for a quick read (Summary) and yet still gives the user freedom to knit-pick any detail for a particular transaction, at the Job Event History, a UI-blend inspired in both time-line and receipt elements.
