# UX Design
Data Management
SaaS (B2B)
User Experience
Redesign
Web
Overview
MY ROLE
Lead UX researcher and designer
DURATION
Jan - Aug 2024, 30% FTE
PROJECT TYPE
Usability test and redesign
A BIT OF CONTEXT
Version 1: NCSA devoted 10 years to develop the first version
Version 2: The phase I led to improve the usability of version 1 and to explore a few new ideas
METHODS
User interviews
Usability testing
Prototyping (low-fi and hi-fi)
TOOL
Figma
Zoom
Google spreadsheet (qualitative analysis)
Project Context
Clowder was targeted to provide data services to general research, enabling researchers of any domain to store their data regardless of the size, and to freely customize their niche way of processing the data under certain research protocol.
Clowder supports data management of multiple data types, e.g., numeric, textual, imagery, audio, video… Clowder also provides users fundamental generic data processing tools (the "Extraction") to avoid redundant works.
To lift Clowder usability, we invited targeted users to learn their current solutions to data management and their feedback on the current development of Clowder.
There are 2 types of deliverable for this project:
Usability problems and solutions
Exploratory findings that will be reflected in the next design phase
The Action I took: a Usability Test
Methods and setting
Each session took 1 hour, covering a semi-structured interview of 3 or 4 sections (think out loud protocol and task-action observation and communication) and a SUS evaluation survey.
User sessions
9 Usability tests were conducted from Apr - Aug 2024.
Participants
I used snowball recruitment and recruited 9 participants in all. 5 Participants fell in the data scientist category (2 researchers, 3 data scientists from their self identity), while 4 participants fell in the developer category.
SUS quantitative score
Due to time constraints, I collected 7 SUS input, and the final SUS score is 73, which is above average SUS score, indicating that the current Clowder software is acceptable but can still be improved.
The following sections present a few typical usability problems and solutions:
Poor Contextual Awareness
The usability problem that users struggle to understand where they are, what they’re doing, or what actions are available in a system, often due to unclear cues or feedback.
1.1 Unawareness of location in vertical hierarchy
Usability test result: participants find it confusing to aware where they are in the folder hierarchy.
Design rationale: I designed the breadcrumb to serve a dual purpose, acting both as a folder hierarchy prompt and as the title for the current page. I enlarged the breadcrumb of the current page to improve its affordance.
Before
After
1.2 Missing of the extractor target
Usability test result: participants weren't able to tell from the interface that the extractor only applies to datasets at the same level where the extractor is located. However, users prefer to run the same extractor on multiple sub-datasets, especially when they're collecting sensor data.
Design rationale: The "Extractor" is a library of prebuilt data processing tools used on datasets, and this library was called "Analysis" at first. The "Extractor" was originally tied to specific dataset levels, requiring users to choose a target segment of dataset first within the hierarchical structure, then select an extractor at the level to run each time. I redesigned to allow users to select an extractor from any layer before reselecting the target dataset, enabling a more flexible workflow.
Before
After
Insufficient Feedback Loop
The usability problem that the system doesn’t provide enough reactions to users actions, leaving them unsure if they succeeded or what to do next.
2.1 File upload progresses
Usability test result: participants was confused to stay in the file upload popup window until the uploading ends.
Design rationale: I designed the breadcrumb to serve a dual purpose, acting both as a folder hierarchy prompt and as the title for the current page. I enlarged the breadcrumb of the current page to improve its affordance.
Before
After
2.2 Less-efficient prompt of extractor running
Usability test result: participants were confused about staying in the file upload popup window until the extractor finished running.
Design rationale: I designed the running log to immediately redirect users out of the log status once the user starts the running, allowing users to browse other extractors or do anything else while waiting for the log to complete.
Before
After
Poor Understanding
The usability problem that the system fails to clearly explain product-specific terms, leaving users confused about their meaning or usage.
3.1 To explain the "Extraction" feature
Usability test result: participants couldn't tell what an "Extraction" is without explanation, let alone how to use this feature.
Design rationale: I designed to provide a tooltip for first time users to learn the product-specific definition of the "Extraction". I also designed an empty state to guide users on the next steps.
Before
After
Information Prioritization
The usability problem that the system fails to clearly provide or highlight the most important information, making it difficult for users to focus on key tasks or actions.
4.1 Extraction browsing / running
Usability test result: participants found it hard to tell what an extraction is about without using too many clicks to explore.
Design rationale: I designed to keep the extraction list and the detail info of this extraction on the same page. Users only read the details of each extraction while clicking on them to explore, they see the running status while not in the exploring mode. So that users are able to see the most important information in each scenario.
Before
After
4.2 Extraction history
Usability test result: participants couldn't tell what the icons in the first column means, and didn't know the context of that extraction history.
Design rationale: I designed to apply colors and text explanation to the status icons. I also provided context, such as which extractor generated the log on each row, and the object dataset the extractor was applied to.
Before
After
Exploratory Findings and Solution Proposals
Community
Need to establish communities for streamlining data access and sharing with agreeable IRB consents.
Provide visibility control for community members. (Usually researchers won't publish the data to the public until the article publication, while they need to share with co-authors before the publication.)
Offer a place to manage the consent forms. (Readers will need to agree upon certain consents before read shared research data.)
Infrastructures to support collaborations between researchers
A version for non-data-scientists for uploading data only. (The current version is too data heavy, non-data-scientists will have a steep learning curve to use it)
Explain the differences between a "description" and "metadata", so that to help readers learn and dive in the data. (A "description" and a "metadata" describes a research from different levels, the description is a higher level view, while the metadata is a technical depiction of the data itself.)
Handling massive data
Provide a local app to operate local mounted data. (Most users used Clowder as a data storage running in the background. However, since research datasets are usually gigantic, it's easier to run algorithms on large datasets locally.)
Allow further automation for data processing, offer capability to integrate Clowder data with 3rd party APIs. (Clowder extractors are basic data processing algorithms, but research often requires more nuanced data processing that they can't support.)
File findability
Improve data visibility and search-ability, especially for graphic and video data. E.g. provide a tree structure view.
Provide users the control for managing the naming method of files.
Allow users explore / mine / dig in articles in Clowder, since this is the 1st step of the process that a user finds a dataset / extractor, or attach dataset / article in the intro of the extractor.
Extractor findability
Divide these extractors by category, and allow users to browse extractors by category.
Recommend these extractors based on the data type a user uploaded.
My Reflections
IRB application and submission
In academic user testing, IRB approval is essential for publishing research results. I documented the steps and a Q&A guide for the IRB application process in product-oriented user studies.
A lighter qualitative coding method
I tried using Excel to conduct qualitative coding for this study. It's an easier coding method for studies having a small participant pool
Communication about the reasonings
For products where a prototype is already created by developers before a designer is involved, it’s crucial to understand the rationale behind the developers' decisions, to help them understand why the solution could be better.
© Fangyu Zhou 2024 Selection · All Rights Reserved