How Spaces can augment collaboration in teams
Client Linkurious
Project Date Oct. 2021 – Mar. 2022
Role Product Designer
The Challenge
LKE allows users to see data points as well as relationships between those points. This in turn helps investigators detect anomalous activities and identify potential threats – efficiently handling and easing up financial crime investigations. This investigative work, however, is a team effort. LKE was initially conceived as single-user tool and so, the current version doesn’t suit the clients’ workflow. This paradigm shift forced the team to re-think how the product works and introduce a more team-centric approach.
Research
We have looked into how our clients organized their teams. It varies widely and is context-dependent. Example client uses cases are as follows:
- A bank department that handles Fraud has its team divided into two: one unit that looks for fraudulent patterns in data, another one which verifies these trends and implements a query [1] to detect them on future transactions.
- Another bank whose unit’s main focus is Anti-Money Laundering (AML) is split between casual and power users – the former being the business people who do the investigations and the latter being the data scientists who take care of implementing the queries.
From the insights we’ve gathered, despite the difference in team structures and use cases, it can be gleaned that a typical lifecycle is as follows: A user joins a team, moves to another team, and eventually leaves the company (See Figure 1).
Process
My role as a product designer involved getting the research done from conception until the implementation and validation phases. I was working closely with the triad (product manager (PM) and tech lead of the squad) and sometimes wearing the hat of a PM as necessary. However, my main area of focus was facilitating workshops (ideation, refinement, among others), communicating with stakeholders (Head of Product, Head of Design, CTO, Customer Success Managers, Solution Engineers) creating design specifications, and validation. Together with the triad, we also built the road map for the next release cycle and adjusted our goals every sprint as we saw fit.
Blueprinting and De-risking
From the insights we’ve gathered and after formulating user expectations, we started building a blueprint – a high-level view of the system that helps drive targeted conversations. As can be seen in Figure 1, the blueprint outlines the user flow without bothering much on the details. It served as the reference point from where we began to specify individual sections. This was, in turn, useful to identify an technical and user experience (UX) risks.
The blueprint also helped the team plan ahead which components or elements were needed that were not yet part of the Design System, and thus required prior design and implementation.
Story Mapping and Dimensioning
Together with the triad, we’ve identified the jobs and created a story map. We looked at the different dimensions of the jobs and prioritized accordingly – taking into account the need and which use case we to optimize for. Simply put, needs coming from our target market and current product positioning allowed us to focus our efforts where it mattered.
Ideation and Refinement
There were specific sections of the user flow that needed to be discussed in more detail while there were others that were straightforward. Those that had no clear solution had to undergo an ideation session while the rest were down for refinement.
Topics that we found risky merited a separate discussion, even an entire sprint, to solve. We’ve identified that, for example, solving the issues on concurrent access (i.e., multiple users opening the same visualization) was critical for the Customer Success team. That in itself deserved a couple of sprints to deconstruct, test, and build a solution. While others, such as renaming a visualization, is straightforward that we only needed to refine the current behavior to avoid reinventing the wheel.
Implementation and Validation
We have broken down the work into multiple user stories that were independent, valuable, and testable. Design and tech specifications along with acceptance criteria were created for each user story. Validation happens after testable blocks were implemented. I used a validation checklist, the template of which I created for the design chapter.
Solution
We introduced Spaces, a way of organizing visualizations and sharing them with teams.
The architecture consists of three sections:
- My visualizations - where private visualizations sit, sometimes used to create draft and early visualizations
- Shared with me - where visualizations that are shared with an individual user is located
- Spaces (one or many) - where visualizations shared with a team or teams are stored
Visualizations that are created within a space are automatically shared with users that are part of that space. These are by default editable by anyone who has access to it. However, concurrent editing is prohibited, i.e., only one user is allowed to edit at a time while the others remain in View-only mode. None of our clients’ use cases require multiple users editing at the same time.
The pain points on sharing had been addressed by this solution:
- From individual sharing to team sharing, it is now more efficient to work on visualizations together while maintaining folder hierarchy within the space.
- Visualizations created by a deleted user remain in the space, hence, migrating the assets separately is no longer necessary in most cases.
- The investigative work flows naturally as analysts can pick up from where someone else has left of without getting bogged down by individual sharing and access rights.
Conclusion
The creation of spaces is indeed a step forward to a more team-centric approach to financial crime investigation, a workflow analysts are more used to. The initial release is only the beginning to unearthing how else we can improve this feature.
It will take at least a few months to get early feedback on this. Through telemetry, however, we can track certain aspects such as the frequency of a space being shared on an individual level, with groups, or with everyone. This will help us understand usage as well as verify our initial assumptions.
One of the things I learned most about the project, however, is making decisions and how to get there early and efficiently. It has not always been a smooth road – we had misalignments and unnecessary back and forth but in the end, we managed to build something that meets our users’ needs. Wearing different hats along the way has also taught me to empathize more with others and navigate various meetings fluently so I can present what is needed but also get the most out of it.
Next steps
After releasing version 4.0 with Spaces at the core of the product, we intend to revamp the page to give it a more polished finish. This is an aspirational mock up that I have designed.
[1] Queries allow users to retrieve data from their graph database. Most clients use Neo4j as their graph vendor, hence, they use Cypher as the query language.