Throughout my career, I’ve designed and collaborated with Ford Motor Company, IDEO CoLab, Lucid Motors, The Art of Living Foundation, LIM Innovations, Fundación Tarahumara José A. Llaguno; currently volunteering at Inneract Project.
I’m currently looking for opportunities in Social Impact Design. If your team strives to work with organizations to help build ethically responsible solutions with communities through design strategy, I’d love to collaborate with you.
An Interaction Designer, Design Researcher, and Strategist.
An Interaction Designer, Design Researcher, and Strategist.
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
Recruit and Usability-Test
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.
Collaboration-related tasks that participants conducted measured:
-
Fail/success rate
-
Ease of use
-
Emotion/reaction
Most features scored low in usability.
 |
|---|
 |
Analyze and Synthesize
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.
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
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”.
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.
