MOSIP's Inclusion Program

Problem Statement

The Modular Open Source Identity Platform (MOSIP) is partly supported by the Bill & Melinda Gates Foundation, providing nations with technology to develop and manage their own national identity (ID) systems.

The MOSIP Team wanted to identify how well users from these countries would be able to use the ID systems. What product changes would make it more inclusive? And how could we use these changes to build a set of design guidelines that developers of digital public infrastructures (DPIs) could follow?

The research objective was to develop a comprehensive set of design guidelines for enhancing inclusivity in large-scale B2B digital public infrastructure (DPI).

Impact of this work

🔮 New toolkit: Created a toolkit and design recommendations for any developer building a DPI or DPG.

🪙 Secured Funding: I was awarded a research fellowship to support MOSIP's mission towards creating inclusive products.

Tools

Figma
Atlas.ti
Otter.ai
Zoom

My Role

UX Researcher

Team

2 Product Owners
1 UX Designer
1 UX Researcher
7 Developers
2 Product Managers

Cognitive Walkthrough

Prioritization

Analysis of bug fixes

Development of design guidelines

Cognitive Walkthrough

The team had created two personas based on their past research. Using these two personas, they had conducted cognitive walkthrough sessions on high-fidelity prototypes to assess the information handling, and pinpoint any problems. Overall, they pinpointed 30+ inclusivity concerns across the Inji Mobile app’s user interface and experience.

Snapshot of the buglist

Prioritization of bugs & fixes

Based on the cognitive walkthrough, I compiled a list of inclusivity bugs and along with the product owner and UX designer, prioritised them according to their severity and impact on user experience. Factors such as frequency of occurrence, criticality of the affected tasks, and development cycle were considered during the prioritization process.

For each identified inclusivity bug, the team analyzed potential solutions and proposed design modifications to address the issues. The analysis involved considering the personas to ensure that the proposed fixes were inclusive and user-friendly for both personas.

Analysis of bug fixes

I independently performed an affinity diagramming exercise, grouping the proposed bug fixes into related strategies. This process yielded 15 distinct strategies. I then filtered this set, removing strategies that were either too vague to design for directly or too specific to a particular scenario. After filtering, I was left with 11 strategies, each of which was summarized in a concise sentence or phrase before presenting it to the team for feedback. These summaries formed our first iteration of the inclusivity design guidelines.

Design Guidelines

It became apparent that without a clear understanding of available options, the effort required, or the benefits of each choice, users who are cautious about trying new or unfamiliar features (Abi-like) may avoid them. This could lead them to pursue slower or error-prone options instead. Furthermore, users who are not inclined to explore various options (Abi-like) might struggle to identify the best path forward if the choices and efforts required are unclear.

Therefore, we created guidelines centered around establishing clear expectations: Whether it involves various tasks or alternative pathways, users should grasp the connections between their actions.

Here are two of the 11 guidelines we created in the first iteration:

🎯 Clearly Indicate Multiple Paths to Achieve a Goal

🎯 Clarify dependencies between multiple user goals in the same screen

Page updated

Google Sites

Report abuse