Background
Insights is a talent management platform made by SHL that creates visualisations based on the results of various tests that employees do. These tests are psychometric in nature, and indicate various attributes of an employee like aspiration, ability, interest, experience etc. Clients use this information to make restructuring, development and succession planning decisions.
The capturing of data and deployment of tests is covered in a different software (case study here). I have also dived into greater detail regarding the function of SHL in the aforementioned case study.
Problem Statement
The platform didn’t meet all the needs of clients, there were quite a few shortcomings, for example, clients couldn’t compare two different groups of people against a set of competencies. A typical use case that clients really wanted was to compare how 1 arbitrary division (say sales UK) is doing compared to another (say sales USA). The clients used custom Excel dashboards created by our Managed Services team (Customer support) to solve this need which was obviously a non scalable solution to the problem.
Role & Duration
Role: UX Designer | SHL
team size: 2
Duration: 4 months
(June 2022 - sept 2022)
Introduction
Responsibilities
Scoping features to introduce in Q4 2022 or H1 2023
Redesigning the IA, visualisations and the general UX of the product
Conducting user research & Creating personas, journey maps and scenarios
Testing the updated product/features with internal and external stakeholders
Working with the content, UI and dev team to build the product
Scope & Constraints
There were quite a few constraints, and were divided into 3 categories:
Tech
Like limits of 500 data points on a graph, this is an incredible handicap as quite a few clients have upwards of 5000 people in their organisation.
Customer
These were time constraints that forced us to release features in the order of what clients wanted as opposed to a more logical holistic order. For example, customers demanded that the ‘compare’ feature mentioned in the problem statement be released first.
Science
These were concerned around the data that we had to work with. There were limitations like discrete scales that rounded up scores which had a massive impact on the visualisations. This will be elaborated in later sections.
The Process
We based off of the standard Double Diamond UX process however the project was not quite as simple, so I restructured the standard process to meet the Agile needs of this project. The diagram below shows the chronological order of this project.
The diagram below shows a detailed breakdown of the steps shown above.
Preliminary Research & Scoping
We started this project by thoroughly reviewing the platform and visualisations and having multiple meetings with affiliated product managers. Since the product was already in use by multiple clients, there was quite a bit of feedback that was available via the PMs.
The product manager had an immediate roadmap for release in Q4 2022, with a feature called ‘compare’ taking centre stage (will elaborate more on ‘compare’ in the next section). We broke down the epics and stories into features and sub-features and created a detailed plan providing UX estimates and timelines via a Gantt Chart shown on the right.
There were business needs involving senior stakeholders and these timelines were negotiated and readjusted a couple of times later in the project.
Release 1: the ‘Compare’ feature
The first and most complex item on the docket was the ‘compare’ feature mentioned in the scoping. I will use an example to explain this feature:
Assume there is an arbitrary scatter graph that shows a person's Ability and Aspiration in terms of their career, and that there are 10 people in the company. This is shown on the graph on the right.
And let’s assume the company has 2 divisions; Sales and Accounting with 5 people in each. Introducing this bifurcation can add tremendous value to the client as they can now compare different groups to each other. Can you see how there is some clustering between the 2 different divisions.
Of course what is shown above is a simplified fraction of actual outcome. The biggest challenge is selecting the groups or ‘pools’ to compare.
Each participant or in this case employee has some bio data attributes such as division (Sales, Accounting etc), location etc. So filters are the ideal solution, however it’s not as straightforward as it sounds. I came up with quite a few use cases and solutions that go far beyond a simple filter.
As a user/client, I want to...
Compare an individual vs their team or branch
Create a group of all the people in my Sales team + add a couple of individual people that I know personally
Create a group that contains mutually exclusive filters like Sales team in Australia + Marketing team in USA
See people who haven’t completed the tests required for the visualisations
... there a few dozen more cases
Release 1: Wireframes
The process for selecting the people you want to visualise data for is called Workflow.
It had 3 steps:
Create new insight (project) from the ‘homepage’ (out-of-scope)
Find and add some people via the ‘add people’ page
View the results on the ‘insight’ page
I combined atoms from other SHL projects and created molecules & organisms in the form of reusable components for the wireframes. I then put together some wireframes with a couple of experimental micro features here and there iterated these wireframes multiple times with the respective product manager.
This approach did have some limitations like the inability to see who is being added before adding them. After some discussions with devs and PMs, I went back to the drawing board and changed the approach to have 2 tables, one that can be used to find/view people and one that shows all the people that have been added. See right:
I created some new Mid-Fi components and built wires shown below according to the approach on the right. I measured this workflow against each of the 20 or so use cases that I had and iterated the designs to ensure that they matched. I also consulted with the strategy director, product manager and the UX designer in my team.
I then created a prototype and presented it to senior leadership and they were quite impressed with the feature, however they decided to introduce a new constraint that required the entire process of the workflow to be executed on a single page. I.e, merging the ‘add people’ and the ‘insight’ pages.
I came up with the approach on the right, wherein the user would directly land upon a basic ‘insight’ page with everyone in the company pre-populated and they would have the option to filter and manipulate the population as they choose.
I proceeded by creating some Mid-Fi wireframes shown below:
We presented them again to senior leadership who were quite pleased and signed off on the approach.
Prototyping & Qualitative Usability Testing
We finally had something that ticked all boxes. The next step was to test it. Due to the complex nature of the functionality, we decided upon moderated testing with users who have some prior experience with the software although not exclusively as we did include quite a few people who have no prior experience of the platform to get their input as well.
We didn’t have access to UI resources at this point so I created a Mid-Fi prototype based on the use case of comparing High Potential employees in 2 groups, Sales UK and Sales USA. See the video below.
We put together a discussion guide with a script of key questions that we wanted and lined up 7 testers. The sessions were run by myself and my teammate, and were also observed by the product manager who had a few additional questions regarding the features and roadmap.
The 3 of us debriefed after each test and had a brainstorming session where we made changes to the prototype if deemed necessary. Suffice it to say, by the 5th test, testers were flying through the task. We tested key taxonomy conflicts as well.
Most of the changes we made were at a data level and cannot be explained without 5 pages of context. But there were some visual issues like the fact that users couldn’t realise the Headlines section was under the fold. To solve this, we redesigned the section above to take up less vertical space and expose the sections underneath. This is shown in the figure below.
Next Steps: Splitting tasks
Now that we had finalised the wireframes with no loopholes, we reached out to do detailed grooming sessions with the developers. The techies broke out the prototype into 2 releases but we maintained most of the functionality for R1 (release 1), and we did a validation study for R1 with a few users and it all went as expected. We then requested for UI resources and started routine handover sessions and UI/UX workshops.
We finally got some breathing room and requested some time to be allocated to research. The figure below shows the next steps. We split the tasks. I had run majority of the Tech grooming / UI workshops in previous projects whereas my teammate had run the research, so we decided to swap. In this project, I conducted all the research & related activities while he only focused on working with the UI team.
Research
You must be wondering why I did research after creating wires for Release 1. It’s because the items in release 1 had already been scoped by the Product Management Director, had an extremely high priority and a very short deadline as developers had already been allocated to it.
Release 1 was only about 7% of the entire project. The goal of this research was to confirm our hypothesis regarding features that were already in release 1 as well as finding vital information regarding the other 93% of the project that will be covered in subsequent releases.
The task was spit in 2 sections:
Competitor Research
User Research
Competitor Research
My original recommendation was usability testing with the competitor's product and comparing the different products in detail however there were neither the resources to purchase demo’s nor the time to green light in depth testing from the higher ups so I used the next best thing that was available;
SWOT Analysis (Strengths, weaknesses, opportunities and threats) - the diagram below has been intentionally blurred.
Comparison Charts (compared features, UI/UX and science)
User Research (Personas, Scenarios and Journeys)
There were 7 types of projects (Lenses) one could create in this platform. The goal for my research was:
Understand how each of the 7 Lenses are used
Understand the users for each of the 7 lenses
Understand succession planning processes
I started by writing a discussion guide based on the goals above and then conducted 10 semi-structured interviews. Each interview was 60 min long, I spent the first half understanding their day to day in terms of talent reviews and the latter was spent on how they use current SHL products to aid them in their goals and/or any competitors.
I also invited the product manager to attend these as an observer. We debriefed after each session and I created a Figjam mini report for the outcome for each session. The organisation had undergone quite a few changes and so had the platform. A side effect of this was the dilution of the core goal and vision of the product. This is why I chose the following deliverables to synthesise the research.
7 Personas ( 1 per lens)
14 Scenarios ( 2 per lens)
14 Journey maps ( 2 per lens)
After each discussion, I iterated the persona, scenario and journey maps to capture the most accurate representation. These deliverables served in the creation of a long term vision of what the platform should do as a whole and was referred by the product, design, engineering and senior management teams. I kept that in mind and structured my research accordingly and documented everything in a powerpoint that could be shared and presented to senior stakeholders.
A sample deliverable is shown below for 1 lens. Senior leadership was quite pleased with the deliverables so they invited me to display them on a wall in the product team section in the London office to maximise reach.
Key Findings
After conducting all the interviews and collating the information, a trend started to arise.
In simple words the trend was:
“ Our product is almost never used in isolation “
I will focus on the specific use case of succession planning:
A succession pipeline is simply a set of employees who are potential replacements of a critical role, if they are ready, they may be leveraged immediately or may require some more experience/development.
Companies typically do talent reviews on a bi-annual basis whereby a review panel goes through each employee in the succession pipeline. The panellists get together in a room and analyse the person holistically, factors include:
Personal relations
Results from SHL insights (this platform)
Input from their manager etc.
The outcome of this talent review is captured via excel or their HR software.
Note: SHL Insights uses psychometric tests to determine if an employee can be leveraged for a position or if they need more development.
Context
Solution: Conception of a new feature
I created detailed process maps around the area of contention that are shown below. There are 2 types of data that are used as input in the talent review:
Quantitative: like the metrics from SHL Insights
Qualitative: like notes taken during performance reviews that are stored in the company’s HR software.
Another important factor that comes into play during these talent reviews is personal relations but by definition is acquired by a process that is fully offline and difficult to quantify.
I pitched this feature to the Chief Product Officer and the Product Management Director, both were very impressed and endorsed me investigate the feature further.
The Product Management Director and I had a few workshops and roughed out key questions that clients would want answered in service of the single source of truth vision. These included:
I proceeded to create Lo-Fi wireframes that answers the questions shown above.
Lo-Fi Wireframes
The second map shows how this vision would be achieved using;
A new feature that would give SHL Insights the ability to store and track
qualitative data over time.
The map on the right shows how things are currently done, how data from SHL insights is parsed via different software, in this case, MS Excel and how MS Excel and the firm’s HR software are the sources of truth that are maintained over time.
Our vision is to get SHL Insights to be the source of truth.
I created a prototype shown below and conducted moderated testing & research sessions to get contextual feedback. I am happy to report that we had very positive feedback and I have quoted one of the testers below. This served as proof of concept for the senior stakeholders and solidified the feature as a roadmap item.
Testing & Further Research
Next Steps: Reconvening
At this point we had updated the scope of the project and added a feature on the roadmap. Meanwhile my teammate had completed his work with the UI team to provide assets to developers. The next step was debriefing and reconvening to begin working on the next item in the docket which was release 2.
Release 2: Visualisations
Release 1 established a workflow to select people to get to the insight. We could now finally focus on the insight itself and redesign the visualisations.
I built a sample dataset and held white-boarding / ideation workshops with product / strategy teams to determine what graphs would provide the value and at the same time minimise the cognitive load on users. We came to a consensus on which graphs to use shown below:
A set of visualisations that are related to a particular goal/project was called a lens. E.g., a High Potential lens requires candidates to have taken specific assessments and would calculate scores of the participants and determine their potential via specific psychometric competencies.
The main graphical component of this lens has quite a few nuances, like score bands and rounding which are scientific constraints. These elements are contrasted in the simplified graphs below.
Note: I am focusing on a single graph in this section for demonstration purposes but this is just the tip of the iceberg, we worked on 10s of graphs, tables, spider charts that were deeply intertwined and cannot be explained without additional context.
With all the constraints, we had one major problem. Rounding meant that multiple data points would be on a single location in the chart hence would sacrifice distribution interpretation without reading the numbers on the chart. I experimented with various solutions shown below:
Sample task for you!
“Try to find the areas with the highest concentration of people in the charts below.”
Note: These charts are not made to scale / are low fidelity proof of concepts
Notice how much easier it is to be able to find the areas of highest concentration with 3 simple size tiers shown in the graph on the right. This sort of optimisation of individual visualisations was done across all components on the platform.
We then worked with the UI team to create high fidelity designs. Some examples are shown below.
High Fidelity Wireframes
Next Steps & Learnings
We iterated quite a bit with product managers (3 weeks) before presenting to senior executives who made major changes which sent us back to the drawing board. The reason we took 3 weeks to make wires was because we wanted to minimise loopholes and present mid-fidelity wireframes to the senior executives instead of lo-fi wires, which cost us more time. In the next project, we will definitely involve senior stakeholders earlier in the design process as that could have shaved 2 weeks off of our timeline.
Another thing we would want to do is to add buffer time between tasks that must be done in series to account for unforeseen events. We had to run this project really tightly and would’ve really benefited from some breathing room for documentation and housekeeping.
I also had the opportunity to learn a lot about qualitative user research, requirement gathering, Interviewing, prioritisation & scoping, and Agile methodologies.
All in all, I am a big data nerd so I loved this project with all the detailed visualisations.
Thank you
The next steps were to support the developers and QA teams to build the features and plan the launch plan with the strategy and marketing teams. Meanwhile, there were plenty of items left on the roadmap to pick up so on we go…