Internal Energy Operations Dashboard — Planning, CSV Workflow, and Implementation Support

Operation Planning: Month View

• Two-month grid covering the current and following month
• Devices as rows and dates as columns
• Plan existence 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 as rows and 48 half-hour slots as columns
• Device-specific minimum and maximum output constraints
• CSV download and upload
• Deletion of the selected day’s plan
• Validation results with identifiable correction locations

Operation Mode Switching

• Current mode and status display
• Control over when uploaded plans become active
• A confirmation modal 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 CSV
• Single-day deletion and multi-date bulk deletion
• Warnings and confirmation around snapshot replacement

Understanding the Current Workflow and Shaping 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 established the operational steps, the impact of data updates, and the decisions users needed to make. The initial requirements contained several open questions. I used concrete interface drafts to support stakeholder review and progressively define the expected behavior. With no dedicated PM, I also documented decisions and supported alignment across stakeholders.

Iterating the Interface Structure

I created several Figma directions, including card-based layouts organized by device, a two-month planning grid, a day view structured as a device × 48-slot table, and interactions for selection, saving, applying, and bulk deletion. Inline editing and CSV-based operation were evaluated against implementation cost, operational practice, and mistake risk before the final scope was agreed.

Validating Interactions Through Code

Figma was used for early layout and information-structure exploration. I moved to code prototypes when CSV parsing, validation, error handling, selection states, and bulk deletion required more detailed behavioral testing. The prototypes helped verify interaction behavior, data volume, implementation constraints, and integration with the existing codebase. They were shared with the external vendor as reference implementations, and selected parts were reused in production.

Designing Frontend Validation and Error UX

• Validated file extension, file size, date mismatches, and dates outside the permitted range
• Checked for missing slots from the required set of 1–48
• Checked 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
• 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 interface date with the date contained in the CSV
• Blocked uploads when the dates did not match
• Separated single-day and multi-date deletion flows
• Added confirmation before deletion and mode switching
• Identified the target and intended impact before applying a change

Preparing Implementation Specifications and Handoff Material

• Annotated screenshots for each screen
• UI states, interactions, modals, empty states, and edge cases
• Single-day and multi-date deletion flows
• API endpoints, payloads, and response patterns
• Frontend and backend validation responsibilities
• Error-code mapping to localized English and Japanese messages
• Copy and translation tables for longer modal guidance
• Rationale and behaviors that needed to remain consistent during implementation

Reviewing Implementation and Contributing Targeted Fixes

The external vendor implemented the full feature set. I reviewed the code for alignment with the specification, validation behavior, error handling, and impact on existing screens. For areas where the design had not been reflected or the implementation decision was complex, I provided concrete code through review comments. I also implemented selected fixes directly and carried them into the production code. GitHub Copilot was used 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, then fixed the issues that were valid.

Separating Initial and Future Scale

The initial release handled approximately six devices × 48 slots. The future target was 50–100 devices × 48 slots. Separating month and day views supported both the initial workflow and 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 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 Deletion and Mode Changes

Single-day deletion, multi-date deletion, and operation mode switching included confirmation modals showing the target and intended impact.

Reducing Interpretation Gaps

Screens, 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.