Heyy! I'm Srithika
I'm interested in the WAC UX/UI Designer role
Because this feels like a role where everything I've built comes together.
I'm genuinely excited about this opportunity.
Coming from an architecture background and later growing into product design, I naturally look at problems from both a structured and human-centered lens. That made this role especially interesting to me.
After going through the job description, I felt connected to the kind of work this team does and wanted to explore it more deeply through a couple of focused design exercises.
I chose to focus on the design system because it’s the core foundation of everything else and I also worked on the commissioning flow and its screens because it’s one of the more complex parts mentioned in the JD, especially with the error states and edge cases involved, and this is the kind of work I genuinely enjoy!
There are definitely other important areas in the role too, but these two areas felt like the best way to show how I think, how I solve problems, and how I approach complex product experiences.
Disclaimer: this case study is simply my interpretation and way of showing my genuine interest and enthusiasm for the role. If anything here comes across the wrong way or offends anyone, I sincerely apologize.
The deep ultramarine blue was chosen to echo engineering blueprints and the physical world WAC works in, while also feeling more modern and distinctive than a standard corporate blue.
DM Mono was used for data values because aligned numbers, device IDs, and sensor readings improve clarity and make technical information easier to scan.
Section 01
At a Glance
The complete commissioning journey in six steps. Every device in a building passes through this path exactly once.
01
Discover
System finds devices
02
Identify
Operator names them
03
Locate
Place on floorplan
04
Configure
Set thresholds
05
Test
Validate readings
06
Activate
Go live
Every step builds on the last. Location cannot be changed after activation — the system enforces this with a two-tap confirmation at Step 3.
Section 02
Step by Step
What happens at each stage — what the system does, what you do, and what changes.
01
Phase 1 · Automated
Discover
"The system does the searching for you."
System does
Scans the building network using BACnet/IP and Modbus protocols. Streams results in real time over a 30-second sweep.
You do
Wait and watch. Confirm the device count looks right. If nothing shows up, trigger a retry — up to three attempts.
Output
A list of all devices found on the network, ready to be named and identified.
Are any devices found? If not, the system retries up to 3 times. Still nothing? An alert fires and commissioning stops.
02
Phase 2 · Operator-led
Identify
"Put a name and a face to every device."
System does
Waits for operator input. Auto-populates device type, firmware version, and manufacturer once a device is confirmed.
You do
Scan the QR code on the device label (fastest). Or use signal ping to find it by sound. Or type the serial number manually as a fallback.
Output
Every device has an ID, type, model, and firmware on record. None move forward unnamed.
Working with many of the same device type? Use bulk identify — confirm type once, QR-scan each unit individually. Faster, but location must still be set per device.
03
Phase 3 · High-risk action
Locate
"Tell the building where each sensor lives."
⚠ Cannot undo after activationSystem does
Shows a live floorplan with signal strength heatmap. Highlights where signal is strong so you can make better placements.
You do
Drag each device from the queue onto the correct room. Confirm the placement — twice. The second tap is the point of no return.
Output
Every device has a permanent physical address: Building → Floor → Zone → Room.
Is someone already assigned to this room? A conflict warning appears with the existing device's ID and install date. You can replace it, move to an adjacent room, or go back and re-identify.
04
Phase 4 · Configuration
Configure
"Set the rules the building will live by."
System does
Validates every value as you enter it. Flags anything outside the allowed range before you can move on. Offers platform templates for common setups.
You do
Set alert thresholds, reporting frequency, schedule, and escalation rules. Apply a template or go manual for custom setups.
Output
Each device has a complete rulebook. It knows when to report, what's normal, and who to alert if something is wrong.
Are all values within the allowed range? If not, the exact field is highlighted with a specific reason and a suggested fix — never just "invalid."
05
Phase 5 · Validation
Test
"Does the device actually work where it's placed?"
90-second validation windowSystem does
Requests a first reading from every device. Checks signal strength, validates the reading against expected ranges, and waits for a heartbeat confirmation.
You do
Watch the results come in. For anything that fails, decide: retest, escalate to the field team, or skip and flag for later.
Output
A pass/fail list for every device, with a specific failure reason for anything that didn't make it.
Did everything pass? If not, you can retest failed devices. If they fail again, they're escalated for physical inspection. Passing devices don't wait — they continue to activation.
06
Phase 6 · Go-live
Activate
"The building comes online."
✓ Devices now liveSystem does
Pushes all commissioned devices to the live dashboard. First real readings appear. Generates a session report with full audit trail.
You do
Confirm the session is complete. Review the session report. Any skipped or failed devices are clearly marked for follow-up.
Output
Live devices on the dashboard. A permanent session report: device count, time elapsed, failure log, operator ID, timestamp.
Were all planned devices commissioned? If some were skipped, the system flags them as "pending" and sends them back to Step 3 for completion.
Section 03
What Can Go Wrong
Six separate scenarios. Each has its own resolution path and rejoins the main flow cleanly.
Bulk Operations
Trigger: Operator has 10+ identical devices to commission
Select all devices of the same type in one actionUp to 40 devices per batch
Confirm device type and firmware once for the entire batchQR-scan each physical unit to confirm MAC address
Each device still receives an individual location assignmentNo bulk-locate — wrong placement corrupts all downstream data
All identified devices enter the Step 3 queue togetherProcessed one at a time from this point forward
↩ Returns to: Step 3 — Locate
Test Failure
Trigger: One or more devices fail the 90-second validation
Failed devices listed with a specific reason per deviceNo signal · Out-of-range reading · No heartbeat
Choose: Retest, Skip and flag, or EscalatePassing devices do not wait — they continue to activation
If retest fails a second time → escalate to field teamDevice flagged for physical inspection. Cannot activate until cleared.
Skipped devices marked "pending" on dashboardAlert sent to supervisor. Rest of batch activates normally.
↩ Returns to: Step 6 — Activate (for passing devices)
Interrupted Session
Trigger: App closes mid-session — tablet loss, WiFi drop, shift end
Auto-save fires — all progress written to server immediatelyEvery 30 seconds + on every step transition + on every confirmed action
"Resume session" banner appears on next app openShows step number, devices commissioned, and time since last activity
Same operator resumes: full state restored instantlyNo data loss. Last device highlighted. Progress bar correct.
Different operator: supervisor PIN required to transfer sessionIf rejected → session abandoned and flagged for review
↩ Returns to: Wherever the session was interrupted
Connectivity Loss
Trigger: WiFi or network drops mid-commissioning
Offline mode activates immediately — operator continues workingBanner: "Working offline — changes sync on reconnection"
All changes queued locally on deviceNothing is lost. Work proceeds normally on device.
On reconnection: queue syncs to server, conflict detection runsOperator reviews any conflicts: keep local or server version
If offline for 5+ minutes → session paused, force-save to deviceMust reconnect before activating any device. Safety gate.
↩ Returns to: Current step, after sync resolves
Location Conflict
Trigger: Operator drops a device on a room that's already occupied
Conflict modal appears immediatelyShows existing device ID, type, and installation date
Three resolution options presented:
A — Replace existing device · B — Move to adjacent room · C — Cancel and re-identifyOperator chooses — no assumption is made
A — Replace existing device · B — Move to adjacent room · C — Cancel and re-identifyOperator chooses — no assumption is made
Resolution recorded in audit log with reasonConflict history visible to supervisors
↩ Returns to: Step 3 — Locate (to confirm new placement)
Hot Swap
Trigger: A live device fails in the field and must be physically replaced
Device stops sending heartbeat — fault alert generatedTechnician dispatched for hardware replacement
New device detected at same location — matched to previous recordSystem inherits all config: thresholds, schedule, escalation rules
If firmware is compatible → goes straight to Test. Steps 1–3 skipped.Fast path for clean hot swap
If firmware is incompatible → enters at Step 4 to review configLocation data preserved. Only config values need attention.
↩ Returns to: Step 5 — Test (or Step 4 if reconfiguration needed)
Section 04
Design Thinking
Every constraint in this system exists for a reason. Here's the reasoning behind the decisions that shape the experience.
Step 3 — Location
Why is location assignment the highest-risk step?
Location is the one thing you cannot fix in software after activation. Every reading, every alert, every report downstream is tied to where the device says it lives. A wrong placement doesn't just give bad data — it corrupts the building's entire understanding of that space, silently, for as long as the device runs. That's why it requires two deliberate taps to confirm.
Design choice: friction is intentional. The second tap slows the operator down at exactly the right moment.
Step 2 — Bulk Operations
Why can you bulk-identify but not bulk-locate?
Device type is a category. Location is a fact. When you identify in bulk, you're saying "these are all thermostats" — which is fine to confirm once. But when you locate, you're saying "this specific thermostat goes in room 303" — and no two devices share the same room. Bulk-locate would mean trusting automation with permanent, irreversible decisions.
Design choice: automation is used where errors are recoverable. Human confirmation is required where they are not.
Connectivity Loss
Why does offline mode exist at all?
Commissioning happens in buildings under construction — in basements, stairwells, plant rooms. Connectivity is unreliable by design. If the app stopped working every time the signal dropped, an operator mid-floor would lose everything and have to start over. Offline mode means the operator's physical presence and work isn't held hostage to network conditions.
Design choice: the system adapts to the physical environment, not the other way around.
Step 5 — Testing
Why is the test validation window only 90 seconds?
A device that can't produce a valid reading within 90 seconds is either misconfigured, incorrectly placed, or physically faulty — all things that need a human to address before the device goes live. A longer window would just delay that discovery. The strictness is also a quality gate: every device that passes has demonstrably worked under real conditions at its real location.
Design choice: a tight window surfaces problems earlier, when they're cheaper to fix.
Step 6 — Activation
Why is partial activation allowed?
In a building with 128 devices, blocking activation entirely because 4 devices failed would hold up the 124 that are ready. The alternative — partial activation with clear pending states — means the building starts getting value from the working devices immediately, while failed ones are tracked, escalated, and resolved separately. Progress doesn't have to be all-or-nothing.
Design choice: the system respects that real-world deployments are rarely perfect on the first pass.
System-wide
Why is every action timestamped and operator-tagged?
Commissioning is a legal and contractual handoff. When a building goes live, the client needs to know what was done, by whom, and when. The audit trail also makes incident investigation tractable — if a sensor reports wrong data six months later, you can trace exactly who placed it and when. Accountability at every step is a feature, not overhead.
Design choice: the audit trail serves operators, supervisors, clients, and regulators — not just the UI.
