Socket
Client: Socket
Location: London, UK
Socket were created as an ‘incubator’ platform for a large and established renewable energy provider, who wanted to reach new audiences. Due to the large numbers of competitors with identical services, the product strategy was to reach a much younger demographic, with the aim to secure new target segments.
A mobile-first website which would exist and support client comms within the wider ecosystem. The app would later be integrated with SMART energy meter data.
I joined mid-project as additional support to Marty, as the Team wanted to get ahead for the next few Sprints. My role was to help ideate, and wireframe out the proposed user journey for the ‘logged in’ state of the product experience, which would then go onto design, validation and development.
Details
Duration:
3 Sprints (2 weeks each)
Tools:
Sketch, Invision, Zeplin, Flinto
Industry
Energy
UXD Team
Mark Swanston (Product), Marty Costello (Lead UX), Ola Podgorska (UX), Dave Allen (Design)
The challenge
The business challenge was to make sure customers are aware of when they are on and off track in terms of their payments, as accurately as possible, in simple ‘easy to understand’ terms (eg: relating units of electricity to the average us of electricity of a household item such as a kettle).
Some key points:
- Customer queries (regarding billing) create a high overhead.
- The call centre reported that customers did not understand the correlation between how usage is represented in kWh and how this converts to billing units, especially how seasonal changes affect revenue (eg: winter electricity use increases, which increases the bill a month later, but customers do not always understand this correlation over time).
- The supplier charges a flat fee for the electricity, due to being a regulated service, but services like u-switch have greatly eroded customer loyalty.
At the initial phase of the project we used a white-board to capture all the elements that the “timeline” or “dashboard” of the product would ideally capture or address.
The process
- Sprint 1
Week 1: “Design” sprint
Week 2: Sitemap, wire-framing dashboard - Sprint 2
Week 3: 5 x scenarios – mobile and desktop (pre and on-supply)
Week 4: Full user flow wire-framing based on agreed Scenario(s) for product demo - Sprint 3
Week 5 & 6: Wire-frame changes and specific Sprint tickets (UX cover over Dec)
WEEK 1
Design Sprint
The design spring allowed us to learn about, and get fully immersed in the next phase of the project. We spent time with Andy and Patrick (the Product leads from Socket) defining the purpose of the platform in more detail. We defined the tasks an individual would be able to carry out using the app:
As a customer I would like to…
- Understand my payments (and how they relate to my usage)
- Understand energy usage over time (and how that affects my payments and balance)
- When my next payment is due
- To understand my usage in comparison to others
We then sketched out possible ideas for what would become affectionately known as the “Balancer” part of the platform – some examples of which you can see on the right. A key benefit of working together on this part of the process meant we had direct access to information (eg: billing structure and energy unit calculations), which meant we could ideate using real data.
In detail
Using this interface, someone could physically move the slider across, and see how the increase or decrease in their energy use affects billing (without changing the amount due).
By allowing some freedom of movement, the user would gain a feeling of control, even if this wouldn’t impact the following month’s bill, it would allow them to visualise the direct relationship their energy use has on cost now and in the future.
This idea was not taken through to the next stage, but elements of the timeline were.
In Week 2, I created this diagram, as background technical meetings were held to get an idea of the overall infrastructure and how Socket would integrate with existing systems.
The Socket product consisted of the “Brochureware” or marketing/sales platform, the Community ‘hub’ and the customer portal (“My Account”) . I did a quick sketch from the info received from the Client and the Tech team.
I then produced a Sitemap of the pages we were going to be wire-framing, so we could reach a consensus on which part of the experience would be taken through into prototyping, design and development.
WEEK 2 and 3
Themes and scenarios
From the initial Design Sprint and earlier sessions, some themes emerged that would need to be considered throughout the design process.
These helped us to:
- Keep aligned/focused on what to wireframe
- Begin wire-framing ideas
- Arrive at the ‘use flow’ scenarios for the Dashboard (this was the focus of the next sprints, so we could do a demonstration of one part of the experience).
Themes
-
Timeline (checking past/current/future states of account)
-
Seasonal (price/energy use changes based on seasons)
-
Cause > Effect (topping up/taking out and how this affects the account)
-
Energy of Things (relating units of energy to customers through easy to understand concepts of everyday objects like kettles, heaters etc.
-
Pots (savings/winter pocket/wallet)
- Education (hints and tips, energy education)
Dashboard and balancer scenarios/use flows:
- Pre-supply
- New customer dashboard + “Balancer”
- “Happy path”
- Usage is higher than payment
- Increase in use continues
- Decrease in use
- No payment arrangement set up
- Cancels/pause direct debit, then resumes payments
I’ll go into more detail on these in the next section.
A “Timeline” theme wireframe example.
The Balancer
Based on the Scenarios outlined above, the business challenge was to be able to visualise to Customers who are paying a set amount, why they might need to top up or reduce their spend periodically. This would also have the added benefit of supporting the Customer Service team in communicating any automatic bill adjustments to Customers.
We didn’t want to sacrifice time designing functionality before solving the problem, so we included a very basic visual of a ‘balancer’ on the wireframes at the MVP stage. The aim was to get a user-flow prototyped, and then test with users. Based on user feedback, we could then further iterate and get the right level of detail.
Proto-user journey
Initially, I created a proto-user journey in Sketch. At the end of the Sprint 2, we added in the wireframes to tie this together with the prototype.
WEEK 3-4
Wire-framing the Scenarios
This proto-user journey then informed the user-flow, which helped us get us consensus on which parts of the experience to prototype (From the “Dashboard” to using the “Balancer”, based on the Scenarios).
I then used Sketch to wireframe mobile, desktop and tablet versions of the Scenarios identified, with particular focus given to the user flow – as this was the ‘flow’ that was going to be taken through to design and development for the product demo to the wider team at the end of Sprint 3.
Scenario: Pre-supply
A. Account still being set up, inactive areas shown in grey
B. For time being “Activity summary” is replaced with “Status notifications”
C. Switch takes place (notification “No customer action needed”)
D. Opening meter read (supply start date in X days)
E. On supply (supply start date)
Scenario: New customer dashboard + balancer
A. No past user-data (meter or payments) view
B. Average balance of estimated bill (pre-bill) view
C. Smart Meter readings – billing adjusts automatically after 1 month view
Scenario: “Happy path”
No actions required by customer or Socket
Scenario: Usage is higher than payment
Customer can let Socket adjust payment directly on dashboard, or decide to balance it themselves (using “Balancer”)
Scenario: Increase in use continues
A. Customer has not increased their monthly regular payment, notifications issued
B. Customer has not increased their monthly regular payment, after a [number/type] of notifications, Socket have adjusted the payment.
Scenario: Decrease in use
Credit accumulates, notified to decrease regular monthly payment.
Scenario: No payment arrangement set up
A. No payment set up, get in touch notification
B. Payment has failed, get in touch notification
Scenario: Cancels/pause direct debit, then resumes payments
A. User can pause/cancel their direct debit
B. User can reinstate their monthly payment
WEEK 4-5
User journey wireframes in full
We decided to focus on a the beginning of the customer journey for the Presentation Demo. This was the Pre-Supply to New Customer scenario, including the pre-supply notification journey. I wire-framed the full journey, including the (so far) identified scenarios on mobile.
As we were progressing, I’d upload the wireframes to Zeplin, which allowed Dave (the UI designer) to work in tandem with us, creating a smooth production workflow, through to the Scrum team, who could then create tickets on Jira.
In detail
This is a detailed view of the sign-up process.
Collaborating with Andy and Patrick, we defined the touch-points as to where Socket would be able to communicate with Customers at the beginning phase of the project. This was based on back-end technical, and customer-centre support (CX) constraints.
I wrote the copy in the interim, with the understanding that changes could be made closer to launch.
The user flow in high fidelity
Marty & I then combined our wireframes, and created this high-fidelity version of the proto-user journey.
WEEK 5 – 6
Sprint tickets 613, 1064, 1091, 1110, 1151, 1202
Ticket 613 – The Balancer (part deux)
In the first part of the week, I worked on ‘The Balancer’. Below is the ‘interim’ balancer which I was using on the user flows.
However, having gathered research from the Call Centre, as facilitated by Patrick, we had more detailed information to wireframe with, so I worked across three visual options, checking it across edge case scenarios:
- Developing the ‘bar’ option further
- ‘Energy cycle’ concept from the ideation sessions
- ‘Tetris/Calendar’ time-block option
The assumption we were working with is that the dashboard balancer would show ‘current monthly average use’ until a SMART meter was installed, after which the app would sync up, and show daily balances.
In detail
One item which we wanted to test with users was the ‘topping up’ part of the balancer journey. We couldn’t reach agreement on whether it was better to:
Option A:
Show the ‘top up’ amount changing the monthly payment amount visually or
Option B:
If the monthly payment total should remain static, and if we should only indicate the increase in the ‘top up’ field.
I prototyped this in Flinto so the team could guerilla-test internally, after the Christmas break.
Because the Balancer was related directly to the Statements/Transactions page, I also wire-framed this page.
SPRINT TICKETS 1064, 1091, 1110, 1151, 1202
This was during the December holidays, so I was also covering for Marty, and handled a few other sprint tickets as they came up, namely:
- 1064 – Logged in and out menu states for different user types
- 1091 – Topping up/Verifone payment user journey
- 1110 – Responsive ‘logo gallery’ panel with bullets
- 1151 – Emergency contacts page
- 1202 – Contact preferences “none selected” feedback states
Ticket 1151
The Emergency numbers needed to be easily accessible and very visible. Supporting content was also necessary, but it was important it didn’t detract from the emergency contact details.
I had a look at three different options, looking at the pros/cons of each. The progressive reveal (Option 3) allowed for the most important content to be seen immediately, didn’t overwhelm the user. The Open/Close trays would then allow users to investigate further if supplementary information was required.
Ticket 1202
I worked through the action/feedback states for the ‘no contact preferences selected’ scenario on the Settings section of the site. Due to technical constraints, this was then prioritised into a later Sprint.
Ticket 1064
The logged in/logged out states for existing and potential customers.
Ticket 1091
The process of topping up (adding money to one’s account, to prevent monthly charge increases), including the redirect to the payment platform.
Ticket 1110
This had to include bullet points which would sit with the logo(s), across the responsive grid.
I finished the project by attending the Sprint Review remotely, held in Nottingham on the 17.12.2019. Some of the work (sitemap & ticket 1064) was included in the demo.
The project was cancelled in early January.
My thoughts about why the project was cancelled
During the course of the project, I also informally gathered user-feedback about the energy use habits of friends and colleagues, so I could verify if the business assumptions were correct around the user challenges. After having asked approximately five individuals, a pattern emerged: the challenge for customers was switching energy suppliers, as the data was not shared between competing suppliers, quickly or easily.
From the business perspective, it was also an issue, as switching suppliers contributed to a large percentage of call-centre contacts, and this was very costly for Socket.
The real challenge was a more fundamental one to solve – looking at the source:
- Connecting up customer data between suppliers – sharing it quickly and easily so when a switch occurs, so there is little delay (this can take anything from 2 days to 3 weeks in the current state)
- This has implications on security, as sharing customer data between providers is not possible in the current state
- It would also mean a wider technical infrastructure project which would be costly
- Due to evolution of metering, individuals can now literally see their daily spend, so it’s no longer the biggest ‘problem’ to solve for customers from a CX perspective.
- The ‘environmental’ and ‘sustainable’ aspects of energy supply could be given more focus within the product. Educating consumers about how their energy use affects the energy grid, and the planet etc, as the target segment that Socket were keen on capturing showed interest and concern about these issues.