Product Design Intern
ROLE
Product Design Manager
Product Design Buddies
Product Managers
UX Researchers
Engineers
TEAM
May 2025 - June 2025
4 Weeks
TIMELINE
ORGS
Smart Infrastructure – Brightly Software (BSW)
Product Management > Product Design > Asset Management Pod
BACKGROUND
Brightly’s SaaS enterprise suite, used across education, government, and manufacturing, was implemented with the Lumos Design System and slated for migration into Siemens’ Element Design System. Element is an object-oriented design framework intended to standardize components, tokens, and accessibility across Siemens’ product ecosystem.
Problem Space
Rather than a one-to-one mapping, migrating Brightly’s products required extending Element to support Brightly-specific components, complex asset workflows, and platform conventions that Lumos already enabled. The work involved identifying gaps in Element’s component library, tokenization, and interaction patterns to ensure full coverage for enterprise use-cases.
Solution
As a product design intern in the Asset Management pod, I audited Lumos components and workflows, defined Element's extensions and token mappings, and prototyped reusable, accessible UI patterns using OOUX principles. Deliverables included a component backlog, conversion prototypes, and documentation to align design and engineering for implementation.
ROLE & TEAM COORDINATION
I worked within the "Bad Assets" design team, collaborating daily with my Product Design Manager and fellow designers, while also partnering cross-functionally with UX researchers, engineers, and stakeholders in Sales and Client Success to ensure our solutions balanced user needs, technical feasibility, and market realities.
My primary responsibility was to audit Brightly’s existing Lumos design system and map its components and interaction patterns to Siemens’ Element design system, identifying gaps and designing new, scalable components to support Brightly’s product workflows.
UNDERSTANDING LUMOS & ELEMENT
We had to understand how two design languages approached structure, interaction, and scalability.
Design systems are shaped by the contexts in which their products operate, from who uses them, to how frequently, to under what conditions. Without analyzing these foundations, a direct component-to-component translation would risk overlooking critical differences in accessibility needs, interaction complexity, and workflow flexibility. This analysis ensured that our extensions to Element would not only match Lumos functionally, but also support the broader range of real-world users served by Brightly’s software.
Where did our insights come from?
Technical conversations with Design System Engineers
Platform audit sessions with Product Designers
Usability discussions with UX Researchers
Lumos
Lumos was built to support Brightly’s broad SaaS portfolio spanning manufacturing, education, healthcare, and government — products used daily by maintenance technicians, facilities staff, administrators, and operations managers with varying levels of technical fluency. As a result, Lumos emphasized accessibility, clear affordances, and flexible data-entry patterns to accommodate diverse environments, device types, and user skill levels.
Element
In contrast, Siemens’ Element design system was originally developed for software tied to specialized machinery and infrastructure interfaces, where users are typically trained operators working in controlled environments. Because these tools assume domain expertise and task familiarity, Element prioritized structured layouts, dense information presentation, and standardized industrial UI patterns over broad accessibility and flexible interaction models.
Understanding these systemic differences helped us frame our work not just as visual mapping, but as an effort to adapt Element to support a wider range of users, contexts, and operational realities present in Brightly’s products.
ALERTS, TOASTS, & SYSTEM FEEDBACK
Aligning how the system communicates status, errors, and success states across workflows.
I mapped Lumos alert and toast patterns to Element’s feedback components, identifying gaps in severity levels, placement behavior, and dismissal logic. I proposed extended variants to support maintenance-specific use cases like form validation, background process updates, and task completion confirmations.
BUTTONS
Standardizing action hierarchy and interaction behavior across primary workflows.
I analyzed how Lumos used button styles, sizes, and states across forms and task flows, then mapped these to Element’s button system. Where mismatches existed, I documented usage rules and proposed additional variants to better support high-frequency actions like saving, assigning, and submitting work.
CARDS
Translating content grouping patterns into scalable, reusable container components.
Lumos frequently used cards to organize asset, work order, and dashboard information. I evaluated these patterns against Element’s structure and proposed card variations that could support richer metadata, status indicators, and action affordances without breaking system consistency.
CHECKS, RADIO BUTTONS, & TOGGLES
Standardizing selection controls to better support configuration and status-driven workflows.
I analyzed how Lumos handled binary and multi-select inputs across settings and forms, then aligned these patterns with Element components. I also documented interaction states and accessibility considerations to ensure consistency across use cases.
DATE & TIME PICKERS
Adapting scheduling inputs to support maintenance and work order planning needs.
Because scheduling is central to Brightly’s products, I mapped Lumos date and time selection patterns to Element components and identified missing behaviors like range selection and clearer time formatting. I proposed enhancements to ensure the system could handle real-world scheduling complexity.
INPUT FIELDS
Aligning form inputs to support complex data entry while maintaining accessibility and clarity.
I reviewed Lumos input types and mapped them to Element’s form system. I identified gaps in validation states, helper text behavior, and field grouping patterns, then proposed updates to support maintenance workflows with high data variability.
REDESIGNING PRODUCT SCREENS
To validate that our combined components worked beyond isolated UI states, we implemented them within full Brightly product screens and core workflows.
This step ensured that the modified Element components could support real maintenance use cases (including work order creation, asset updates, and scheduling flows) without breaking layout structure, hierarchy, or usability. By placing the updated buttons, inputs, alerts, and scheduling controls into complete screens, we tested spacing systems, interaction feedback, accessibility states, and information density at scale. These examples demonstrate how the extended system not only matched Lumos functionality, but improved consistency and long-term scalability across Brightly’s platform.
IMPACT & FEEDBACK
My work laid the groundwork for Brightly’s company-wide migration into Siemens' design system.
Our work created a clear migration path for Brightly products to move from fragmented, product-specific UI patterns to a unified, reusable component library. The components and usage guidance I defined directly supported high-frequency maintenance workflows such as asset creation, work order management, and preventive maintenance scheduling for Brightly’s SaaS enterprise suite.
Team & Mentor Feedback
— Erich Shreck, Senior Product Designer @ Brightly Software, a Siemens Company
Beyond formal feedback, this project positioned me as a strong cross-functional partner. I collaborated closely with product managers, engineers, and manufacturing subject-matter experts to balance real-world maintenance practices with the constraints of a scalable cloud platform.
Overall, this project helped me see how design systems function as long-term business infrastructure, not just visual frameworks. By creating a sustainable path for Brightly’s products to align with Siemens’ Element system, we contributed to greater consistency, reduced technical redundancy, and supported the company’s broader platform unification after acquisition. Knowing that our component decisions could influence development efficiency, brand trust, and scalability across multiple products reshaped how I think about the responsibility of system-level design.
Reflections & Takeaways
Take Initiative in Ambiguity
During the design system migration, I proactively identified and resolved gaps beyond my scope, like undocumented components, inconsistent patterns, and missing accessibility specs. By prototyping and documenting solutions, I reduced design debt and strengthened system alignment. This rigor proved essential during the later transition to Siemens’ iX Design System, where my audits served as a foundation for closing key gaps and accelerating large-scale integration.
Communicate with Purpose Across Teams
Collaborating with designers, engineers, and PMs across a 12-hour time difference (NA & APAC) reinforced the principles of Brightly’s global transformation. I learned to balance asynchronous collaboration—using detailed documentation and Figma annotations—with strategic live check-ins to resolve blockers efficiently. This experience reinforced that strong communication in distributed teams isn’t just about frequency, it’s about precision, empathy, and maintaining momentum across continents.
Systems Thinking Scales Design Impact
Contributing to a design system migration shifted how I think about design beyond the screen. Instead of solving isolated interface problems, I learned to think in terms of reusable patterns, semantic tokens, and the relationships between components across an entire ecosystem. This systems-level mindset helped me design with scalability in mind—considering not just how something looks or functions today, but how it can evolve to support future products and teams in the future.