UX Case Study: Designing a Productivity Application

Arif Kabir
13 min readSep 20, 2019

Project Overview

Spaces is a productivity tool designed to make it easy to manage information for different projects and collaborate with others. With Spaces everything about a project — files, browser tabs, third-party applications and more — can be organized on one screen. No matter where your project information resides, Spaces affords you both a glanceable and an in-depth look at it. It is a flexible tool that effectively relieves the mental load of personal and collaborative project management.

I worked with a team of two students and took lead on the product design and roadmap. I also played a significant role in designing the high-fidelity screens for key features such as app organization, work management, and adding new integrations.

See the final design iteration and deliverables at the end of the case study.

Project Details

  • Type: Classwork project for the Interaction Design Studio class at the University of Maryland, College Park
  • Duration: 15 weeks, concluded in May 2019
  • Deliverable: High-fidelity interactive prototype demonstrating key functionality
  • My Role: Product Manager & UX Designer
  • Tools: Contextual Inquiry, Guerrilla Interviews, Affinity Diagramming, Sketching, Figma, and Sketch

Objectives

  1. Create an experience which makes it easier to start new work or continue existing work.
  2. Help users organize information and resources around a project in a quick and easily understandable manner.

Motivation

How can we make it easier for people to start working? As graduate students working on multiple projects, we all agreed from personal experience that working on a new project or switching between projects was difficult because of the amount of time it took us to switch from one project or workflow to another. Additionally, every hurdle encountered in the process presented an opportunity for distraction and delays. To work on a project that would benefit us as well, we attempted to tackle this problem by creating a better experience for users to start working quickly and then to continue working.

Process

We followed a user-centered design process with a focus on qualitative data collection and analysis to extract rich design insights. Specifically, we used Contextual Inquiry, Affinity Diagramming and Empathy Mapping to capture insight about users’ work performance and what factors impacted it. We condensed our insights in design goals and followed a rigorous design and feedback cycle to create a tangible user-experience which could support a diverse range of projects for the end-users. Each iteration was validated and improved on by user-testing and in-class critiques from our peers and professor. Our process steps were as follows:

Research

Our main research goal was to understand how people currently worked on their projects and what factors aided or hindered their work performance. We also wanted to validate this problem space by discovering other products which attempted to tackle the same problem and learn from their design decisions. To this end, we first conducted user-interviews to understand users’ work patterns, and then competitively analyzed 3 products.

User Interviews

We interviewed 5 participants who were a mix of graduate students at the University of Maryland and working professionals in the Washington D.C. area. We selected them because they were working on multiple different projects (school work, graphic design, academic research etc.) for their personal and professional work. The interviews were structured to observe their process of working on and switching between their work tasks on their computers.

We started the interview by retrospectively questioning them about their recent work and then observed the participants as they started to work on a task of their choosing. Later, we asked them to switch to a different task and observed how they did it. We also asked them the following questions:

  • Overall, how easy is it usually for you to get started?
  • Are you feeling comfortable when working under your own setup?
  • Do you open files or applications for different tasks on your computer? Why (or why not)?
  • Why do/don’t you close applications while switching tasks?
  • When you are working with your computer, can you highly concentrate on your work?
  • How do you arrange your resources for different tasks? Why do you do so?

Additionally, the “Think Aloud” contextual inquiry approach was used so that we can keep track of what the interviewees are really feeling when doing the task.

Competitive Analysis

In addition to our user research, we also looked into what products were already available on the market to see current efforts to address this problem, as well as to determine if there was a need and a niche that we could fulfill. We came across three products with similar functionality:

  1. Toby for Chrome: A Chrome extension that organizes bookmarks by into collections
  2. Workspace Pro: A macOS-specific application to launch and close multiple macOS applications with just one click
  3. Workspaces by Apptorium: A macOS-specific application to organize and quickly open important documents, websites, folders, apps, e-mails by project

We found that the initial premise of organizing project resources and quickly opening them were answered in some fashion by these applications. However, we found some affordances that were not being fulfilled by these products:

  1. We did not find these products to have any functionality to collaborate and share project resources with other collaborators, even for them to only receive web links, or to see what might be in someone’s project.
  2. We did not see any functionality to also be able to open or close all project-related resources with the click of one button.
  3. We did not find any affordances that would allow users to interact with any services or web applications they might be using for their project.
  4. We did not see any metrics corresponding to the usage of these apps, including time tracking to see how much time was actually spent on these projects.

The competitive analysis helped us to confirm that there was a need in the market for a product that organizes project resources and tools, and also provided insight into what affordances we should focus on for our project.

Analysis

We combined our interview notes to create an Affinity Diagram and an Empathy Map. We got a lot of insights from the study. Interviewees are quite different in working habits. Some of them like to organize and set everything before work, while others don’t even know where their files are stored. However, aside from the divergent insights about work patterns, we soon found insights that were common across our participants. These are shown by the “Motivations & De-Motivations” and “Organization of Information” themes in the Affinity diagram below.

The Empathy Map further refined this insight with concise user quotes and helped us choose impactful design goals for our project.

Design & Iteration

Based on our findings thus far, we arrived at a crossroads based on our two main user findings that users wanted to be motivated and also wanted to organize their information: should our app primarily focus on motivating users to get started and to organize their projects and associated artifacts, or should we focus on helping them organize their projects so that they felt motivated to work?

While these goals aren’t mutually exclusive and sound quite similar, they could potentially lead to two very different products. The former would focus on on-screen techniques that would motivate users to work on their projects, such as reminders to work, blocking certain websites and apps at a certain time, etc. The latter would focus on an interface that primarily focused on organizing artifacts, while also inherently including incentives to be motivated to start because of the ease of getting started. After much deliberation and another round of user feedback, we decided to focus on the latter, to focus on helping our users organize information so that they felt motivated to work.

Design Goals

We decided to focus on the following design goals:

  • Help users organize information on their projects effectively
  • Prevent users from losing information while working
  • Prevent users from getting overwhelmed with too much information
  • Provide shortcuts to access necessary temporary information

Initial Concept

We created some sketches individually, from very rough idea of “crazy 8’s” to a more detailed product proposals. All these designs were aligned with the 4 design goals stated before. Our idea was to create an interface that integrates all resources needed for a project automatically or manually, and keeps everything updated without losing information. Since we had different understandings of what are the required resources for a project and what information should be saved, we created very different sketches. After a discussion, we agreed to create a browser-based extension focused on managing a few critical aspects of a project.

Iteration 1 of 4 (Browser Extension Sketches)

We started from the idea of a browser extension that would help users manage their projects and online resources. We chose the browser because our user research pointed to it being an important tool in the workflows of all our users and the main source of gathering information from the internet. We were inspired by one of the products we had come across in our competitive analysis, a Chrome extension called Toby, which is a tool for organizing bookmarks into “collections”. A collection in Toby is just a group of URLs, but we thought a project could mean more than this.

We intended to create a browser extension which would aid project management by showing information related to a project at-a-glance. Essentially, the tool would allow the users to create new projects, select the project they were working on, and automatically remember information about the selected project. We designed the prototype to accommodate the following types of information regarding a project:

  • Tabs or URLs
  • Notes
  • Calendar
  • Contacts
  • Upcoming events

Based on the idea, we created our first testable prototype with simple sketches by pen and paper. We also had some questions to be answered through user testing, like:

  • Should a project be exclusive? (Is it possible to work on different projects at the same time?)
  • What context should be automatically saved? For example, is it better to save all open tabs or just the ones the user specified?
  • Are there other elements needed as a project management tool?
Iteration 1 Wireframes

Iteration 2 of 4 (Revised Wireframes)

After getting feedback with the paper prototype, we quickly started with an interactive prototype (with relatively low fidelity) for tests in the next steps. We broadened our scope from a Chrome extension to a larger cross-platform application, and developed a workflow for user testing with this prototype.

Our first idea about the MVP included the following features:

  • Create a (work) “project”.
  • Associate any open applications, files, folders, and browser tabs with a project.
  • Resume a project with one button press. This will open all applications, files, and browser tabs associated with the project and arrange them in the last observed configuration.
  • View persistent project information while working on the project.
  • Close a project with one button press. This will close all open applications, files and browser tabs associated with the project.
Iteration 2 Wireframes

We tested this prototype with our peers in class. The subjects were asked to use this product to start their own project as well as comment on the overall experience. These tests are also done in a “Think Aloud” approach as the previous research.

Feedback

We got some insights about both the high-level structure and design details for the product.

  • Users don’t read the instructions or add a project description when set up a project.
  • Setting up a project totally automatically is not preferable. Users need control over the project.
  • A hierarchical display of items in a project is clearer and less overwhelming compared to long lists.

This feedback session also inspired to clarify what our product should actually do. In the discussion, we drew a quadrant map on the blackboard to divide the potential resources or items in a project into 4 categories based on 2 criteria: whether it is open and whether it is included in the project:

  • “P” for opened items within the project
  • “O” for opened items outside the project
  • “B” for closed items within the project (bookmarks)
  • “X” for closed items outside the project

Our initial idea was to let the application takes over the whole computer so that every “O” will be automatically added to the project and converted to “P” as long as the project is running. However, in the usability test we found that users actually need more control over the project. We thought manual settings were evil, but they are necessary. Taking this into consideration, we abandoned the idea of setting up everything automatically. Opened items will not be forced to be included in the project, and users are not limited to run only one project at one time. We planned to make a product that displays the resources properly and provides utilities for project management, such as time tracking and collaboration.

We also talked about the name, and decided to use “Spaces” instead of “InContext”, since we are creating a highly flexible platform for project resource management rather than a tool simply for saving and resuming contextual information passively.

Iteration 3 of 4 (Phase 1 Deliverable)

From previous feedback we had understood that our design should empower the user and allow highly flexible project and resource management capabilities. To expand on both these fronts, we started developing the idea of integrations. Integrations were essentially be widgets from different web services, applications and more that would live inside a project offering glanceable information and their own unique functionalities. This would transform the project space from a collection of resources to an information hub where the user could see information from an arbitrary number of sources of their choosing.

We also thought about how users could use Spaces to collaborate on projects. To enable this, we designed a way for users to share their project space with other users, either one space at a time, or the entire project.

With the possibility for an endless number of spaces in a project, we also redesigned the project page to be more space efficient to maximize the information available on-screen while maintaining glanceability with increased and arbitrary number of spaces.

Iteration 3 Wireframes

Feedback

We tested these changes with our classmates again, and also received critique during our in-class presentation. Generally the changes were well received. Everyone liked the idea of integrations but were curious about how users would discover and add them to a project. Furthermore, users were confused about some of the signifiers around a space, for example: we had similar signifiers for open an expanded view of the space and open the space in a browser. Users also expressed interest in the ability to search for content within and across spaces.

Final Iteration

For the final iteration our main goal was to add power and versatility to integrations. To this end, we added the ability to expand a space, recreating the effect of using it in a full-screen browser, rather than a compressed widget. We designed a new time tracking dashboard and a Trello board as examples to showcase this functionality. We also added search capabilities with based on the feedback received in the previous iterations.

We also made our on-boarding more intuitive by adding graphics to explain how Spaces can benefit the user and adding the sidebar to bring the design in line with the rest of the application.

Lastly, we updated our visual design to be more open and productivity focused by switching our color palette to a simple white with blue accents. This combined with our existing design gave the entire application a modern and polished look.

There were numerous other changes which are summarized below:

New abilities

  1. Add the ability to search to find relevant spaces and resources
  2. Add the ability to collaborate and add others to spaces and projects
  3. Add the ability to open and close all project resources. Make it clear to the user through a success message that all resources were opened/closed
  4. Add the ability to switch between projects
  5. Show how it would look if someone wanted to see more details for a space
  6. Add the ability to sign in not only with email and password, but with other SSO options such as Facebook, Google, and LinkedIn
  7. Add the ability to add applications (not just browser tabs and files) to a space
  8. Show the profile picture of the current user to signify who is using the application and also ways to modify the profile and to log out

Enhancements

  1. Change the welcome screen from text to a visual graphics that explain the concept of the app better
  2. Show projects of varying complexity because not every user will be a power user, and new users could get overwhelmed by too much going on
  3. Show more activity based workflows
  4. Remove all placeholder text
  5. Update nomenclature to be clearer (e.g. “tabs” instead of “browser tabs”)
  6. Update the time tracking space to show higher fidelity of details
  7. Update the UI to be cleaner and more consistent

The interactive prototype can be found here.

Conclusion

This project has proved to be a robust exercise in product design. Navigating it from the broad idea of reducing the barrier to work to creating the unique project and information management capabilities was possible due to the interactive user-centered design process. Furthermore, the team and I were constantly looking for feedback from our peers in class to guerrilla interviews conducted during the design phase.

My key takeaway from this project was the importance of not relying too much on the initial user research, and instead, conducting interviews even after entering the design phase to ensure that the product actually solves the problem we were targeting.

--

--