Back end system for a B2B online service
The company has multiple client-facing teams taking care of end-users at different touchpoints and different statuses.
This required a single system to manage the customers’ needs and take care of their success.
Some of the information and functions are available on an old and complex system.
In some cases, the tasks the team members had to perform required using different tools and systems to complete.
This results in time-consuming tasks, long and cumbersome conversation with the company customers and a general frustration on the team members’ side.
The strategy was to rebuild the existing system, based on the different teams’ needs and requirements.
As a POC, we first sought out to address immediate pain points, that will prove valuable to both the teams and to the company’s customers.
ROI was front and center, since creating a brand new system is very costly from a development point of view.
This system needed to prove it’s value to the company as soon as possible.
Zeplin/avocode (Dev deliverables)
Helping the product team get to where they wanted to be, required defining and maintaining a ‘rule-of-thumb’ guidelines for our mutual project.
These guidelines were aimed to help us stay focused and aligned throughout the duration of the project.
Since we were building this system from the ground up, we defined that for us, one of the key objectives is a consistent User Experience across the system.
Our POC was the first MVP dashboard for one of the client-facing teams, leading to a full-scale system.
Our User interface flows and layouts required a scalable structure that could be duplicated, and support additional use cases and functionalities.
One of the tools we defined was a Design System, aligning the appearance and functionality of different components in the system.
This system allowed the creation of new features in an agile way, with components ‘straight from the box’.
Zoom in- zoom out
In order to achieve the top two design objectives, I created a site map and iterated it as the project evolved.
Image of The system’s site map divided into different teams and their available functions
This tool enabled us to constantly look at the system from a birds-eye-view and maintain scalability and consistency across the system.
From the get-go, we’ve defined that being able to measure users’ behavior on the system would help improve it in the long run.
After creating a few features for the development team to start working on, I’ve prepared a report mapping out the types of measurements currently available on the system and recommendations for further analysis.
Image of UX Measurement reports for Mixpannel and FullStory
We kicked off each new feature with a requirements list provided by the product manager.
In some cases, we had a rough sketch to work with, in other cases we didn’t. In these cases, we created one from scratch together.
After defining the problem, our hypothesis and possible technological solution, I’ve defined the suggested outcome based on the following methods
One of the challenges to overcome was time differences between the headquarter office and the US offices.
Most of the interviews were done via video calls or Slack and ‘shadowing’ local team members to better understand what types of workarounds they use in the existing system.
One of the initial techniques I used to understand the users and their needs, was to map out the current flow they go through.
That enabled us to better understand the pain points we wished to address in the current process.
Jobs To Be Done
Once we defined the scope of each feature, I broke down the feature to different Use cases, based on a Jobs To Be Done (JTBD) framework.
After defining the main actions or tasks the users needed to complete, building flows for each functionality was easy.
This process enabled us to ‘catch’ edge cases and cover their solutions at a relatively early stage of the process.
After the main Jobs To Be Done were in place, and the user-flow for each use case was defined, we defined a rough sketch to go over on with the PMs. In most cases, our rough sketches were done on a whiteboard together with the PM, in some cases a deeper sketch was required.
This method helped us to conduct a more focused conversation about a concept that is tangible. It also enabled us to move forward faster.
After we defined the initial feature scope I moved on to the wireframes creating a visual flow.
Using tools like Invision enabled the team to play around with it and see if the user flow makes sense.
Since we designed a style guide and a design system was in the making, it was easy to provide designed wireframes and an almost finalized experience that developers/ PMs/users can review and comment on.
Creating a prototype after the final iterations we defined, helped the team to better understand the flow.
Another method that worked really well for us, was to constantly involve our system users in the wireframes process, to get their feedback before moving on to development.
Once a prototype was ready for use, we sent them a link for usability testing, and asked them to perform a specific task on each feature.
The system is the one source of truth, where all the real-time data is gathered.
This way, both the client-facing teams and the back office teams will be able to work with the same information and functionalities, for the same customers.
Since the data is updated in real-time with the company’s data, the information presented to the teams is always spot on and accurate.
User-friendly and seamless complex actions
By focusing on the JTBD, we created a system in which client-facing teams can perform their tasks in a fluid manner, with ease and confirmation.