I participated in a one-week design sprint at IDEO CoLab with a multidiciplinary team of experts in renewable energy and designers. We rapid prototyped and conceptualized GreenMe–an electricity supplier switching service dedicated to building 100% renewable energy communities in deregulated energy markets.
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.
Key adoption blockers and barriers were addressed and presented to Cisco. Improvements to the software application are currently being shipped.
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?
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
Recruit and Usability-Test
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.
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:
Ease of use
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
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.
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.
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.
introduction to left-hand panel
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
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
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.
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.