Scenid Cloud

Creating a multi-product business management platform

Scenid Cloud is a B2B ecosystem which was commissioned by a German healthcare institution to manage their industry contacts and track and communicate important KPIs internally. It includes a CRM (Customer Relationship Management) tool, called Customers, as well as a BI (Business Information) tool, called Insights, and other smaller features.

I worked on this platform and the products within for 3.5 years as the only UX / UI Designer. I was responsible for conceptual functionality, visual design and cross-platform continuity. Having started as a UX / UI Design Intern and working my way to Senior UX / UI Designer, I gradually took on more responsibility in communicating with clients and stakeholders and taking part in strategic decision making for Scenid.

Customers

Customer relationship management and customer insights

Role

UX / UI Designer

Team

2 Developers, 3 Stakeholders

Product

CRM tool

Timeframe

2020 – 2023

Customers is a CRM product that helps the customer satisfaction team effectively communicate with customers and explore and share data with each other. Accurate representation of organisational structures and employment relationships enable users to save important business contacts and easily navigate the contact database as well as the comprehensive contact history.

Briefing

A redesign for the existing version of Customers had just been given the go-ahead shortly after I joined the team. The goal was to make customer data more accessible and to streamline the most important user flows for maintaining the customer database.

Sitemap of the first version of Customers

Sitemap of the first version of Customers

Mapping out user groups

Mapping out user groups

Personas & use cases

Personas & use cases

Analysing screens

Analysing screens

To get a better understanding of the current state I then also created a sitemap and analysed some of the screens. Together with the team we established use cases and personas based on stakeholder feedback.

To get a better understanding of the current state I then also created a sitemap and analysed some of the screens. Together with the team we established use cases and personas based on stakeholder feedback.

Based the findings from this we formed hypotheses for the redesign. To prove or disprove these I created a survey for the core users from our client’s customer satisfaction team. The results informed our user journeys as well as our overall approach to the redesign.

Discovery

We started the redesign process by asking stakeholders what wasn’t working with the initial version of Customers. For this redesign process we had weekly, later bi-weekly, feedback sessions in our team to present findings.

To get a better understanding of the current state I then also created a sitemap and analysed some of the screens. Together with the team I established use cases and personas based on stakeholder feedback.

Based on the findings from this we formed hypotheses for the redesign. To prove or disprove these I created a survey for core users from our client’s customer satisfaction team. The results informed our user journeys as well as our overall approach to the redesign.

Discovery

We started the redesign process by asking stakeholders what wasn’t working with the initial version of Customers. For this redesign process we had weekly, later bi-weekly, feedback sessions in our team to present findings.

Discovery

We started the redesign process by asking stakeholders what wasn’t working with the initial version of Customers. For this redesign process we had weekly, later bi-weekly, feedback sessions in our team to present findings.

Based the findings from this we formed hypotheses for the redesign. To prove or disprove these I created a survey for the core users from our client’s customer satisfaction team. The results informed our user journeys as well as our overall approach to the redesign.

Approach

Looking at similar products beyond the scope of CRMs, I took inspiration from Contacts Apps which provide a common and simple navigation for contact databases: an alphabetised list.

From the user journeys and rough architecture I sketched out networks of user flows. I used the contact list as a central navigation element, complimentary to search, and arranged all user flows around this main part of the product. Then I created wireframes for all user flows, outlining what types of components would be needed for each screen.

Approach to search

Approach to search

Approach to navigating organisational structures

Approach to navigating organisational structures

Wireframe new layout

UI framework & design system

For the new UI of Customers we decided to switch to a new framework because it offered more flexibility for design and development and therefore the product itself.

For the design system we tried stay close to the framework, trying not to create unnecessary new components, and the guidelines of Material Design. The colour palette needed to stay in line with the clients CI, but we made the styling easily editable so we could later create different tenants of the same platform for different teams or customers with different colour palettes.

Screen design & handoff

After validating the wireframes and user flows with the client-side product manager, I started converting them into screen designs using elements from our UI library and some custom components based on Material Design. The developers in my team then implemented these designs after a final internal review. Throughout the successive implementation I consulted whenever I was needed.

We tested the product with key users from the most important user groups before launching. The findings helped us tweak certain features and re-prioritise the information hierarchy for some elements.

First iteration of the new Customers

First iteration of the new Customers (Journaling Feature)

Launch & feedback

After safely transferring the customer data from the old system to the new we were able to launch the new version of Customers. With the launch we also established a new feedback loop with the client in order to better meet evolving user needs.

The product eventually took on more responsibility from other software tools within our client’s organisation as further development went on.

Database view of latest version of Customers

Map view of customer database

Custom data tables

Feature refinement and further development

Through our new feedback loop we had a lot of new ideas and input from our client and the users within their organisation which we reviewed regularly. That way we were able to provide users with regular updates that led to more user engagement and involvement throughout the years after the launch.

Learning how certain features were being used allowed us to expand on those functionalities beyond the scope of the initial launch.

Updates

To implement updates and develop features requested by users we worked in an overlapping 3-week-sprint cycle with 1 week for planning and coordinating with the product manager, 1 for design and 1 for development. I was responsible for the design part, following a double-diamond workflow.

I scheduled user interviews to find out more about a request or to test newly developed solutions. Aside from solving user feedback, I made sure new features or updates were consistent throughout the product and didn’t create any new problems elsewhere.

Updates

To implement updates and develop features that users requested we worked in an overlapping 3-week-sprint cycle with 1 week of planning, 1 for design and 1 development. I was responsible for the design part, following a double-diamond workflow.

I scheduled user interviews to find out more about a request or to test newly developed solutions. Aside from solving user requests, I made sure new features or updates were consistent throughout the product and didn’t create any new problems elsewhere.

Updates

To implement updates and develop features that users requested we worked in an overlapping 3-week-sprint cycle with 1 week of planning, 1 for design and 1 development. I was responsible for the design part, following a double-diamond workflow.

I scheduled user interviews to find out more about a request or to test newly developed solutions. Aside from solving user requests, I made sure new features or updates were consistent throughout the product and didn’t create any new problems elsewhere.

What I learned

Having worked on this product for over 3 years, I learned a lot about nurturing stakeholder relationships. I learned how opening up feedback channels can lead to more user insights, higher acceptance, and overall a more collaborative atmosphere. If users feel more involved, they’ll participate more.

I learned to streamline and simplify complex processes and adapt them to ever evolving user needs. Just as user needs grow and evolve in tandem with the product, so too does the design system. Overall, I learned a lot about what it takes to create a platform from scratch and how to maintain it as well as the structures necessary to enable user activity to varying degrees of access.

Insights

Business Information System

Role

UX / UI Designer

Team

2 Developers, 2 Stakeholders

Product

Business intelligence tool

Timeframe

2021 – 2023

Insights is a business information system commissioned by the same client as Customers. It lets teams create custom visualisations from their own data sets to keep track of their KPIs. Users can create their own dashboards and share them with other users. Insights makes an organisation’s data visible and accessible to its members and teams.

Briefing

Next to Customers, our client also wanted a new version of their BI tool, Insights. With the new version our client wanted to be able to create dashboards tracking importing KPIs on their own and adapt them to changing demands and data sets. Our shared vision for the product was for users to be able to create dashboards from any data set, using any kind of visualisation.

Process

Allowing users to visualise their own KPIs brought varying degrees of complexity. Therefore, the new version of Insights was developed in 3 stages across the space of 2 years: first dashboards, then data input and lastly custom graphs. Each stage built upon the previous as to incrementally increase functionality and followed the same process during production.

Dashboards

We built the dashboard system first as a proof-of-concept for co-creating dashboards. For this we interviewed key users to get a better understanding of how they were currently accessing KPIs and what the dashboards would be used for. Additionally, we looked at other BI products and collaborative tools that used shared canvases. We also researched general use and best practices of BI dashboards to contextualise our efforts.

Early sketch of graphs on a Dashboard

Early sketch of graphs on a Dashboard

Sketch with meta data

Sketch with meta data

We determined that our approach to the dashboard system should balance accuracy with ease-of-use. Building Insights within the same ecosystem as Customers allowed users to access both products via the same account and paved the way for symbiotic functionality.

Wireframe of a dashboard

Wireframe of a dashboard

Final design of a dashboard in editing mode

Final design of a dashboard in editing mode

We determined that our approach to the dashboard system should balance accuracy with ease-of-use. Building Insights within the same ecosystem as Customers allowed users to access both products via the same account and paved the way for symbiotic functionality.

We determined that our approach to the dashboard system should balance accuracy with ease-of-use. Building Insights within the same ecosystem as Customers allowed users to access both products via the same account and paved the way for symbiotic functionality.

Together with the developers we established technical constraints for ensuring readability and preventing misinterpretation. I then mapped out use cases and user journeys as well as rough sketches of the dashboard canvas. To connect all individual sketches and solutions to a coherent system I created user flows with wireframes. From these I created screen designs with components from our platform’s established design system. Our developers then implemented these designs with my guidance.

Together with the developers we established technical constraints for ensuring readability and preventing misinterpretation. I then mapped out use cases and user journeys as well as rough sketches of the dashboard canvas. To connect all individual sketches and solutions to a coherent system I created user flows with wireframes. From these I created screen designs with components from our platform’s established design system. Our developers then implemented these designs with my guidance.

Together with the developers we established technical constraints for ensuring readability and preventing misinterpretation. I then mapped out use cases and user journeys as well as rough sketches of the dashboard canvas. To connect all individual sketches and solutions to a coherent system I created user flows with wireframes. From these I created screen designs with components from our platform’s established design system. Our developers then implemented these designs with my guidance.

Data input

In order to allow our client to manage their own data sources for the KPIs displayed on their dashboards we implemented a data input system during the second stage. After getting briefed on the requirements we assessed the technical implications and concluded that we would create a unified upload process for all input types. My developer teammates went through the upload process with me, so I could understand what the necessary steps were and how data was stored in order to build the foundation for visualisations.

Final version of source data overview

Final version of source data overview

In close feedback loops with the developers and a key user I created sketches and user flows and came up with a table editing feature that let users generalise overrides for data sets. We streamlined this process and adapted it to be used for later editing as well. We prototyped a version of this and tested it with stakeholders to see whether they could make the adjustments to the data sets that they needed and how easily they could follow the process. Our findings changed our perspective on user responsibility and the scope of the feature to simplify the process. I created detailed designs of the altered process and our developers implemented the changes.

In close feedback loops with the developers and a key user I created sketches and user flows and came up with an editing feature that let users generalise overrides for data sets. We streamlined this process and adapted it to be used for later editing as well. We prototyped a version of this and tested it with stakeholders to see whether they could make the adjustments to the data sets that they needed and how easily they could follow the process. Our findings changed our perspective on user responsibility and the scope of the feature to simplify the process. I created detailed designs of the altered process and my developer teammates implemented the changes.

In close feedback loops with the developers and a key user I created sketches and user flows and came up with a table editing feature that let users generalise overrides for data sets. We streamlined this process and adapted it to be used for later editing as well. We prototyped a version of this and tested it with stakeholders to see whether they could make the adjustments to the data sets that they needed and how easily they could follow the process. Our findings changed our perspective on user responsibility and the scope of the feature to simplify the process. I created detailed designs of the altered process and our developers implemented the changes.

Graph editor

Lastly, we built an editor to allow users to create custom visualisations from their own data sets. We discussed with the project managers how this part of the product would fit into their organisational structure and workflow and who would be working with it most. In talking to some of these potential users we learned how they approached data visualisations and what details they focussed on.

The time planned for this last stage of development was limited and there were many unknown factors around the technical feasibility of an interface for editing data visualisations. Therefore we decided to develop the graph editor in rapidly prototyped iterations. Each week we designed and developed a new version of the prototype and had it tested. We reviewed the progress regularly in weekly and sometimes bi-weekly meetings with our project managers to decide how to proceed.

The design of the interface had to provide a clear model of how visualisations were constructed. Having researched different graph types and visualisation models throughout the development of Insights, we mapped out the technical process of how graphs were generated. Covering many examples and use cases we eventually found a way to translate it into a process that users would be able to follow. I then went on to create designs to facilitate this and our developers implemented them. The feedback we got from the tests showed us that this solution enabled users to not only visualise the data they wanted but engage with the data sets in ways we hadn’t anticipated.

Early sketch of graph types

Early sketch of graph types

Early sketch of data cube model

Early sketch of data cube model

The design of the interface had to provide a clear model of how visualisations were constructed. Having researched different graph types and visualisation models throughout the development of Insights, we mapped out the technical process of how graphs were generated. Covering many examples and use cases we eventually found a way to translate it into a process that users would be able to follow. I then went on to create designs to facilitate this and our developers implemented them. The feedback we got from the tests showed us that this solution enabled users to not only visualise the data they wanted but engage with the data sets in ways we hadn’t anticipated.

The design of the interface had to provide a clear model of how visualisations were constructed. Having researched different graph types and visualisation models throughout the development of Insights, we mapped out the technical process of how graphs were generated. Covering many examples and use cases we eventually found a way to translate it into a process that users would be able to follow. I then went on to create designs to facilitate this and our developers implemented them. The feedback we got from the tests showed us that this solution enabled users to not only visualise the data they wanted but engage with the data sets in ways we hadn’t anticipated.

Latest version of graph editor

Latest version of graph editor

Dashboard sharing dialogue

Dashboard sharing dialogue

Screen design

All parts of Insights connect to each other and to the rest of the platform through a menu in the navigation bar which also houses basic information and functions retaining to user identity. Because the dashboard, data input and graph editor systems were built successively yet separately, it was important to have the big picture in mind for the designs.

Although they are laid out differently to facilitate different user flows, these differences also help users with orientation within the product. The dashboard system and graph editor are both canvas-based, but while the graph editor highlights the tools and settings to construct a graph, the dashboard system draws the attention to its contents rather than its functions. Customers has features with similar functionalities that share these characteristics.

Launch & feedback

We did a final round of testing, making sure all our client’s use cases were covered and tried. And after all intranet data sources were connected, Insights was launched and open to use.

The graph builder completed our original vision of Insights. It was now possible for users to use their own data to create accurate visualisations with a visual editor.

Although my time ended just as the new version of Insights launched, the response and feedback I witnessed was generally positive. The tools we were providing to our users were received by some as useful and by others as eye-opening.

What I learned

Working on the layout and visual language of a complex editor taught me to balance many components to create a pleasant and coherent crafting experience. Researching graphs and human perception of visual information has changed my perspective on interface design in general. I was able to bring this knowledge into the project and learned how visualisations are constructed. Sometimes learning about technical foundations and constraints are not only necessary but can yield surprising results that ultimately benefit users.

The complexity and fuzziness of problems impacts our ability to assess how much time or effort it takes to solve them. These unknown factors also extend to communication within teams. I learned that in approaching problems with a lot of unknown factors close iteration loops as well as clear communication within a team are increasingly important as team members’ ideas of the product in question can differ widely.