Building a platform providing end to end visibility of client onboardings and product implementations processes.
By asking the current actors of the onboarding process to tell us about their day jobs, we put together maps of what the product could look like, clinically recording the different steps in the process.
However, every person involved in the process used different systems, a different vocabulary and different timelines. Tricky mapping!
Whole weeks were spent analysing data, interviews, systems. A team of 20 people worked full time on figuring it out.
We encountered a major issue: it was very complicated to talk to anyone relevant in the company and there were a lot of people gathering the same information.
We had some very successful workshops as well as terribly disorganised ones, but we learned and managed to get enough information to get our personas correct.
In the end we managed to get 6 Persona types, split into 2 groups. The personas were never fully validated by the client, but they worked when we started user testing.
We put together a workshop to validate our assumptions regarding user journeys + personas.
It was not surprising when no one agreed on one solution and we had to compromise quite a bit. What helped most was a prioritisation exercise: we finally had something to work on and with.
With time we narrowed the map down and removed a lot of the manual input instances which made the tool somewhat lighter.
Some areas were expanded, some completely removed.
We prioritised depending on what users needed, what stakeholders required and what could genuinely be built in the systems.
The solutions presented didn’t cater for all the problems we were encountering every day, among which were these two crucial questions:
- What actually constitutes a project?
- How is a project started in each system? Is it possible to do that automatically?
< None of these solutions were adopted: steep learning curves, missing the wow factor…
We tested our solution as often as possible and iterated as best we could: it seemed impossible to find something that would work and please everyone.
Because our ideas were radically different (one linear, spreadsheet like, and the other very round and visual) we needed to make sure everyone would be able to read their portfolios and work with them easily and quickly.
We put together some AB testing prototypes and some questionnaires to figure out which solution was easiest to use.
It was extremely well received by stakeholders and higher level employees. But it worried the day to day people who would work with this constantly: they thought the tool wouldn’t add enough value to their work.
This remained a point of contention throughout the rest of the project.
Because we weren’t really agile, there was a need for the UX and UI team to deliver proper documentation.
I put together an interactive documentation system that explained the ins and outs of each interaction, by sprint, each linked to user stories and referenced in Jira.
The developers had access to the documentation and it was updated in real time thanks to Axshare.
This documentation was used by the whole team a reference to know which functionalities to use for the next parts of the project and explain interactions to stakeholders.