7C/ Keep Ux Design for the vLEI Ecosystem
Keep - UX design for the vLEI Ecosystem
Session Convener: Janet Gonzales, Kevin GRiffin
Notes-taker(s):
Tags / links to resources / technology discussed, related to this session:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
For GLEIF we had an ecosystem governance framework that provided the technical requirements and constraints, the user types and regulatory use cases, and of course a strong development team, but the challenge of it was how do we work within this framework to create an experience recognizable to users. This presentation will provide a brief overview into some of the challenges, pain points and breakthroughs we experienced when working through the UX design process to this point for GLEIF.
Goals–
As mentioned, we had to work within the ecosystem governance framework which clearly defined the user types and had specific instructions for what parts of the experience should look like, designing recognizable UX flows to different user types (both technical and non-technical) were equally important, and working within the security of the KERI protocol.
User Flows
Trying to make sense of the different user flows for me started here–taking into account who would be receiving credentials, presenting credentials and issuing credentials and what the edge cases would look like.
User Personas
There are several different user types in GLEIF’s case–enough that there is a glossary, but simply stated, there are GLEIF employees, authorized persons that issue credentials (QVIs), authorized users (ECRs/OORs), and individuals looking to verify credentials. When I was working through the persona process, there were a few things I identified:
- Not every user is going to be a technical user, this needs to be simple, for even non-technical employees to understand.
- In industries like finance, this will be a piece of the broader due diligence process, it’s important to guide individuals through the process, ideally with some tutorial and understanding of their role, since they won’t be in this day in and day out.
Out of Band/Swimlane Diagrams
Part of the verification process is done out of band, and because of this it became important to do some in band/out of band, swimlane diagram creation.
Iterations of Dashboard
Trying to produce an ideal dashboard is only one issue tackled here. Credential issuance, revocation, key management, etc. are far larger issues, but just to show an example of some of the iterations of some of the screens, I’m going to walk you through some considerations taken when developing the dashboard.
Focus on User Friendly Terms
Working with the acronyms at first seemed daunting, and to make it easier on users, we thought using more basic terms on a simple dashboard would be easiest, but when presenting it to GLEIF, it seemed to cause more confusion. “Connection” proved to be too general a term, tasks as well, there needed to be more contextualization around this.
Focus on Visual Hierarchy
With that in mind, we tried to contextualize more and provide all available options to verify, share and issue credentials, and emphasized the tasks section since this is where we envisioned more users would be spending their time. Keys and credentials would be managed from the dashboard as well across all identifiers. This also was still not the level of contextualization that was needed and we needed to make sure that it made sense for all user types, technical, non-technical, GLEIF employees, non-GLEIF, etc but we also wanted to future proof the designs to allow for users to use the Keep for other purposes. We found that balance to some degree in the next screen.
Focus on Contextualization
Here contextualization went almost a little too far, though the terms came direct from the ecosystem governance framework, but that works off of the assumption that even non-technical employees would read the glossary, and even so, in some cases it doesn’t provide the right context for the task itself. We added a short onboarding flow that each user type would have to go through to also help with this issue. We also created a sidebar with generic actions here though that we continue to use in the current form.
Current Dashboard
The current dashboard, accompanied by an “Intro to Your Role” tutorial provides the right balance of contextualization and user-friendliness to navigate through the basic tasks (but it’s fair to admit this is still being worked on). Currently we’re working on screens for iOS and for Desktop.
Brief overview of Keep architecture electron, mirthil, keripy - repo : github.com/weboftrust/keep