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.
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.
Sketch, Adobe XD
Rapid Prototyping, Research, Ideation, Team Collaboration
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
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
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.