Scheduled Jobs · Enterprise field operations
From fault management to planned field operations
Expanding a platform built to operate electrical faults into one that supports planned work across teams, shifts and connected systems.
- Role
- Product ownership, strategy & UX/UI
- Platform
- For IEC. Names and identifying details have been changed to allow this work to be shared publicly.
- Users
- Field technicians, supervisors, operational managers, control center
- Scope
- Research, product logic, UX/UI, functional specification, delivery
01
A familiar system, a different kind of work
WIZVOLT is a fault-management platform for the Israel Electric Corporation (IEC). The desktop system brings together fault types, locations and assigned teams; its mobile app supports technicians and supervisors in the field.
It was built to react when something went wrong. Planned work introduced a different rhythm: jobs scheduled in advance, multiple teams and work continuing across shifts. Coordination had relied on paper, calls and messages. My challenge was to bring this new way of working into a familiar product while keeping operational responsibility clear.
02
Understanding the work behind the screens
I worked against the full chain of the operation, not a single user group:
- Field technicians executing the work on site
- Supervisors accountable for conditions at the site
- Dispatch coordinating assignment across teams
- Office managers scoping and funding the capability
Interviews, workshops and workflow mapping helped me trace responsibilities, dependencies and exceptions across the desktop platform, mobile app and dispatch system.
Stakeholder Management was central. I facilitated workshops bringing operational knowledge, documentation requirements and technical constraints into the same conversation with the client, architect, CTO, development and QA - recording decisions and open questions and using evolving mockups to make alternatives concrete. The maps connect discovery to the product logic: assignment can change while the reported electrical state remains.
Good decisions happened when the field, the client and the developers were in the same conversation.
03
One platform, two operational logics
Research showed that planned work had to be separated from the core fault flow into a new, dedicated flow.
I integrated planned jobs into the existing architecture and design system, preserving the card layout, navigation and information hierarchy crews already used. A pale yellow treatment, explicit Scheduled Jobs label and dedicated filter distinguish the new work, with fields and actions suited to planning.
The desktop maintains the operational overview; the field app focuses on execution. I mapped what could be reused from the fault model - job information, permissions, assignment, reporting, role-based visibility - and what needed new logic, keeping assignments and updates synchronized across connected systems. The workflow and interface evolved together as constraints became clearer.
A fault-card structure, reorganized to fit planned work.
Out of the research came a new card: visually distinct and tailored in content, yet as close as possible to the familiar structure and language users already rely on.
04
The job continues. The shift ends.
The hardest case appeared at handover: a team could finish its shift while the job remained active and power was still disconnected. Reassigning the job could not wipe out that context.
I separated assignment status from electrical state. Responsibility could move to another team while the reported power state and history were retained. Making both states visible helped the incoming team understand its responsibility and the situation on site.
Dispatch manages reassignment, including requests from the field; technicians do not choose the next team themselves. A reason, optional note and explicit confirmation make the transfer deliberate and traceable.
Try the transfer
Illustrative prototype · fictional data
A simplified model of the two dimensions - not the original client interface and not connected to any real operation. Transfer the job and watch which state changes.
Task status
Team A · Active
Current team at work
Electrical state
Power disconnected
Reported by Team A
Job history
- 1. Assigned to Team A
- 2. Power reported disconnected
05
From product logic to field execution
I carried the model into functional specifications, reviewed feasibility with the architect and CTO, and worked with developers and QA through implementation.
On the app, available actions follow the stage of the job. Reporting captures the event context, a completion code, a note and supporting evidence. The existing safety form is photographed and attached to the digital report. Reporting restoration completes the job: it leaves the technician’s active feed and remains available to managers and in history.
Some of these screens already existed as part of the fault-handling process. Wherever possible, I reused the same screens to keep the experience consistent.
06
In the field, with more to come
The feature is now used in the field by a selected testing group, with nationwide rollout in preparation. Participants report substantial time savings, fewer misunderstandings and fewer calls and messages needed for coordination.
The work established a product model for planned, multi-team operations within the existing platform. My next initiative is digitizing the safety form itself - another step in moving manual processes into digital workflows in a large, long-established organization.
WIZVOLT is a pseudonym. Names, identifiers and operational details have been changed or generalized for public presentation. Visuals include supplied portfolio designs and illustrative reconstructions.
The shift ends. The work continues.