top of page
backsplash - no logo.png

Cisco’s WebEx Teams, one of Ford’s key collaboration tools, has been globally adopted at Ford, except for Palo Alto.

I led a qualitative usability study with Ford Palo Alto workers, ranging from a variety of experience and exposure levels to the tool. 

My Role

As a contractor UX Designer to Ford, I thoroughly analyzed and usability tested Cisco’s WebEx Teams, one of Ford’s key partners and collaboration tools.

Provided a liaison between Cisco’s design team and the digital collaboration needs of Ford Palo Alto users.

Results

Key adoption blockers and barriers were addressed and presented to Cisco. Improvements to the software application are currently being shipped.

Challenge

WebEx Teams has been globally adopted at Ford except for Palo Alto workers.

Given that WebEx Teams is a new collaboration tool at Ford Greenfield Labs in Palo Alto, Ford and Cisco wanted to know, what are the tool’s pain points and top opportunities for adoption?

Approach

1. Based on research, develop a WebEx Teams user experience map that communicates:

  • How Palo Alto Ford employees currently use Webex Teams

  • Pain-points and blockers that users stumble upon while using Webex Teams

  • Opportunities for improvement and implementation based off of user pain-points

2. Design user-flows that highlight blockers and improvement opportunities

3. Provide Cisco’s design team with on-the-go expert reviews of new features before launch  

Research Process

research process.png

Recruit and Usability-Test

survey screener

Screening Participants 

I initially hypothesized that two factors would highly influence the tool’s usability:

1. Engagement frequency - the higher the engagement with the tool, the higher the usability score, and vice versa.

2. Job roles of employees - by request of Ford, I made use of Ford Worker Archetypes describing workers, done by a previous research consulting group.

After recruiting participants, I categorized them into the two groups.

Usability Testing

Out of the 14 qualitative testing sessions,

4 participants were frequent users of WebExTeams and 10 were non-engaged users.

Participants completed various collaboration-related tasks using the tool’s most prominent desktop app features.

pic.png

Collaboration-related tasks that participants conducted measured:

  • Fail/success rate

  • Ease of use

  • Emotion/reaction

Most features scored low in usability.

Analyze and Synthesize

Analyze and Synthesize - zoomed in.png
light bulb.png

As I analyzed the data from the testing sessions, I disproved the first part of my hypothesis - Engagement frequency with the tool did not influence its usability.

Instead, regardless of tool engagement frequency, low usability scoring was linked to:

  • Low feature exploration (determined by the worker’s purpose for using the tool) Ex. a frequent user could be less proficient with the tool if their job role didn’t require much exploration of its features, whereas a less frequent user could have higher proficiency if their job role required more exploration of features.

  • Poor user interface

  • Higher experience and familiarity with other widely adopted collaboration tools

I made the decision to discard user engagement with the tool from further pain point and opportunity analysis.

Visualize and Communicate

Experience Mapping

Given that WebEx Team’s user journey is non-linear, I created an experience map in such a way that each feature was represented individually.

archetypes.png
light bulb.png

Upon pain-point and opportunity mapping, I disproved the second part of my hypothesis. The job roles represented in the Ford Worker Archetypes didn’t influence users’ tool experience, as they were general to the enterprise and not specific to Palo Alto workers.

However, I kept the archetypes as part of the map’s storytelling to explain my decision to stake holders to not use them.

Top Findings

blockers - barriers - adopt.png

As a  liaison between Cisco’s design team and the digital collaboration needs of Ford Palo Alto users, I made a call-to-action to Cisco to improve key features preventing adoption of WebEx Teams.

I turned my insights into user-flow visualizations of opportunities for improvement to highlight top adoption blockers and barriers—onboarding and learning/navigating workspaces.

Onboarding

Adoption Blocker

WebEx Teams’ onboarding misses the opportunity to teach new users how to perform key and simple commands as part of the initial walk-through (ex. create/join your first team, create/join your first space).

I analyzed WebEx Team’s, compared it to its main competitor, Slack, and prototyped features that helped users familiarize with the tool’s features through “learning by doing”.

quote.png

Too many pop-ups that I don’t really care for. Would rather have examples of doing stuff.

opportunity

implementation

introduction to left-hand panel

opportunity

implementation

introduction to "Create a Space"

The results of the usability study research and its prototypes influenced Cisco to implement the opportunities identified into current versions of the tool.

Learning & Navigating Workspaces

Adoption Blocker

The tool’s workspace information architecture model was hard to learn and navigate:

  • “Teams” and “Space” workspaces paradigm was confusing

  • Lacked ability to create “formal” and “informal” conversations

  • Visually difficult to distinguish between 1-1 vs. group conversations

  • Options for creating and managing workspaces were undiscoverable

workspace information architecture

opportunity for create a space

search bar flow

opportunity for

conversation panel hierarchy 

I compared the tool’s information architecture against its competitor to call attention to its workspace navigation problem, and pointed to new opportunities. 

I also called attention to other high priority usability issues that will impact Ford employees' adoption and ability to effectively use the tool, and pointed to new opportunities. 

Learnings

Academic and internship experience aside, consulting for Ford as a sole UX researcher and designer without a team came with first-time challenges.

I am the expert, not the client

At the beginning of the project, Ford stakeholders made the request to categorize participants into pre-existing Ford worker archetypes. I proposed to not use these archetypes, given that they could lead to assumptions of user goals and intentions, however my proposal got dismissed.

With the help of an incoming senior researcher to the team, we later confirmed that, as I had hypothesized, the archetypes didn’t influence the tool’s experience, as they were general to the enterprise and not specific to Palo Alto workers. I learned the valuable lesson to never let my junior experience be an inhibiting factor in speaking against a client’s request if I deem it invalid, as I am the one who holds the skill expertise, not the client.

infotainment v2.png

Previous case-study - Product design (NDA)

Re-designed a touchscreen infotainment system interaction model from the ground up

HP.png

Next case-study - Strategy (NDA)

Led research and strategy efforts in future-casting "where to play" concepts of next generation PCs for an influential tech player

bottom of page