top of page
backsplash.png

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.

Brief

Build a system that automates the process of commercial customer switching to an energy provider that works better for them–potentially just once, but more likely, multiple times in the same year or month.

Tools

Sketch, Adobe XD

Skills

Rapid Prototyping, Research, Ideation, Team Collaboration

Team

Corie Smith, Sr. IT Manager–Duke Energy Corporation |

Derek Thorn, Sr. UX Designer–Principal Financial Group |

Anthony Coleman, Digital Portfolio Manager–

Alabama Power |

Joe Fodera, Research Operations Manager–Ford Motor Company

Lenght

1 week

Challenge

In deregulated markets, consumers (both commercial and homeowners) have the power to choose what kind of energy they want–and providers can compete on things like price and energy source. However very few consumers do switch–because switching tends to seem painful, manual and complex.

How might we enable people in deregulated energy markets to quickly and easily switch providers based on criteria that matter to them?

Things to consider:

  • How might this be part of a larger circular economy?

  • Is the only value to deliver back to the consumer the price?

  • A system that is turnkey and simple rather than manual and complex.

Process of the Design Sprint

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.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.

bottom of page