With Steward, the end user or a data owner can upload data, discover apps, allow or deny app permissions, manage permissions and review usage of their data assets. Steward is used by a few of our customers' end-users including Nebula, The Music Fund, Castalise, and more.
MY ROLE
Lead designer – discovery and ideation, lo-fi design exploration, interaction design and prototyping
TEAM
Naheed Vora, Product Manager Nikhil Sharma, Full-stack Engineer Luka Jeran, Front-end Engineer Xi Zhang, Front-end Engineer
+ back-end engineers
To lead the Data-Protection-As-A-Service market with blockchain technology, we are building Oasis Parcel, a privacy-first data governance tool that isolates and protects your most sensitive data. Our goal is to empower developers and companies by helping them build secure and compliant infrastructure.
Parcel GA has been recently released, used by a few of our customers including Nebula, The Music Fund, Castalise, and many more.
MY ROLE
Lead and solo designer – discovery and ideation, lo-fi design exploration, interaction design and prototype
TEAM
Naheed Vora, Product Manager Charlie Jacobson, Product Manager Nikhil Sharma, Full-stack Engineer Luka Jeran, Front-end Engineer Xi Zhang, Front-end Engineer
+ many more back-end engineers ❤️
DATA & CONSENT MANAGEMENT TOOL
Steward was designed to help individuals regain ownership and control over their data. The product aims to empower individuals by allowing them to store data securely, have an option to whether provide or withhold data to the app, and make informed decision along the journey.
One place to manage digital assets with full control and ownership
We designed a User Privacy as a Service product Steward, an end-user app that provides data sovereignty with the audibility of their data use. Our vision for Steward is communicated via Steward features – allowing individuals to take data control and ownership back from businesses and app developers.
Above is Parcel App Create flow where user can create permissions. Here, the user is creating 2 analysis permissions, ML and Genome analysis.
Steward users, once chose to manage their app data on Oasis blockchain network, can either allow or deny to each permission.
Permissions — The user can allow or deny app permissions. Permissions can be revoked at any time.
Data History — Allows user to have full visibility into how their data is used by the app.
H H H
Allow or Deny Permissions
All users who opt into Oasis flow–to take control of their data with Oasis– would either allow or deny app permission. Allowing permission means the user grants access to the app –so the app can take action with the user data as described in the permission. Once the data is accessed, users can see when and by whom the data is accessed.
One of our main goals was to educate the users on the whole concept of Steward and its features. For example, users need to know how secure it is to store their data on the blockchain, and with Steward, they can have full control and ownership over their data. I also made sure the users understand the consequences of their choice and the fact that they can revoke access from the app at any time. These design solutions can help the users make more informed decisions and feel safe.
Confirm Permissions
This closure page provides the user an ability to review or update their permission choices at the end of the flow. One of the inspirations I got during my design exploration was an order confirmation of E-commerce products where the users can confirm what they purchased. I expect that the confirm/update permission UI in this final page is especially critical for our near future product plan which is supporting multiple permissions per app.
OVERVIEW
Description of app information. The info includes what the app is and links to their main website and privacy policy.
PERMISSIONS
Users needed a way to quickly review and update their data permission to app at any time.
YOUR DATA
Securely stored user data. The dataset may be uploaded by the user or the app developer, depending on the use case. A user can manage their data –download or delete it– and monitor a record of all actions for each data.
DATA HISTORY
An unforgeable data access history. It makes it easier for users to see who has accessed their data and when. Various filters are provided so users can easily navigate the table.
USER DATA
A data table with all user dataset uploaded as part of this app. Dataset is either permission granted or revoked.
AUDIT HISTORY
A single source of all data access activity history. Only app admin can view these logs.
RESEARCH
As an early startup member knowing that we didn't have enough resources, often I had to make design decisions relying on my gut feeling and UX knowledge. Working on Steward, I tried as many design variations as possible, which helped me empathize with different categories of users: like those who have trouble building up digital trust in technology, who are often confused about which of their data are collected and accessed by businesses, and who feel a lack of control over their data.
I conducted competitor research -not limited to data privacy products but those beloved and trusted by global users- to understand their design principles which I can see through their UX and UI.
With the most promising design thoroughly selected by my teams, we conducted user testing (think-out-loud) and a user survey. We asked non-Steward users to go through the Steward app data permission flow to understand if the design is effective, based on their task completion rate and time. Also, we asked our new Steward users follow-up questions regarding why they chose to use Steward and whether they understood our product and features correctly.
DESIGN PRINCIPLES
With the research insight, I was able to create design principles for data security/privacy and these include:
1. Be open and transparent; privacy-related policies and procedures should be documented and communicated as appropriate. Info about the policies relating to personal info management should always be available to an individual. 2. Give control to users; empower users to play an active role in managing their data. They should be provided access to their data and informed of its uses. 3. Be specific about user's behavior consequences; for example, let them know the privacy impact of their actions and assess risk 4. Put visual elements that indicate the process is secured; seeing is believing. Even if a product has no security flaws, with no visual indicator users won't trust it. 5. Privacy as a default setting; ensure users by showing them their data is automatically protected. If an individual does nothing, their privacy remains intact. No action is required on the part of the individual to protect their privacy - it is built into the system by default.
Exploration and iteration
Steward app permission flow can be confusing for the new users if it does not provide enough context. Also, there is an inevitable transition between the 3rd party app and Steward within the app permission flow. Thus, a little UX mistake can lead to a massive user churn.
My biggest UX priorities include: • make the transition between 3rd party app and Steward as smooth as possible, • design the first user onboarding and app permission flow easy and short, • display enough information of how Steward works at the right time and right place, • and put aha moments to make sure that users experience and understand Steward’s core function and value as often as possible to prevent churn.
Permission Card Design
The concept of permissions and allowing/denying access is complex so I wanted to make the UX and UI here extra clear.
One of the critical design decisions I made here is placing a message that pops up when a user chooses an option, which describes the impact of their choices. Later, I got a lot of positive feedback on this design via user testing.
2 Landing Pages
One of my assumptions for Steward is that we need to make the landing page of App-to-Steward flow a bit different from our default landing page – add some context or visual cues for users who transition from App to Steward. So I decided to make the landing page sort of a bridge that connects the App and Steward with intentional visuals, which will help reduce the user's cognitive load during the transition between 2 pages.
Closure/Confirmation Page
I explored many variations of the closure page. First, I started with a welcoming illustration. However, as I explored more and more, it became clear that the page could be more effective with a product preview image, especially considering that Steward is a fresh concept product and that we are in the early stage of Steward launch.
Also, some of the major design principles in the data security area are "Be transparent" and "Give the users control." With this in mind, I decided to show users' permission choices at the end of the flow, which is similar to eCommerce order confirmation.
Mobile app exploration
I also had an opportunity to work on the Steward mobile app with an app developer team, which was unfortunately not shipped in the end because company direction and focus had changed.
USER DATA
A data table with all user dataset uploaded as part of this app. Dataset is either permission granted or revoked.
AUDIT HISTORY
A single source of all data access activity history. Only app admin can view these logs.
