Nick Bewley's Website

Business Problem:

VMware provides tools enabling Systems Administrators to manage IT infrastructure. Often, users will need to initiate extensive system processes that take a long time to complete. For example, after clicking to initiate a data center, it could take 20 minutes to an hour for the operation to complete. The Long Running Operation component provides the user the operation's status and actions, while providing the user the ability to browse the interface and accomplish ancillary tasks.

Process:

Background This project arose from the need to create a consistent, unified notifications system in VMware Cloud Services. As different products onboarded to the new platform, each product was addressing notifications in drastically different ways, creating a disjointed, confusing notifications experience.

Step 1: Problem Definition After teasing apart the scenarios within which VMware notifies its users, I interfaced cross-functionally to define high-level buckets for the different notifications. One type of notification distinguished itself as high-priority in a large number of instances across the platform: long-running operations. In these cases, the user will have initiated a system process that could last up to an hour. The user may want to continue browsing the platform to accomplish other tasks, further, and may want to be informed of the task's status in those subsequent views. Defining these points cross-functionally in the research phase informed the design solution we ideated around in Step 2.

To support an understanding of the current problems users were encountering, I created a journey map illustrating some of the gaps that existed in current products. This document, along with first hand customer research, helped define requirements to include in the final product.

Step 2: Ideate I mapped out flow diagrams illustrating how to accommodate—both in-app and offscreen—workflows to enable a good user experience within these scenarios. As the flow diagrams became more refined, I spec'd the specifics of the interaction design in different contexts, which you'll find below.

Step 3: Refine With the basic interaction in place, I moved into refining the visual and interaction details: tweaking the color palette to meet AAA accessibility standards, for example. The component's interaction at scale was defined, as well, along with the specific details of the interaction: the length of time in which it animates from state A to B, the animation curve, etc.. I worked in Framer to create the specifics of the various states, and the final deliverable was a working prototype and supporting documentation describing the long-running operation component.

Step 4: Edge Cases After defining the base component and its various states, I began to consider the different cases in which a user will encounter this component. What if a user initiated two long running operations at the same instant, for example? Or, what if the operation times out, or encounters a server error? I moved forward and addressed all edge cases, incorporating engineering feedback to help define implementation gaps.

The interaction diagram below outlines the different cases covered in the Long Running Operations design. The user can hide the widget or the cancel the operation as they browse the interface to accomplish further tasks. Further, if the user wants to leave their computer while the operation runs, the workflow supports that use case. If the operation fails after the user closes their browser, therefore, we send an email to inform the user that the task has failed in order to inform the user should that task prove perilous to their deployment.

Step 5: Next Steps Currently, as part of the broader notifications design, I'm working to integrate the long-running operation component into the larger notifications design strategy.

Results:

The design component is being integrated for release as a component in the Clarity Design System. I look forward to seeing how different products utilize the Long Running Operation Component, and to iterating towards improving it! Long Running Operation Final Design

Business Problem:

WiFi administrators monitor deployments across many different geographical locations. For example, imagine the workday of one of our customers, Brad, Network Administrator at Chic-Fil-A. Brad's job depends on insuring the wireless network at any one of many Chic-Fil-A locations, insuring that all maintain sufficient internet access simultaneously. Brad would love to have a unified, centralized view of his entire network behind a single "pane of glass."

Process:

Step 1: Understand Our Users The first step I took when tasked with the Health View was to gain greater understanding of our end users. I led the team in crafting some traditional ux deliverables: crafting empathy maps, user scenarios, and fleshing out personas. We took it a few steps further, however, traveling on a week-long customer visit to interview customers and determine pain points with our current software. The in-person interviews were valuable, giving us first-hand accounts of user scenarios and pain points in current implementations.

Step 2: Ideate Our initial research allowed us to align around a key goal: creating a single interface to diagnose and remediate network problems. After gaining alignment on the goals of the project, I developed low-fidelity sketches and wireframes to demonstrate big picture navigational ideas. As you see in the sketches below, different types of views were explored. After interfacing with users and stakeholders, the map-based approach proved to be the most promising in context of our users' deployments.

Step 3: Prototype, Test, and Refine Often the most enjoyable part of the process, we began prototyping early. I started with creating high-level navigational elements and connecting them to illustrate user flows. We created some simple prototypes and tested them with our users, culling learnings that we baked back into the final solution through contextual inquiry techniques. Here is a clip of one user working through an early version of the interface:

Step 4: Visual and Interaction Details Throughout the process, we were constantly trying new visual and interaction design paradigms. I worked closely with the visual designers, and my background in Visual Design helped to guide them towards a cohesive design language. I prototyped detailed micro-interactions, as well, testing ways to improve ease of use through advanced user interaction. Prototyping in front-end languages (html, css, and js), eased implementation on the development side, and our developers really appreciated the help ;)

Results:

Overall, the project has been well received! Our users have appreciated the attempt to structure the interface towards guided workflows:

Business Problem:

Finding quality, cheap, high-end reused goods nearby provides value to savings-conscious buyers. Symplyst aims to provide a convenient interface within which buyers and sellers can communicate easily and safely.

Process:

Step 1: Define the Users Operating under a startup budget, I was tasked with gaining learnings as quickly as possible. I worked with Product Managers to define our personas: cash-strapped, tech savvy youth who want to find quality goods at a bargain.

Step 2: Test Lo-Fidelity Prototypes I led guerrilla usability studies to determine whether the high-level information architecture was effective. The navigation of the app is anchored in the top and bottom navigational bars. After testing 20 users representing a cross-section of our persona, we had enough data to validate the navigation architecture. We implemented the navigation, then moved on to refining the visual design language and interaction paradigms.

Step 3: Create Visual Design Language After defining the structure of the app, I moved on to creating a consistent visual design language. I created a typographic structure reflecting the hierarchy of the app, and a restrained color scheme to draw attention to the action buttons.

Step 4: Hi-Fidelity Prototyping and Micro-Interactions With the structure of the app in place, I designed transitions and micro-interactions to delight users as they perform complex tasks. Here are some of the final interaction designs:

Results:

Unfortunately, the startup was unsuccessful. However, the experience of working in a startup environment was extremely valuable.

Business Problem:

Students depend on standardized tests to advance their education, and we were tasked with creating the interface to make testing as seamless as possible. Students need to find test centers, schedule appointments, and view prior test results.

Process:

Step 1: Define the Users The first step to take in this project was to engender empathy with our users. Students have a lot to balance between school, after-school work, social lives and extra-curricular activities, among others. I wanted to make sure that our interface made their lives easier and spoke to them in a design language they could relate to. I worked with cross-functional teams to create these personas:

Step 2: Ideate Great, now we know who our design is speaking to. Let's think about some of the most common use cases for those users: finding a place to take a test, booking a test at that location, and viewing past tests are some of the most important. We developed workflow diagrams and wireframes for all key use cases, and then built around the base. Building around the "finding a place to take a test" scenario, I was able to apply the search interaction / workflow I designed there for adjacent use cases. Here are wireframes I designed to address an adjacent search scenario: as a teacher, I want to find and view my students' test results.

Step 3: Design Language Cool! Now we have some intuitive workflows. The next step is to craft a design language that speaks to our users. Education connotes many adjectives, yet we settled on a few to use when defining this interface: fun, yet formal. To craft the design language, I start with the building blocks then build out from there. Specifically, I start by applying color, typography, and imagery to previously conceived workflows.

Results:

A success! Prior to our project, ETS was a stale brand that didn't connect with the user base. The prevalence of Helvetica and stock photography gave the web experience an institutional feel, a feel that students couldn't connect with. Our project was so successful that the company decided to expand this sub-brand's experience to other sub-brands.

CASE STUDIES

Resumé