carolyn zhu
BD Workspaces (3).png

Blockdaemon Workspaces

 
 

Workspaces for Blockdaemon (BD)

My Role:

Senior Product Designer, partnering with the team’s Lead Designer (Jordan). This project was also led by a Senior Product Manager (Doug). For this work, Jordan led the initial brainstorming and I led the user journeys and flows. We both participated in research and contributed to the hi-fidelity designs.

Key competencies for this project:

  • Information Architecture

  • User Journeys

  • Research

Overview:

November 2022

Project Length: 6 Months

Our web application used an “organizational” structure called “ORGS” to group users and settings. Customers had a difficulty understanding if Orgs should be used like a file structure, or if they were only meant to have one per company. Additionally, all individual’s settings were handled in a “Personal Org” - which was another Org altogether, automatically created for every user with a different set of settings.

The problem:
The “orgs” experience suffers from trying to solve too many problems at once:

  1. A collection of users working as a team for a company, with unified billing and settings

  2. A way to invite one-off collaborators to work on a project

  3. An internal Blockdaemon admin tool

  4. A way to organize work/resources/permissions within a team

the process

I first met with our Technical Account Managers (TAMs) because these are the folks with the most direct contact with our clients and often are doing the actual work on the client’s behalf in a ‘superuser’ mentality. TAMs are the first line of defense and are the ones who hear the client complaints about the web app. TAMs were able to tell us how clients were using the Org Structure - in ways far beyond what they were meant to do.

From there, we set out to understand what users needed from our web app in terms of structure, groupings, billing needs, settings needs.

I broke down the functions of our current Orgs and grouped them by common feature types of other platforms. I pulled inspiration from a lot of commonly known products (Like Google Suite and Figma) to draw connections.

From there, the team and I decided that the functions that hit on the majority of the pain points of our users were: 1) to make Settings easier to find and understand (both for a group of users, and for individual users), and 2) to allow users to collaborate regardless of what company they worked for.

I looked across a handful of similarly-organized web-apps such as Figma, Jira, Abstract, and Slack to see what vernacular they used for similar features. Names such as “Team” “Company” “Organization” “Workspace” “Workplace” were seen in similar products. The Blockdaemon Web-app proved a unique use case though - the users within each “Collaboration Group” may or may not be working for the same team or company. “Workspace” was a common enough term that wouldn’t require users to re-learn a new concept, while also being agnostic enough for use between colleagues or non-colleagues.

Throughout this entire process I continued to conduct internal research and concept reviews with our TAMs to see if we hit the mark on what they’re hearing from clients.

With approval from Design, Product and Engineering leads, we landed on relaunching with “Workspaces” and “Accounts”. This was just the beginning.

The process Part 2: Limitations & Flows

The user journeys were the second biggest block of work for this project knowing that users would be joining the web app from various situations. Additionally, we needed to have a clear understanding of how the backend accounts management system worked and what the engineering limitations would be.

Then, I began mapping out flows for each scenario before ever getting started with low-fi designs. Here is where I worked through open questions at various steps in the flow with the Product Manager and engineering leads.

I collected all of the required flows to launch Workspaces:

  1. New User Sign up from “Create Account”

    1. Including “Create new Workspace”

  2. New User Sign up from Email Invite

  3. Returning User, first sign-in post-migration

  4. Workspace Settings

  5. Workspace Settings for non-workspace-admins

  6. Account Settings

Design time:

Design for this project was broken up into a few key pieces:

  1. Workspace selector / switcher

  2. Profile access

  3. Workspace creation

  4. Settings

For each of these pieces, we worked through wireframes or low-fidelity mock ups to organize all requirements. We then took to higher fidelity to determine the exact design.

Low Fidelity

High fidelity Designs of a Standard Sign up flow + Workspace settings

Design QA:

Once designs are in a dev environment, both I reviewed all screens for discrepancies. As part of our QA process, I screenshot the dev environment with detailed notes about what I’m seeing. I then reviewed these notes with the front end engineers for understanding and agreements. This process continued until all screens match the figma files. In some instances, due to time restraints or technical limitations, I worked with the engineering team to prioritize fast follow improvements.

Conclusion:

The new Workspaces feature was released in November 2022 - and the response has been extremely positive. Clients know exactly where to go to access their settings and personal profile needs.

Upcoming Additions: Next up for Workspaces is an update to User Permission Groups, and an Enterprise feature that would enable companies to manage their employee’s accounts.