Huang,Tien-Han 


Case Study - Enpal Customer Portal

Reducing homeowner anxiety during the solar installation journey

Project Overview

  • Role: Product Designer (UI/UX)
  • Timeline: Design Challenge (e.g., 4 Days)
  • Tools: Figma, AI (Midjourney/Google AI for concepting)
  • Platform: Responsive Web App (Mobile-First Approach)

Enpal customers pay thousands of euros for a solar installation — then wait months with almost no visibility into what happens next. In this self-contained design challenge, I designed a mobile-first portal concept built around one insight: the anxiety isn't about solar panels, it's about uncertainty. The result is a status-first tracking experience with a validation plan for how I'd test its core assumptions with real users.

The Problem

Between signing a contract and seeing panels on their roof, an Enpal customer goes through a long, opaque process: site checks, permits, scheduling, installation, grid connection. During this time, they've already committed a significant amount of money — and they hear almost nothing.

That silence has a cost on both sides. For customers, it creates anxiety: Did something go wrong? When will this actually happen? Who is coming to my house? For Enpal, that anxiety turns into repetitive inbound support calls, all asking variations of the same question: "Where is my installation?"

The design question: how might a customer portal replace that uncertainty with a sense of visibility and control — and reduce the support load in the process?

Constrain & Assumption 


This was a 4-day challenge without access to Enpal's customers, support data, or internal teams. I want to be transparent about what informed the design instead:

What I worked from:

  • Enpal's public website and customer journey, mapped end to end
  • Comparable "waiting experiences" that handle uncertainty well — parcel tracking, food delivery apps, and service-appointment products — to understand which patterns users already trust
  • Publicly available customer reviews, to identify recurring frustration themes

My working assumptions:

  1. The primary anxiety driver is uncertainty about timing, not technical questions about the hardware.
  2. Most support calls during the waiting phase are status requests that a self-service view could answer.
  3. Installation day is the highest-stakes moment emotionally — a stranger entering your home for a major intervention.

These are assumptions, not findings. In a real engagement, validating them would be step one — I outline how in the final section.

Ideation


The goal was to design a responsive interface, so I decided to design for both desktop and mobile to ensure the design works on both device types.

Key Design Decisions



Decision 1 — Status-first hierarchy

Problem: Users open this app with exactly one question: "Where is my installation right now?"

Decision: The current status owns the first screen. Everything else — documents, contact, FAQs — is secondary navigation.

Reasoning: Customers already have a mental model for this from parcel tracking: open app, see status, close app, feel reassured. Fighting that model with a dashboard of equal-weight features would bury the one answer people came for.



Decision 2 — Context-aware timeline with site-readiness alerts

Problem: A static progress bar tells you where you are, but not why you're stuck or what happens next. Passive waiting feels worse than active waiting.

Decision: The timeline shows each phase with three layers of context: what's happening now, what's blocking the next step, and — critically — what the customer themselves can do (e.g., "Clear access to your fuse box before the site check").

Reasoning: Perceived control reduces anxiety more effectively than raw information. Giving customers a task, even a small one, converts them from passive waiters into participants — and prevents avoidable delays on Enpal's side.

What I'd Validate First

The impact of this concept is hypothetical until tested. Here's how I'd turn each claim into evidence:

Hypothesis 1: The status-first view reduces "where is my installation?" support tickets.
Measure: Support ticket volume tagged by topic, compared before and after launch.

Hypothesis 2: The installer trust module improves installation-day satisfaction and reduces rescheduling.
Measure: Post-visit CSAT and reschedule/no-show rates.

Hypothesis 3 (riskiest assumption): Timing uncertainty — not cost or technical doubt — is the dominant anxiety during the waiting phase.
Test first: Interviews with customers currently mid-process, plus a review of actual support transcripts. If this assumption is wrong, the entire information hierarchy needs rethinking — which is exactly why it would be validated before anything ships.
What I'd Do With More Time

Four days forces prioritization. What got cut, deliberately:
  • Edge cases: delays, failed inspections, permit rejections — the moments where communication matters most and where this concept is currently weakest.
  • Post-installation experience: monitoring energy production, the handover from "waiting customer" to "active user."
  • Accessibility audit: the concept follows WCAG-informed patterns, but a proper contrast and screen-reader review wasn't in scope.

What I learned: My instinct was to design more features. The most valuable hours were spent doing the opposite — cutting everything that didn't answer "where is my installation?" The discipline of a single organizing question turned out to be the design.