CERN's Enterprise Analytics tool
Our financial and HR analytics and reporting tools become outdated, both in terms of technology and functionality. Can you redesign both tools, and preferably merge them?
The Process
Project scope
International organizations aren’t always driven by invoicing and revenue. This means that the initial “why?” might not be well defined. Leadership might have good reasons why a product has to be (re)developed but we can’t rely on abstract or hierarchical motives only. Business objectives should always be defined, and shared with those who join a project along the way.
During initial workshops, I tried to identify the core of the objectives, but the environment wasn’t ready to define strategic goals. Tactical goals were defined instead.
Challenge
CERN doesn’t have a workshop culture.
Approach
Deliberately accepted organizational conventions, started with internal workshops, involved clients afterwards.
Result
Good engagement in key stakeholder workshops. Defined rough project goals, business objectives and metrics for success.
Data Analysis
The old systems have been used for many years and valuable information regarding user behaviour has been stored in back-alleys of databases. I wanted to get a good overview of behavioural patterns. The systems contain many documents, reports and filter functionalities and various user roles have different objectives.
Challenge
No analytics tools in place
Approach
Collaborated with database engineers to analyse log files
Result
Quantitative understanding of user behaviour in current systems
Personas
The information gathered in the data analysis phase has been used in various subsequent steps. Combining raw data and user interviews allowed us to define an elaborate list of user types with different motivations. This list could be reduced by grouping overlapping characteristics into a list of 5 personas.
Challenge
Stakeholders think in established system access roles.
Approach
Personalised the story behind user and its objectives, merged roles with overlapping functionalities.
Result
Personas, based on real data and user insights, supported by the stakeholders.
Contextual Inquiry
The old systems were part of the user’s daily routine, but their experiences were unknown by the product team. We shadowed two dozen domain experts from all departments. This resulted in a clear overview of strengths and weaknesses of current systems including pain-point map. In addition, it gave as a deep understanding of how our users work, and how much they still rely on printed paperwork.
Challenge
Departments can operate in their own vacuum
Approach
Specifically targeted "unknown" users from various departments
Result
Eye-opening observations, that proved that various departments have different work practices and that our own department isn't an example for the entire organization.
Ecosystem Mapping
CERN isn’t subject to any domestic or international laws. This means that business processes are highly specific and often complex. I organised a workshop where various domain experts could collaborate to define processes, assets and roles and the relation between them. Participants impressed each other by showing how well they knew particular domains. “I didn’t know you knew that.”
Challenge
Not everyone has the same understanding of CERN's processes.
Approach
Invited a diverse group of participants that could represent different business domains.
Result
Participants taught each other how CERN's administrative world works. A common understanding has been established amongst the participants.
Ideation
CERN’s culture can be hierarchal and top-down. This results in team members relying on decisions from their superiors. They sometimes underestimate how much they have to offer. It’s essential to create an environment in which everyone feels at ease to share their ideas and can contribute to the product direction. Various ideation sessions allowed me to collect ideas from developers and external stakeholders.
Challenge
Some developers are skeptical about being involved in the design process, they would rather build what is proposed.
Approach
Broke ideation process up and involved developers only in the domains that they considered themselves experts.
Result
Extensive series of ideas that served as foundation for mock-ups.
Information Architecture
It’s understandable that specialists take established structures for granted. The organisation of personal data is well understood within the administrative departments but less clear to new arrivals or non-administrative people. Cart sorting enabled me to convince key stakeholders that their understanding of categorisation is not always the same as that of the day-to-day user.
Challenge
CERN’s terminology can be hard to understand, even for CERN natives.
Approach
Ran face-2-face and virtual cart sorting exercises and encouraged participants to add a “don’t know what this is” bucket.
Result
Dramatic shift categorisation and improvement of terminology.
Mock-Ups
CERN didn’t have a UI design strategy. This created a great opportunity. Many applications have similar scopes so, in parallel with this – and a few other projects – I worked on a design pattern library. This allowed me to combine insights from the various projects and to combine user tests to see which design choices would be most suitable.
Challenge
CERN didn’t have a UI design strategy.
Approach
Introduced design pattern library in parallel.
Result
Designed essential pages and elements based on internal design system.
Paper Prototype User Tests
Designing data-driven financial and HR screens means that much of the feedback is related to data validity and efficiency. I choce to let the initial paper prototype phase have an emphasis on content: is the right content there and is the content right? Printed screens allowed the participants to draw on the mockups and share how they would solve particular challenges.
Challenge
Some participants, mainly in managerial roles, prefer discussing high-level design strategy over content issues and interaction flaws.
Approach
Let the participant be in control over the interview, collected contextual data for future usage
Result
Better buy in.
Video User Tests
The first rounds of video tests had a focus on assessing the interaction design and usability of the main elements. This created an opportunity to target a different persona. This persona had a less deep knowledge of CERN’s internal world but gave us great insights in where we had to improve the UX of our MVP.
Challenge
Development team was not used to having their products tested. The amount of improvements can be intimidating.
Approach
Organised informal pop-corn / beer party to show summary of the first user tests.
Result
Understanding of need to improve and a prioritised list of UX improvements in Confluence and Jira.
Specific Element Optimisation
Our first MVP used several out-of-the-box components that didn’t perform well. We didn’t have the luxury to spend much time on redeveloping a new prototype so I created a “static interactive” prototype. I just needed to know where users would click to see which elements they would use. This way, I could test and redesign some elements with limited time, and without the support of developers.
Challenge
Industry-standard components are not suitable for CERN-specific objectives.
Approach
Conducted rapid user tests to convince stakeholders that particular elements need to be changed.
Result
UX improvements for various components and acceptance amongst developers.
Financial Report Reviews
I used paper prototypes to improve the financial reports. I found that giving the users a chance to draw on the printed pages was an effective way to work on specific details.
The data in the screenshots is confidential so the images are blurred. On the left, you see the initial version. The right image shows the design after interviewing more than 10 domain experts.
Challenge
CERN’s accounting structure requires specific solutions for particular and rare cases.
Approach
Conducted paper prototype tests with subject matter experts such that we could directly draw improvements.
Result
Adjusted financial information screens after each interview and gradually improved the design.
Lesson Learned
- This was my first UX project at CERN. The result was a product with a great UX, that allowed users to quickly find mission critical data, tailored for their needs. However, the UX was sometimes too great. My product design vision wasn’t always in the sweet-spot between business objectives, user desires and technical feasibility.
- One of the issues was that the business objectives weren’t strategic enough. I shouldn’t have accepted a compromised project scope definition and should have created more awareness for strategic omni-product impact.
- Development costs are a part of the business objectives too. I also should have provide mored room for developers to share their technical concerns. I was used to being constantly challenged by product teams but CERN’s culture relied a lot on expert opinions and my vision was blindly followed. I should have pro-actively adapted my designs when developers exceeded their estimations. Not all UX optimisations are worth the investment.