Beacon
01 PROJECT SUMMARY
The product was scaling. The interface needed to scale with it.
Zoho IoT was expanding from a relatively contained product into a broader ecosystem spanning B2B developer modes, B2C experiences, onboarding, dashboards and increasingly complex enterprise workflows. At the same time, delivery velocity was rising to support go-to-market milestones.
I created Beacon as the shared design language for that growth: a reusable system of visual foundations, interaction patterns and UI components that helped teams build new product areas without reinventing the interface every time.
02 PROBLEM
Every new feature was becoming another design decision.
As the platform diversified, common controls started to drift. Buttons, navigation states, notifications, selectors, date pickers and data-entry patterns could be interpreted differently from one flow to the next.
The visible issue was inconsistency. The deeper cost was repeated design effort, implementation ambiguity, QA friction and rework at exactly the moment the team needed to move faster.
Button families, hierarchy and interaction states were explicitly defined instead of being redrawn feature by feature.
03 MY ROLE
From founding designer to system steward.
As the founding designer for Zoho IoT, I owned the design language connecting the product ecosystem. I initiated, designed and maintained Beacon in Adobe XD, turning recurring interface decisions into reusable components, interaction rules and visual standards.
My work sat between product design and delivery infrastructure: identify repeated patterns, define state behaviour, document intended use, align with engineering and QA, and feed lessons from active feature work back into the system.
The system specified navigation behaviour across base, hover, submenu, overflow and “More” states.
04 OUTCOMES
Beacon paid back in delivery speed, not just visual polish.
70% faster feature delivery Reported improvement from reuse, clearer references and reduced repeated UI work. | Less rework for the dev crew Shared states and interaction rules reduced avoidable interpretation and implementation churn. | One reference across design, engineering & QA Beacon became a dependable internal source for UI patterns, behaviours and hierarchy. |
Toast patterns captured warning, success, error, information and loading states as reusable feedback behaviour.
05 INTENT
Create a design language, not a frozen catalogue.
The goal was not to make every screen identical. Beacon needed to provide dependable primitives and interaction behaviour while leaving enough room for very different IoT contexts, from developer tooling and device configuration to onboarding and customer-facing workflows.
So the real question became: what should remain stable across the ecosystem, and where should product teams still have room to solve genuinely different problems?
The same system supported a more illustrative onboarding experience, including selected, hover and alternate setup states.
06 CHALLENGES
The system had to solve for scale before scale fully arrived.
This was 2018, when design systems were rapidly becoming a serious product discipline. Inside Zoho IoT, the practical challenge was harder: define patterns robust enough for an expanding enterprise platform without slowing a team already under GTM pressure.
IoT workflows also carried dense states. Controls could be disabled, loading, warning, destructive, active, nested, empty or data-dependent. A component library that only captured the “happy path” would have been decorative rather than useful.
Checkbox and radio controls documented default, hover, active and disabled combinations rather than a single static state.
07 APPROACH
Build the system from recurring product decisions.
Rather than starting with an abstract inventory of UI elements, I used the live product as source material. Repeated screens, controls and behaviours were analysed for common structure. Stable patterns became reusable components; ambiguous ones were resolved through actual product use.
The shift was consequential: design moved from producing isolated screens to maintaining a shared vocabulary that could be assembled repeatedly and refined through feature delivery.
Colour foundations covered brand tones, neutrals and semantic status colours for operational feedback.
08 KEY WORK / SOLUTIONS
The system worked because it captured decisions, not just pixels.
01 Reusable foundations across product modes
B2B tools, B2C experiences and onboarding had different jobs to do, but common controls were beginning to drift. I created reusable foundations that could travel across those contexts without redesigning common elements each time.
Tabs, overflow and action patterns stayed coherent as information density increased.
02 Components designed for real states
Enterprise IoT workflows contain validation, loading, success, error, disabled and destructive states. Beacon documented those behaviours so design, engineering and QA could reason from the same source.
Slider behaviour specified hover, intermediate loading and final state changes.
03 A shared reference for engineering and QA
A system creates leverage only when the people building and validating the product can rely on it. Beacon became a central reference for hierarchy, sizing, feedback, navigation and interaction behaviour.
Alert, warning and information cards documented spacing, severity and action treatment.
04 A living system built alongside feature delivery
The platform was evolving too quickly for a one-off style guide. New patterns emerged from active feature work, were rationalised, and then fed back into the shared library.
A dense dashboard-builder flow shows Beacon patterns combining inside complex configuration work.
09 TRANSFORMATION
From screen-by-screen decisions to a shared product language.
Before Beacon, recurring UI decisions risked being remade inside each feature. After Beacon, teams had a shared vocabulary for visual hierarchy, states and interaction behaviour that could be reused across an increasingly varied IoT ecosystem.
The material change was operational: less time spent resolving familiar UI questions, less rework for implementation teams, clearer QA references, and faster progress through milestones. The reported impact was a 70% boost in feature delivery.
A live product screen demonstrating the system at scale: navigation, device context, tabs, feedback and date-range interaction working together.
10 LEARNINGS
Consistency is operational
Visual coherence mattered, but the larger value came from reducing interpretation across design, engineering and QA.
Systems need product pressure
Patterns became stronger because they were tested against live IoT workflows instead of designed in isolation.
Adoption is the real milestone
The strongest signal was not that the library existed. It was that engineering and testing teams treated it as a dependable reference.
