Internal Energy Operations Dashboard — UX Engineering for Planning and Mode Switching
This case study focuses on the UX engineering behind Operation Planning and Operation Mode Switching, two of several features I contributed to within an existing internal dashboard for a smart-city energy environment. My main output was a detailed technical UI specification covering interaction behaviour, UI states, frontend validation, error handling, and data flow, supported by Figma materials and working prototypes. I also coordinated frontend data needs with the backend engineer and stayed involved through vendor implementation and production release by reviewing the code, providing code for specific changes in review comments, and making changes myself when needed.
Where this experience applies
This case study focuses on moving a high-impact CSV- and database-dependent workflow into new feature areas within an existing internal dashboard. The work combined workflow analysis, UX engineering, validation design, technical coordination, implementation specifications, and production support.
- Moving a CSV- or manually operated workflow into an internal interface
- Defining interaction behaviour, UI states, and data flows
- Designing controls that reduce the risk of accidental data loss
- Turning evolving requirements into testable interface alternatives
- Coordinating frontend data needs and validation boundaries with a backend engineer
- Preparing technical UI specifications for another implementation team, supported by Figma materials and working prototypes
- Supporting implementation through code review, specific code changes in review comments, and direct changes when needed
Overview
I contributed to several new features within an existing internal dashboard used in a smart-city energy environment. This case study focuses on two of those feature areas: Operation Planning and Operation Mode Switching. My formal role was Frontend Engineer, and my work on these features was primarily UX engineering. I investigated the existing operational workflow and used Figma alongside working prototypes built with the project’s frontend stack to help stakeholders evaluate concrete alternatives and clarify requirements. I documented the agreed interaction behaviour, UI states, validation rules, error handling, data flows, and implementation details in technical UI specifications, supported by Figma materials and working prototypes. I worked with the backend engineer to communicate frontend data needs, propose possible data structures, and agree how responsibilities should be divided between the frontend and backend. The backend engineer owned the final API design, while I documented the agreed API behaviour, payloads, responses, validation boundaries, and error handling within the UI specifications. An external vendor handled the overall production implementation. The vendor reused selected parts of the prototype code, and I reviewed the implementation for alignment with the agreed behaviour and specifications. I provided concrete code in review comments and directly implemented selected areas that were complex, incomplete, or inconsistent with the specification. Both feature areas were released to production and entered operational use.
Background
The existing dashboard is used to manage and monitor power devices within a smart-city energy operations environment. The feature areas covered in this case study support the editing and application of short-term or experimental operation plans. The previous workflow combined Excel, CSV files, command-line operations, and direct database updates. Because these actions were connected to power control, applying an incorrect plan could affect operational costs and supply stability. CSV uploads also used a date-based snapshot replacement model. Data omitted from an uploaded file could therefore be treated as deleted, making the relationship between user actions, validation, and data updates especially important.
Challenge
The project needed to introduce a safer and more understandable interface for a high-impact operational workflow while working within an existing product, an evolving set of requirements, and realistic implementation constraints.
- Initial requirements contained open questions that were difficult to resolve without concrete interface behaviour to evaluate
- CSV contents replaced existing planning data for a selected date, creating overwrite and deletion risks
- The date selected in the interface needed to match the date contained in the CSV
- Validation needed to cover device IDs, active status, device-specific value ranges, and all 48 time slots
- The initial release covered approximately six devices, with a future target of 50–100 devices × 48 slots
- Existing screens made date boundaries and the causes of errors difficult to understand
- External implementers needed explicit definitions of interactions, UI states, edge cases, data behaviour, APIs, and copy
- Changes needed to fit the existing codebase without disrupting other screens
Primary Users
- Operations-oriented users who adjust schedules
- A manager-level stakeholder who directly uses the interface
- Other internal stakeholders who review or apply planning changes when needed
Feature Scope
Operation Planning: Month View
- Two-month grid covering the current and following month
- Devices shown as rows and dates as columns
- Plan availability shown within each cell
- Plans created only for selected experimental dates and devices
- CSV template download
- Bulk deletion across selected dates
- Selection states and confirmation modals
Operation Planning: Day View
- Detailed grid for one selected date
- Devices shown as rows and 48 half-hour time slots as columns
- Device-specific minimum and maximum output constraints
- CSV download and upload
- Deletion of the selected day’s plan
- Validation results showing identifiable correction locations
Operation Mode Switching
- Current operation mode and status display
- Control over when uploaded plans become active
- Confirmation behaviour explaining the intended change and its operational impact
- Explicit confirmation before applying a mode change
CSV Workflow
- Template download when no plan exists
- Valid devices and all 48 time slots included in the template
- Upload restricted to the selected day view
- Date matching between the interface and the CSV
- Single-day deletion and multi-date bulk deletion
- Warnings and confirmation around snapshot replacement
Approach
Understanding the Current Workflow and Surfacing Requirements
I interviewed operational stakeholders and reviewed how Excel, CSV files, command-line operations, and database updates were used to create and apply operation plans. This helped establish the operational steps, the effects of data updates, the risks involved, and the decisions users needed to make. Some requirements were difficult to define in the abstract. I therefore used concrete interface alternatives and working prototypes to help stakeholders react to proposed behaviour and clarify what the workflow needed to support. In the absence of a dedicated PM, I also documented decisions and supported alignment across stakeholders.
Iterating Between Figma and Working Prototypes
I used Figma to explore information structure, screen composition, UI states, and alternative approaches. These included card-based layouts organised by device, a two-month planning grid, a day view structured as a device × 48-slot table, and different behaviours for selection, saving, applying, and bulk deletion. I also built working prototypes using React, Next.js, TypeScript, Material UI, MSW, and the project’s existing frontend patterns. I moved between Figma and code throughout the process, using whichever medium made a question easier to evaluate. Presenting concrete alternatives allowed stakeholders to compare possible behaviours and identify what matched or did not match their operational needs. Inline editing and CSV-based operation were evaluated against implementation cost, existing working practices, data constraints, and the risk of mistakes before the final scope was agreed.
Defining Interaction Behaviour, UI States, and Data Flow
The work extended beyond screen layouts and wireframes. I defined what should happen after each user action, how the interface should change between states, what data would be needed at each point, and how the frontend should respond to success, validation errors, and processing failures. Code prototypes were especially useful for evaluating CSV parsing, validation, selection states, error handling, destructive actions, and data volume within the existing codebase. They also helped expose technical constraints early enough to influence the agreed behaviour. The prototypes were shared with the external vendor as supporting implementation material, and selected parts of the prototype code were reused in production.
Coordinating Frontend Data Needs with the Backend
As the interface behaviour became clearer, I identified the data required by each view and the points at which it was needed. I proposed possible data structures and discussed with the backend engineer whether particular transformations should happen in the frontend or backend, considering implementation efficiency, consistency, reuse, and safety. The backend engineer owned the final API design. I contributed the frontend requirements and proposals, then documented the agreed API behaviour, payloads, responses, validation boundaries, and error codes as part of the implementation UI specifications.
Designing Frontend Validation and Error UX
- Validated the file extension, file size, date mismatches, and dates outside the permitted range
- Checked for missing time slots from the required set of 1–48
- Checked for invalid device IDs, inactive devices, and values outside device-specific limits
- Stopped uploads when processing could not continue
- Aggregated correctable data errors with row and column information
- Defined how validation results and processing failures should affect UI state
- Coordinated validation responsibilities, error codes, and response formats with the backend engineer
Handling Snapshot Updates and Destructive Actions
- Restricted uploads to the selected day view
- Compared the date selected in the interface with the date contained in the CSV
- Blocked uploads when the dates did not match
- Separated single-day deletion from multi-date bulk deletion
- Added explicit confirmation before deletion and operation mode switching
- Identified the target and intended operational impact before applying a change
- Defined the UI states and data-update behaviour for successful, blocked, and failed actions
Preparing Implementation UI Specifications and Handoff Material
- Annotated specifications for each screen and feature area
- Interaction behaviour, UI states, modals, empty states, and edge cases
- Single-day and multi-date deletion behaviour
- API endpoints, payloads, and response patterns agreed with the backend engineer
- Frontend and backend validation responsibilities
- Error-code mapping to localized English and Japanese messages
- Copy and translation tables for longer modal guidance
- Working prototypes used as supporting material for the implementation specifications
- Rationale and behaviour that needed to remain consistent during implementation
Reviewing Implementation and Contributing Code Changes
The external vendor handled the overall production implementation. I reviewed the code for alignment with the agreed interaction behaviour, validation rules, error handling, data flow, and impact on existing screens. Where the agreed behaviour had not been reflected, or where an implementation decision required more concrete guidance, I provided code for specific changes in review comments. When needed, I also made changes myself and carried them into the production code. I used GitHub Copilot as an additional review and verification aid to surface possible bugs, validation gaps, and security concerns. I checked each finding against the actual code, project scope, and implementation context, and fixed the issues that were valid.
UX Engineering & Implementation Highlights
Making Requirements Concrete
Figma alternatives and working code prototypes gave stakeholders something concrete to evaluate when the requirements were difficult to fully express upfront. Their responses were used to refine the interface behaviour, operational flow, and final scope.
Separating Initial and Future Scale
The initial release handled approximately six devices × 48 slots, while the future target was 50–100 devices × 48 slots. Separating the month and day views supported the initial workflow while accounting for the expected increase in information density.
Making Date Agreement an Upload Condition
Uploads were restricted to the selected day view, and the interface date was checked against the date contained in the CSV. A mismatch blocked processing before another day’s plan could be updated.
Aggregating Correctable Errors
Row- and column-level errors were collected and displayed together with their locations and causes, allowing users to review multiple corrections in one pass.
Confirming Destructive and Operationally Significant Actions
Single-day deletion, multi-date deletion, and operation mode switching included confirmation behaviour showing the target and intended impact before the action was applied.
Connecting Interface Behaviour with Data Behaviour
User actions, UI states, frontend validation, API responses, and data-update effects were specified as parts of the same workflow rather than as separate design and engineering concerns.
Reducing Interpretation Gaps
Interactions, UI states, edge cases, APIs, validation responsibilities, error codes, and localized copy were documented as one connected specification. Code review then checked the implementation against those decisions.
Outputs
- Requirements based on existing workflows and operational risks
- Interaction and screen-structure specifications for the month and day views
- Operation Mode Switching behaviour and confirmation flow
- CSV template, upload, validation, and deletion workflows
- Figma explorations and final annotated specifications
- Working code prototypes used to support the implementation specifications
- UI state and interaction specifications
- Frontend validation and error-feedback specifications
- Frontend data requirements and proposed data structures
- Frontend/backend validation responsibility mapping
- Documentation of API behaviour agreed with the backend engineer
- Error-code mapping and localized English and Japanese messages
- Implementation documentation covering states, data behaviour, edge cases, and modals
- External-vendor handoff material
- Code review, implementation guidance, and selected production code changes
Outcome
- Released Operation Planning and Operation Mode Switching to production
- Started operational use of both feature areas
- Turned evolving requirements into concrete, testable interface behaviour
- Defined interactions, UI states, data flows, validation rules, edge cases, and copy
- Aligned frontend data needs and responsibility boundaries with the backend engineer
- Carried safeguards for snapshot replacement, deletion, date mismatches, and operation mode switching into implementation
- Reused selected parts of the working prototypes in production
- Reviewed the vendor’s implementation, provided code for specific changes in review comments, and made selected changes directly
Screens & Design Material
Final technical UI Specification: Month View
A two-month view for checking plan availability by device, downloading a CSV template, and deleting plans across selected dates.
Final technical UI Specification: Day View
A device × 48-slot table with CSV upload, download, validation, and deletion for the selected date.
CSV Validation Error View
Correctable errors are aggregated with row, column, and cause information so users can review multiple issues in one pass.
Operation Mode Switching
The interface shows the current mode and controls when uploaded plans become active.
Mode-Switch Confirmation
The confirmation identifies the intended change and its operational impact before the new mode is applied.
Draft 1: Card-Based Day View
An early alternative using one card per device to explore how users could review and edit daily plans.
Draft 2.5: Month Grid
An iteration exploring how users could identify dates with plans and move from the month view into the selected day.
Draft 3: Day Table
The transition from a card-based structure to a device × 48-slot table for handling higher information density.
Draft 4: Editing and Bulk Actions
An iteration used to evaluate editing states, bulk actions, data-update behaviour, and mistake prevention.
What This Work Demonstrates
This case study demonstrates UX engineering within an existing operational product. User actions, interaction behaviour, UI states, frontend and backend responsibilities, data-update constraints, implementation cost, and operational impact all needed to be considered together. I moved iteratively between Figma and working code prototypes to make evolving requirements concrete and testable. I then developed the agreed behaviour into validation rules, data requirements, localized error messages, edge-case handling, and UI specifications. After handoff, I continued supporting the work through vendor code review, concrete implementation guidance, selected production code changes, release, and the start of operational use.