We produced a handful of design concepts in Sketch, with a range of design with clear status bar, obvious fill box etc. In general, we tried to simplify the experience by grouping similar workflows together and keep a focus state on each step.
Unfortunately, at first glance, the stakeholder had concerns with the level of change introduced by the redesigns. The customer support team, who provide training to our customers, were made redundant and were no longer able to provide support to customers with these changes.
However, as we needed to align the design with the MyRefintiiv design system and work in different backend systems, changes were inevitable.
Emphasising with the stakeholder’s worries, we proposed the best way to validate these ideas and discover unforeseeable usability issues was to evaluate the designs with customers.
Although the lead product owner was supportive of this idea, his past experience in user testing was that they were slow and expensive and he was therefore concerned about the development timeline and budget.
I found a solution utilising our resources wisely. Knowing that our customer support teams were close to the customers, we quickly drafted an evaluation plan and asked them to help in recruitment. They managed to produce a list of consented customers in a few days! We then arranged the customer evaluation sessions via Calendly. I also invited a fellow independent designer to be the facilitator of the sessions to avoid any bias.
Meanwhile, Paul and I put together two interactive prototypes in Invision. The first prototype introduced the fewest changes whilst still conformed with the design system. The second combined a number of hypothesis’ on improving ease of use. The reason why we did it this way was to validate if customers also had the similar "no change" mindset as our stakeholders and to see "Is it that bad if we don't make any changes?". We did not want to change for the sake as a "design best practice", but for the customers' pain points.
I planned the research guide and coordinated the design evaluation sessions in one week. Two pilot tests were conducted with the customer support team to spot any issues in the prototypes and scripts.
The evaluation goals were to understand where the customers expected to find the feature (navigation) and how might customers interact with a complex form intuitively (interaction and language).
A wide range of different customers took part in the design evaluations, from new users to experts, American to Indian, from medium size companies to large corporates. Despite being a diverse group, their opinions were unanimous.
You see the now and was. And the difference is 1. It's better than the first one. Because you have fewer number. It's better than the 5 columns.
Our customers found it easier to interact with the new concepts because they were able to intuitively use the new workflows and search feature without explanation. Some of our longstanding customers also appreciated that we were able to present the same level of detail provided by legacy system, but in a cleaner and easier to use way.
These evaluation sessions helped us and the business to understand customers’ usage of MyRefinitiv in their everyday work.
We documented our research in the research platform Auerlius. It followed us to generate key insights and share them with the wider design team.
We learnt even there were more columns, they were essential to compare to previous declaration because customers required business justification for any changes. Therefore, instead of changing number of columns, we renamed the columns as customers suggested and made it easy to understand what customers' next step were.
We designed thoroughly in the entire workflow. To facilitate the declaration process, we also redesigned policies pages and grouped relevant terms and conditions, documents and procedures in a logical way.
We gathered key insights and presented them along with our design recommendations to our stakeholders. With the help of customers’ voices, the stakeholder became confident in our design and deemed them not as disruptive as she first thought.
To balance out technological effort and increase in business value, we constantly collaborated with architects, frontend developers, backend developers and Salesforce developers to plan a smooth rollout with the least development time and budget. After many discussions and iterations, we reached a consensus to deliver a MVP solution, followed by staged future enhancements. This feature was successfully built. There are about 2000 active users now.
The legacy site was designed for customers who have a deep understanding of financial terminology and required customers to work in a very specific workflow. It had a steep learning curve that needed to be tackled.
The dedicated customer support professionals that were assigned to each customer to train and support them were no longer available. Therefore the user interface needed to be intuitive for customers to self-serve.
Call to actions, instructions and legal disclaimers were disorderly presented in different parts of page. The content needed to be reorganised meaningfully.
We had limited time and budget to build extra functionality onto an existing data table. We therefore needed to compromise on ease of use vs development effort.
Stakeholders expected few changes in design and development as they wanted to avoid retraining customers and changing existing processes.
A great understanding of customers’ holistic workflow helped us to design a seamless experience for them. Sometimes customers voiced pain-points (unrelated to the UI) in their journeys which we did not think of.
Customers in the financial sector are used to working with a large amount of data that’s presented in a tight space. They value information more than white space.
“Customers might think / feel…” The best way to validate this assumption is to ask customers directly and invite stakeholders to listen to the conversation.
A table might look simple, but a generic table that works across the whole organisation is complicated. Work closely with developers to understand their challenges.
The design needs to be easy to interact with and communicate clear feedback of the interaction between users’ actions and system state, such as loading and failure.