My Framer Site

Eva Mary Arun | Product Owner

Works

About

Resume

Eva Mary Arun

What We Learned: The manual sign-in process was tedious and repetitive.
What We Did: Introduced Single Sign-On (SSO) for a seamless login experience.
What We Learned: Wellington users needed daily exports to excel of service requests.
What We Did: Added two list views, including one with all columns and direct Excel export functionality.
What We Learned: Users couldn’t tell when filters were applied or when SRs were on hold.
What We Did: Added a filter icon and introduced an “On Hold” status column for clarity.
What We Learned: SR Group and Type fields needed to update dynamically.
What We Did: Implemented lookup fields that update based on selection. Required custom Power Pages logic.
What We Learned: Date selection allowed backdating, and time fields were unnecessary except for disconnections.
What We Did: Restricted date selection to future dates and made time fields conditional on the Disconnection SR Type.
What We Learned: Users wanted to upload attachments directly instead of emailing them.
What We Did: Enabled direct file uploads. This feature is missing from the current system.
What We Learned: There were risks of human error with status updates, no way to track history, and too clicks to mark ICP's as created.
What We Did:
- Added validation to prevent skipping status stages
- Introduced an “ICP Created” button to streamline actions
- Built an activity log that tracks status changes, user actions, and timestamps, with optional notes.
What We Learned: Users needed a better way to flag and track SRs by status.
What We Did: Implemented a flag-and-status system for clearer tracking and prioritisation.
What We Learned: Only certain user groups should be allowed to update statuses.
What We Did: Restricted status changes to Wellington Electricity and contractor roles to reduce errors.

Redesigning Service Requests portal to improve usability, reduce cybersecurity risks, and streamline maintenance workflows.

Redesigning Service Requests for Faster, Smarter Workflows

What We Learned: The manual sign-in process was tedious and repetitive.
What We Did: Introduced Single Sign-On (SSO) for a seamless login experience.
What We Learned: Different user groups needed personalised dashboard views.
What We Did: Created distinct dashboard. Retailers only see their own SRs, and contractors only view assigned requests.
What We Learned: Users wanted high-level statistics available on the homepage.
What We Did: Ran a quick survey to identify key metrics. Explored queue management for managers but scoped it out for this release.
What We Learned: Wellington users needed daily exports to excel of service requests.
What We Did: Added two list views, including one with all columns and direct Excel export functionality.
What We Learned: SR Group and Type fields needed to update dynamically.
What We Did: Implemented lookup fields that update based on selection. Required custom Power Pages logic.
What We Learned: Users wanted to upload attachments directly instead of emailing them.
What We Did: Enabled direct file uploads. This feature is missing from the current system.
What We Learned: Users wanted to upload attachments directly instead of emailing them.
What We Did: Enabled direct file uploads. This feature is missing from the current system.
What We Learned: There were risks of human error with status updates, no way to track history, and too clicks to mark ICP's as created.
What We Did:
- Added validation to prevent skipping status stages
- Introduced an “ICP Created” button to streamline actions
- Built an activity log that tracks status changes, user actions, and timestamps, with optional notes.
What We Learned: Users needed a better way to flag and track SRs by status.
What We Did: Implemented a flag-and-status system for clearer tracking and prioritisation.
What We Learned: Only certain user groups should be allowed to update statuses.
What We Did: Restricted status changes to Wellington Electricity and contractor roles to reduce errors.

OVERVIEW

As part of a cross-functional team, I worked on redesigningthe service requests portal used by Wellington Electricity. These portals had become outdated and posed cybersecurity risks due to unsupported hosting platforms.

Our goal was to upgrade the portal by identifying user needs, mapping out current processes, and designing an improved interface. Through user research, stakeholder engagement, and iterative prototyping in Figma, we aimed to deliver a secure, intuitive experience that supports core operational workflows while minimising ambiguity for developers during implementation.

As part of a cross-functional team, I redesigned Wellington Electricity's outdated SAP Service Requests (SR) portal. The existing system was a cybersecurity risk and functionally limited. Our goal was to upgrade it by identifying user needs, mapping current workflows, and delivering a secure, intuitive interface that minimised ambiguity for developers and streamlined critical business operations.

Role

Product Designer

Timeline

3 Months

Team

2-person UX team — Lead Designer (supervisor) and myself as the Product Designer

Process

UX Research, Ideation, Wireframing, Mockups, Prototyping, User Testing

ABOUT THE PRODUCT

Wellington Electricity is a Power Distribution Company. Wellington Electricity has two SAP portals. The SAP Service Requests (SR) portal and Plant Maintenance Portal. The SR portal supports 4 main business processes including New Connections, Decommissions, Upgrades/Downgrades and Temporary Disconnections.

Wellington Electricity is a Power Distribution Company that manages two SAP portals. The SR portal supports four key workflows:

New Connections
Decommissions
Upgrades/Downgrades
Temporary Disconnections

CURRENT SYSTEM ARCHITECTURE

The current service request process begins when a retailer submits a new request, typically for a new electricity connection. If required, an ICP (Installation Control Point) is generated in Gentrack. The ICP number is then manually entered into the portal. Once the request is logged, Wellington Electricity (WE) sends the job details to the Contractor. Upon receiving the request, the contractor becomes responsible for scheduling and completing the work. After the job is carried out, WE verifies the job data and updates Gentrack as needed.

If the job meets all requirements, WE marks the request as complete in the portal. This final step triggers a transaction in SAP, officially closing out the process.

Retailer submits a request (e.g., for a new connection).
An ICP (Installation Control Point) is generated in Gentrack.
Contractor receives and schedules the job.
Wellington Electricity verifies the job and updates SAP.

PROCESS MAP

To gain a deeper understanding of the current process flow, together with my team lead I interviewed several key users of the portal. During these sessions, we asked team members to walk us through the processing of various Service Requests currently in their queue. By using real-life case scenarios, we were able to see the broader context and identify the unique life cycles of different types of Service Requests within the existing system. Insights gathered from these interviews were synthesised into a visual process map that helped us align with stakeholders and understand the end-to-end workflow.

To understand the service request lifecycle, I interviewed high-volume users. Using real scenarios, I mapped key workflows to reveal process variations across different request types.

Insights gathered were synthesised into a visual process map that helped us align with stakeholders and understand the end-to-end workflow.

UNDERSTANDING THE PROBLEM SPACE

The existing product although functional had some key limitations that included inconsistent export functionality—Excel exports only worked in Chrome, were blocked in Edge, and lacked detailed installation data. Billing logic was incorrect, charging per request instead of per street light. Reports were outdated, status updates required manual fixes after technical glitches, and contractor rejection reasons lacked standardisation. The system also failed to block requests missing essential ICP numbers.

Unclear field requirements - Incomplete data and manual follow-ups
Export function only worked in Chrome - No Edge support
Poor status tracking - Confusing overlap between Ticket and Tracking Status
No validation for mandatory fields - Frequent submission errors
Billing errors - Incorrect charges (per request vs. per streetlight)

USER PAIN POINTS

Lack of Clear and Comprehensive Information for Users

Lack of Clear Information for Users

Unclear field labeling and mandatory requirements lead to inconsistent contact information and incomplete submissions, causing manual follow-ups and underutilised data.

Incomplete submissions due to unclear field labels and missing mandatory fields.

Confusing and Error-Prone Status Management

Error-Prone Status Management

Confusing Status Options (SR Tracking Status & SR Ticket Status)

Consider converting Ticket Status into a tag/label to distinguish it more clearly from tracking status.
Overlap between SR Tracking Status and SR Ticket Status created confusion for users.
Explore automation to reset status where applicable.

Lack of Status Validation

Risk of contradictory status combinations (e.g., “Accepted” and “Rejected” selected simultaneously).
Validation and dropdown inputs are needed to prevent user error and maintain data consistency.

Confusing Status Options
Overlap between SR Tracking Status and SR Ticket Status created confusion for users.

Lack of Status Validation
No validation rules allowed errors like missing ICP numbers or past-dated schedules.

Current Portal

User Interface

Cluttered Search Screen

The existing search interface is visually overwhelming.
New design introduces only key filters (e.g., SR Number, ISP Number, Status, Address, Dates), with secondary filters hidden to reduce clutter.

Large Tables and User Experience (UX) Redesign

Current tables are too wide, causing key fields to be hidden especially in the retailer portal.
A redesigned layout improves readability and accessibility of all necessary fields.

Overly Long Lists

Excessive SR entries make it hard to find specific requests.
Better pagination and filtering will help users locate information more efficiently.

Cluttered Search Screen

Large Tables causing key fields to be hidden
Overly Long Lists

Current Portal

Integration and Data Challenges

Address discrepancies, character limits, and rigid field formats create friction in data entry. Improvements include confirming address mismatches with Gentrack, reviewing character limits, refining the 'Date Required' field based on request type, and enabling custom capacity inputs for greater flexibility.

Address mismatches
Conflicting formats between the portal and Gentrack
Lack of consistent field constraints
Missing or inconsistent character limits led to data entry errors and backend sync issues.
Irrelevant or rigid form fields
Users had to fill in fields that weren’t applicable to their request type, leading to incorrect submissions.
No validation for key inputs
The system allowed invalid entries—such as past dates or blank mandatory fields—resulting in processing errors and follow-ups.

PROBLEM STATEMENT

The current Portal has the following risks including an Unsupported Java Platform, SAP being behind on upgrades, several UX Issues and Potential Cyber Risk. The SR Portal supports business functions which cannot effectively be performed if the portal fails.

REDESIGN GOALS

Define a robust data schema that includes field-level constraints such as character limits and improved input validation.

Define robust data schema with clear input constraints

Redesign the status tracking system to clearly separate lifecycle statuses from flags, with built-in validation to prevent users from skipping required steps.

Improve status tracking with validation and separation of flags

Introduce mandatory contact fields to ensure clear site-level communication and accountability.

Introduce mandatory contact fields to ensure clear site-level communication

Streamline the search interface by decluttering the UI, simplifying result tables, and implementing focused filters for quicker request retrieval.

Simplify search interface, introduce better filtering

FINAL DESIGN

With a clear understanding of specific use cases, pain points and process maps we were able to draft the final mockups of the portal. I led the design stage of the portal design and the portal was fully developed on Figma. The design also considered that the final portal was to be built on Microsoft PowerPages and was designed accordingly.

MOCKUP

FINAL DATA SCHEMA DESIGN

Based on various user interviews and process walkthroughs we were able to draw up a detailed data schema with specific character limits. The data schema was designed to have the portal host multiple tables. This structure ensured that the portal was scalable in future when large amounts of service requests would need to be saved on the database.

PROTOTYPE WALKTHROUGH

After developing the initial mockups, we conducted a series of prototype walkthroughs with key stakeholders. This included high-volume retailers and key users from Wellington Electricity. These informal sessions helped us gather early impressions and usability insights.

MAIN ISSUES

Prefilled Fields

Retailer and business area information should auto-populate based on login credentials

Date Validation

The "Schedule Date" field should restrict selection of past dates

Form Editability:

Service request forms should remain editable even after closure, until the end of the billing cycle each month

Form Replication

Users requested a feature to copy and paste entire form contents to reduce manual data entry

Form Replication

Users requested a feature to copy and paste entire form contents to reduce manual data entry

Prefilled Fields

Retailer and business area information should auto-populate based on login credentials

Date Validation

The "Schedule Date" field should restrict selection of past dates

Form Editability:

Service request forms should remain editable even after closure, until the end of the billing cycle each month

These UX issues were addressed during development, guided by a UX enhancements table that helped communicate findings to developers and supported ongoing design iterations. At this stage, development was 80% complete. The portal, built on Microsoft PowerPages, was migrated to the client’s development environment, allowing users with organization login IDs to access and test the site before public release.

TEST SCRIPTS

With logistics in place, we moved into Unit Testing. I created test scripts covering both happy paths and exception cases to ensure thorough and rigorous testing.

UAT SESSION

Findings during the UAT sessions were recorded and logged in a defects register that was presented to the developer during daily check-ins to fix bugs as we proceeded with testing.

DEFECTS REGISTER

FINAL PRODUCT

Based on testing outcomes, the product was continuously refined in collaboration with the developer. The final version was successfully presented to the client and received positive feedback. With the portal now complete, it was handed over for SAP integration. Training and transition began promptly, marking the close of the project and paving the way for full implementation.

Eva Mary Arun

Product Owner | Digital Transformation

Site Map

Home

Works

About

About Me

Product Owner with a background in UX design and business analysis. Specialising in Digital Transformation projects.

Lets Connect!

Resume

Eva Mary Arun

Product Owner

Site Map

Home

Works

About

About Me

Product Owner with a background in UX design and business analysis. Specialising in Digital Transformation projects.

Lets Connect!

Resume