Joseph Patrick Roberts

Designing for a screen is one thing.

Designing for hardware is another problem entirely. Over several product cycles at Copeland, I led UX across five thermostat products — each with its own constraint profile, audience, and set of tradeoffs. Designing across five products in the same ecosystem means every decision either compounds or conflicts — so every decision has to know which one it's doing. Over eight years as the sole designer at Copeland, that has produced five shipped products, two patents, and a design system serving four product lines.

The through-line across all of them: the interface has to do the hard work so the person using it doesn't.

Inheriting a touchscreen that didn't know it was a touchscreen.

When I came onto Touch 2, the existing interface was doing something common and understandable — replicating the visual language of the fixed segment thermostat that sat next to it in the product line. Safe, familiar, wrong.

A touchscreen isn't a fixed segment display with more pixels. It's a different contract with the user entirely. Touch 1 wasn't broken — the menu structure was actually solid — but it wasn't taking advantage of what the hardware could do.

Before any design work, I analyzed Touch 1's strengths and weaknesses, mapped the competitive landscape, and ran interviews across utility partners, contractors, and customers. That breadth mattered — each group had a different relationship with the product and different failure modes to surface.

What I kept

The core menu architecture. Changing navigation that users already understood would have introduced friction without adding value. Good bones are good bones.

What I changed

The visual language, the interaction model, and one pattern that changed everything: the action button.

Every screen has a primary action. In Touch 1, that action was buried or inconsistent. I introduced a persistent, contextual action button that surfaced whatever the most important next step was — save a setting, get help, complete a pairing process, confirm a selection. One button, one job, always in the same place, always relevant to where you are.

Simple in concept. Significant in practice. It gave the interface a consistent logic that users could learn once and apply everywhere.

Designing for what comes next

The less visible decision on Touch 2 was designing the interface architecture to be extensible. At the time, remote sensors and the EIM weren't in scope. I built the UI framework so those features could be added without breaking the existing structure.

They were added later. They fit cleanly. That's the goal.

Hardware and software, decided together

I was involved from the industrial design evaluation phase — running testing, observing, and feeding back on how different hardware form factor concepts affected the UI. On a touchscreen product, the physical and digital decisions aren't separate problems. I was the connection between them.

The Touch 2 also became the industry's thinnest smart thermostat at .77" — a hardware constraint that shaped every UI decision about information density and touch target sizing. And it was the first smart thermostat to win a JD Power award, external validation that the balance between capability and usability landed where it needed to.

The Touch 2 patterns later informed consulting work with Trane's internal design team on their premium touchscreen thermostat — a signal that the work held up outside our own product line.

Solving a problem by moving it somewhere better.

The Equipment Interface Module is designed to work with both indoor and outdoor HVAC equipment — a flexibility most EIMs don't offer. The configuration challenge: how does a contractor tell the EIM what kind of equipment it's connected to?

The obvious answer — configure it at the unit — requires traveling back and forth between the thermostat and the equipment. In a typical installation that means multiple trips, often up and down stairs, often in tight mechanical spaces.

I moved the configuration to the thermostat.

Through a simple pairing and configuration flow, the contractor sets the equipment location and type from the thermostat, once, without leaving. The EIM receives that information and configures itself accordingly.

The product context makes the scale of that decision clearer: 44% of homes have four wires or fewer, but heat pump installations require six. The EIM was built for that gap. And where the leading competitor shipped three separate modules to cover the same use cases, the Sensi EIM did it with one.

Contractors noticed immediately. In field training sessions following launch, two separate distributor groups called out the pairing process independently — specifically that configuring from one location, without going back and forth to press buttons, was what they appreciated most. The launch webinar drew over 180 contractors. That's the design decision validated in the field, by the people it was built for.

Sometimes the best UX is the one that makes you forget you did any UX at all.

Patent: US 12,608,066

When power stealing from the HVAC system is lost, the EIM and Sensi Lite face a choice: show an on-device error, or blank the display and surface device state to the mobile app. I designed the UX logic and notification flow behind that decision. It's the subject of US Patent 12,608,066, awarded April 2026.

32 segments. 3 buttons. A full thermostat experience.

The Sensi Lite was the most constrained product I've worked on. Display: 32 segments. Input: three buttons — up, down, menu/action. Mandate: a complete thermostat experience for a budget-tier product.

This is where design becomes editorial. You can't show everything, so you have to decide what matters most — and then make that decision invisible to the user.

Starting with function, not form

Before touching any design tool, I mapped every function the thermostat needed to support against every constraint it had to work within. Some requirements were obvious. Some were regulatory — fan circulation runtime is mandated. Some emerged from conversations with engineering: fewer relays meant a narrower range of compatible equipment, which was actually a gift — a smaller decision space for the user.

Navigation: flat and cyclical

Hierarchy is expensive when you have three buttons. I kept the navigation flat and cyclical — the user moves through settings in a loop rather than diving into nested menus. The menu/action button serves double duty: a standard press moves through the flow, a long press enters a homeowner settings menu, a second long press accesses the contractor configuration menu.

That last detail matters. Contractor settings can break an HVAC configuration if a homeowner accidentally wanders into them. The long-press-to-long-press pattern keeps those settings accessible to the people who need them, invisible to the people who don't — without removing DIY installation capability entirely. That lives in the app.

Order as logic

With flat navigation, the sequence of settings isn't just organizational — it's functional. Some settings are conditional: if a user configures their system as a heat pump, options like reversing valve direction need to follow immediately. Getting the order wrong means asking users to answer questions before they have context to answer them.

I sequenced settings based on that conditional logic, defaulting to the most common equipment configuration at the top — informed by contractor feedback — to reduce installation time at the thermostat.

Testing beyond the screen

I ran physical installation testing with real users, observing not just how they navigated the UI but how they interacted with the hardware itself. Could they tuck the wires easily? Did the snap-to-baseplate mechanism communicate itself without instruction? Those observations fed directly back into the product — including tweaks to the baseplate design, strengthening the clips and reducing twisting during installation.

Iconography validation

How do you show that the HVAC system is off using only a symbol? I ran guerrilla testing — five icon variants, one question: which one says "system off"? We landed on a square inside a circle, borrowing the stop symbol from media players. Users recognized it immediately. It informed iconography decisions across later products.

Task testing

Usability testing on the mode-switching flow revealed that 23% of users abandoned the task early, most stalling at the three-dot menu button which didn't read as interactive. That finding directly shaped how I labeled and positioned the menu entry point. Auto mode caused hesitation in roughly 30% of users — confirmation that conditional sequencing wasn't just a logical preference, it was load-bearing. After clearing the first task, users navigated the rest of the menu with significantly less confusion, validating the flat cyclical structure once the entry point was clear.

The decisions I lost, and what happened after

Two positions didn't survive stakeholder review. Post-launch data proved them right.

The first: I wanted the fan circulation runtime setting surfaced higher in the menu for homeowner accessibility. It was pushed lower in favor of a mobile-first product vision. The result was added noise for customer service — friction that could have been avoided.

The second: I proposed placing the menu/action button on the opposite side of the display from the other two buttons to reduce accidental capacitive taps. Validation came back roughly 50/50, and hardware engineering preferred an in-line layout for manufacturing simplicity. Accidental taps became a meaningful post-launch issue — significant enough to require a firmware adjustment to partially mitigate it.

I don't tell these stories to relitigate the decisions. I tell them because they changed how I work. I now document testing rationale and design decisions more rigorously so the reasoning is on record regardless of what gets decided. If you're going to lose an argument, lose it with evidence.

Designing for hospitality, distance, and every language at once.

The Verdant VX4 and Line Voltage thermostats serve the hospitality market — a fundamentally different audience than a homeowner. Hotel guests speak different languages, have varying levels of tech familiarity, and interact with the thermostat once rather than repeatedly over years. The design has to communicate immediately, to anyone, without instruction.

The Line Voltage thermostat for the European market pushed this further: text wasn't a reliable tool. I replaced text labels with iconography throughout — a visual language that communicates function without relying on any single language. An icon either communicates or it doesn't. There's no copy to cover for it.

A custom character set, designed for distance

Standard 7-segment displays prioritize simplicity of manufacture over legibility. I designed a high-density segment character set from scratch — angled slices and a flexible grid geometry that renders numbers with far greater clarity at distance, while retaining enough flexibility to display the full alphanumeric character set for status messages and configuration labels.

The primary use case: a guest reading the temperature from across a hotel room. The character set was designed around that moment. It's the subject of a pending US patent.

A consumer app people trust and a diagnostic tool technicians rely on.

Sensi is the main story — a consumer thermostat app rated #1 on iOS through a decade of hardware generations, platform shifts, and new features. WR Connect is the counterpoint: a greenfield commissioning tool for White Rodgers thermostats that turned a technically complex pairing workflow into a QR code scan, and took gold for Most Valuable App at the 2023 ACHR News Dealer Design Awards.

Different users. Different constraints. The same underlying system — and the same obligation to make it coherent.

The foundation, not the feature.

By the time I took ownership of the app design, it had the kind of UI you'd expect from a product that moved fast and prioritized shipping: functional, but patchy. Custom controls where system components would have worked fine. Patterns that made sense in 2017 and never got revisited. A design language that accumulated inconsistencies over years of one-off decisions.

The ratings reflected it. Around 4.3 stars. Not bad, but not a product people were excited about.

The first phase was a ground-up redesign: simplified thermostat control, a cleaner dashboard, consistent system states, a design language that actually felt intentional. Ratings climbed from 4.3 to 4.7 on iOS, 4.4 on Android.

Shipping the redesign was the easy part. Keeping it good over time — that's the harder problem.

The platform migrations to SwiftUI on iOS and Material Expressive on Android were the opportunity to actually fix it.

The practical reason: Apple and Google ship OS updates that change system behaviors, components, and visual defaults. Custom components don't get those updates automatically. System components do. For an app supporting hardware going back to 2014, that matters more than it does for most. Platform-native components absorb OS changes automatically — custom ones don't, and on a lean team that maintenance overhead compounds fast.

The design reason: system components bring a lot for free. Accessibility behaviors, dynamic type support, dark mode, haptic patterns, expected interaction models. Custom components have to earn all of that separately, and they often don't. Dark mode couldn't be a standalone project — the team was too lean and the backlog too real. Moving to platform-native made it a side effect: every migrated screen got dark mode as part of the deal, not as a separate pass.

There's a philosophy underneath this: users spend more time in other apps than they do in ours. It's in our interest to follow the patterns that already work. That bandwidth is better spent on the decisions that are genuinely unique to Sensi.

How we're doing it

This isn't a big-bang rewrite. Feature-freezing a shipping product to modernize everything at once isn't realistic, and it's nearly impossible to justify to stakeholders who see platform migration as cosmetic work.

The strategy is screen-by-screen: when a new feature touches a screen, that screen gets migrated. New work gets built in SwiftUI or Material Expressive from the start. Legacy screens get updated when there's a natural reason to open them.

To make sure feedback came from the right cross-section of users, I built a structured beta program with filtered recruiting — across OS, hardware tenure, control preference, and accessibility needs. Not just the loudest people who opt into betas. The improvement from 4.3 to 4.7 didn't happen by accident.

It's slower, but sustainable. Every migration is tied to something real rather than being pure overhead. Two birds, one stone, every time.

When the app and the device contradicted each other.

The legacy app used full-screen color to communicate HVAC mode. Orange for heat, blue for cool, neutral for passive. The intent was right: mode state is important information, and making it ambient rather than buried in a label is good instinct.

The execution had three problems.

The solution: move the color to the number.

Instead of the background adopting the mode color, the displayed temperature adopts it. The information is still ambient — sitting on the most prominent element on the screen — but surgical rather than wholesale.

One change. Three problems solved. Accessibility contrast is predictable. Dark mode works without special casing. The app and the thermostat now speak the same visual language. A user who glances at their device and opens the app sees the same system communicating the same information.

Accessibility
A saturated orange or blue background creates contrast failures for text and UI elements sitting on top of it. WCAG compliance becomes a moving target when the background color is dynamic.
Dark mode
There's no clean dark mode equivalent for a full-bleed orange screen. Desaturate it and it becomes unrecognizable. Leave it as-is and it doesn't work. Neither is acceptable.
Consistency
The Sensi Touch 2 thermostat already used a better visual language for mode communication — temperature numbers turning blue when cooling, orange when heating. Independent reviewers called it out specifically, noting it made it easier to know exactly when the HVAC was running. The app and the device were telling two different stories to the same user.

Removing a button that was doing someone else's job.

The installation flow is one of the highest-stakes experiences in the app. A homeowner selecting the wrong wires in the wirepicker — the screen where users identify which wires are connected to their thermostat — means the app infers the wrong equipment configuration. Getting it wrong has real consequences.

Which makes clarity here non-negotiable.

The legacy flow had two buttons at the bottom of every screen: Previous and Next — a pattern inherited from early mobile design.

Modern iOS and Android navigation already provides a reliable back action. It lives in the navigation bar at the top of every screen. Users expect it there. Adding a second back button at the bottom creates visual clutter, splits attention, and buries the primary action between two competing controls.

I removed Previous entirely.

With the redundant button gone, Continue became the clear primary action. The help link moved from a small text link buried below the buttons to a proper tappable action above Continue. The progress indicator moved into the native navigation bar, showing install step position without taking up screen real estate.

App Store reviewers picked up on it without prompting. One long-term user called out the step-by-step guidance as "a little touch that made me fall in love with it." That kind of feedback doesn't come from the interface getting out of the way by accident.

Users bring mental models from every app they've ever used. Fighting those models is expensive. Borrowing established platform patterns means reliable behavior for free — and the testing budget goes toward the decisions that actually need it.

A content surface that couldn't feel like an ad.

Sensi partners with utility companies to offer energy demand-response programs — enroll and save money during peak usage hours. Good programs. Low enrollment because users had no reason to go looking for them inside the app.

There was also no good way to surface new features or products to existing users. The thermostat card wasn't the place for it.

Spotlight was the answer: a named, dedicated section on the home screen, separate from the thermostat card, carrying partner content, product news, and savings opportunities. New screen, built native from the start.

The hard constraints

The content isn't mine. Card copy is written by Copeland's marketing team in collaboration with energy partners. I don't control headline length, offer details, or partner logos. The design system has to handle all of that while still feeling like Sensi.

We lose the user at the tap. Learn More opens a partner-owned enrollment flow in an in-app browser. The card has one shot to inform and motivate before the handoff. It can't rely on the next screen to do any of the work.

And it can't feel like an ad. Sensi users trust the app to be a neutral utility tool. The moment Spotlight reads like a banner, that trust takes a hit.

Named section
Spotlight is a named section, not injected into the existing feed. Users can see it, understand what it is, and choose to engage. The thermostat card stays untouched.
Partner attribution
Partner logos sit at the top of every card. Users should know the offer is coming from their utility company, not from Sensi. Transparency builds more trust than white-labeling the content.
Consistent CTA
The Learn More CTA is always the same style and position regardless of content type. Once you've tapped one Spotlight card, you know how all of them work. Expiration dates shown explicitly when relevant. No dark patterns.
Soft notification
A count badge on the section header acts as a soft notification — no push alert, but users get a signal when something new is waiting.

What testing revealed

I tested the card design through iterative copy development and in-depth user interviews, running multiple rounds before launch. The biggest risk wasn't the design — it was the content. Working directly with energy partners to get the messaging right meant the cards communicated real program value rather than generic marketing copy. The result was content that informed without overselling, which is the only way a trust-dependent utility app can carry a content surface.

Energy program enrollment increased measurably after launch. Specific numbers are under NDA.

The metric I watch most closely: app store ratings held. 4.7 iOS · 4.4 Android, flat through the Spotlight launch. For a content surface added to a utility app, no regression is a win. It means users didn't experience it as an intrusion.

Spotlight also created a repeatable integration path for future partners without needing to redesign anything. The system does the work.

Greenfield design for a high-stakes technical audience.

Not all mobile work is maintenance. WR Connect was a blank canvas — no legacy to inherit, no existing users to protect, no design debt to carry. Just a hard problem and the freedom to solve it correctly.

The audience was different too. Not a homeowner who installs a thermostat once and opens the app twice a year. A contractor configuring ignition control boards under time pressure, often in tight mechanical spaces, with a system that cannot be powered on if the configuration is wrong. The stakes of a bad interaction aren't frustration — they're damaged equipment and a return visit.

The problem: configuration is traditionally done through dip switches or cryptic 3-digit codes on the board itself. Both methods require the technician to be physically at the board, potentially with the system live, reading documentation designed for engineers rather than installers.

There's a compounding risk: an incorrect configuration can damage components. The configuration has to be right before the system comes on, not after.

The constraint that drove the solution

HVAC systems are typically off during installation. Any configuration method requiring a powered board was a non-starter — that ruled out Bluetooth for initial setup and pointed directly at NFC.

NFC payload delivery let the contractor configure the board entirely from the app: guided, validated, error-checked, then transferred with a tap. No power required. No cryptic codes. No dip switches. The complexity moved from the physical board into the app, where it could be managed intelligently before anything touched hardware.

Once the system was powered, Bluetooth opened a diagnostic channel. The same app that configured the board could now monitor it in real time — live fault codes, system status, operational data. One tool, two phases of the technician's workflow, solving a different problem at each phase.

How it landed

WR Connect received a Gold Dealer Design Award from ACHR News. More telling: the core functionality was absorbed into Copeland Mobile, a broader platform serving the full product portfolio. The product didn't survive as a standalone app. The work did.

Four products. Two domains. One design system.

When companies grow through acquisition, their software tells the story. Different visual languages, different interaction patterns, different component behaviors — each one an artifact of a team that solved their own problem, their own way, without knowing they'd eventually need to work together.

Copeland's web application portfolio was that story. Four products inherited from different companies, serving different industries, built at different times by teams optimizing for shipping rather than coherence. The UI worked — well enough that the business kept running, well enough that nobody wanted to risk touching it.

My job was to change that without breaking anything that mattered. A design system is just a shared language. The goal is making sure every product in the portfolio is speaking it.

Unifying Copeland's Product Suite.

Building Kelvin — a design system for four products, two domains, and a user base that can't afford mistakes.

The Products

HVAC Management
Sensi MTM
Bulk thermostat control for small businesses and property managers handling HVAC across many locations without visiting each one.
Hospitality HVAC
Verdant Thermostat Manager
The software backbone for hospitality properties. Hotel operators configuring room temperature schedules, managing setpoint limits, monitoring system status across a property. The legacy interface had three structural problems worth naming: content was dense and unmanageable without collapsible columns, actions were scattered across the UI rather than consolidated in a predictable location, and the layout didn't adapt across devices. Those three things became the design brief.
Cold Chain Retail
Copeland Connect+
Cold chain monitoring for grocery refrigeration. Operators monitoring units, receiving alerts, managing temperature compliance across store locations. Before any design work, I ran user discovery interviews to capture authentic operator experiences — understanding what they needed, where they succeeded, and where the existing UI created friction. That research directly shaped the Connect+ redesign direction and the initial prototypes for iterative testing.
Cold Chain Medical
Copeland TempTrak 6
Cold chain monitoring for medical and pharmaceutical refrigeration. The highest-stakes product in the portfolio — temperature excursions here don't mean spoiled food, they mean compromised vaccines, medications, and biologics.

Revenue-protecting inertia is a real force.

The fragmentation wasn't careless. Each product was built to work — and it did, well enough to generate revenue, well enough to retain customers, well enough that proposing a significant UI investment always lost to the next feature request.

That's a specific organizational dynamic worth naming. When software is making money, the business case for fixing its UX is always harder to make than the business case for new capabilities. The cost of inaction is invisible. The cost of change is obvious. So nothing changes.

Year after year, features get bolted on through the path of least resistance. In TempTrak, this produced multiple ways to accomplish the same task — each one the remnant of a different team's solution to the same problem, all preserved because removing any of them might break someone's workflow. The UI accumulated complexity the way a city accumulates one-way streets: each decision made local sense, the aggregate made navigation unreasonable.

These users cannot afford to be confused.

The stakes vary across the portfolio, but they're never low.

This is why the "if it ain't broke" culture persisted. Caution made sense. The cost of being wrong wasn't a bad review — it was a cold chain failure in a medical facility.

Any modernization strategy had to account for all of this. Not work around it. Account for it.

Named for the man who figured out how to measure temperature.

The design system is called Kelvin — named for Lord Kelvin, whose foundational work on temperature measurement underpins the domain these products operate in.

Kelvin is built on a themed shadcn foundation with custom components developed for the specific interaction patterns that appear across the portfolio. The goal isn't visual homogeneity for its own sake — it's a shared language that makes each product feel like it belongs to the same family while serving its own user context.

What Kelvin addresses:

  1. Consistent visual language across all four products.

    Typography, color, spacing, component behavior. A user moving between MTM and TempTrak should feel orientation, not disorientation.

  2. Shared interaction patterns for overlapping functionality.

    Alarm management, schedule configuration, sensor status — calibrated appropriately for the different stakes of each context.

  3. Production efficiency for development.

    Shared components mean less rebuilding, fewer inconsistencies introduced by parallel implementation, and a clearer path for future feature work.

  4. Accessibility built in from the component level.

    Dark mode, dynamic type, contrast compliance. The kind of thing that's expensive to add to custom components and free from a well-built system.

It's okay to move the cheese, as long as you put it somewhere better.

The work is under NDA. What follows is the rollout strategy and the patterns validated in production.

The standard design system playbook — freeze features, migrate everything, relaunch — doesn't work for a user base with regulatory SOPs and hardware dependencies. The risk profile is too high and the organizational will for that kind of disruption doesn't exist.

Instead, Kelvin rolls out through a parallel track approach: small, non-critical features built in Kelvin running alongside the existing interface. Users can try them, give feedback, and continue using what they know. No forced migration. No retraining before the new experience has proven itself.

This strategy does something the big-bang approach can't: it generates cross-platform intelligence. A component validated in MTM — a lower-stakes HVAC management context — informs how the same component gets calibrated for TempTrak's higher-stakes environment. Shared patterns, validated at different risk levels, in sequence.

The feedback has been clear. Users aren't asking "why did you change things." They're asking for more, faster. Task completion is quicker — clearing alarms, setting defrost cycle schedules, managing configurations. The things that used to require navigating a tangle of overlapping paths now have a clear, direct route.

Moving the cheese worked because the new location is better. That's the only acceptable reason to move it.

Alarm management Across cold chain products, alarm acknowledgment is a frequent, high-stakes task. The legacy interfaces handled it inconsistently depending on entry point and feature version. Kelvin establishes a single, predictable pattern that works the same way regardless of how you got there.

Schedule configuration Setting defrost cycles, temperature schedules, and setpoint controls involves similar underlying logic across MTM, Verdant, and the cold chain products — but the legacy implementations looked and behaved differently in each. A shared scheduling component with product-appropriate configuration reduces cognitive load for users who operate across products and development effort for new schedule-related features.

Sensor and device status Hardware status communication — connected, disconnected, alert, offline — appears across all four products. Kelvin standardizes how device state is communicated visually and behaviorally, so users develop reliable expectations regardless of which product they're in.

Kelvin is a foundation, not a finish line. As parallel track validation continues, the rollout will expand to more complex workflows — eventually including the SOP-critical flows in TempTrak that require the most careful transition planning.

The goal isn't a redesigned product. It's a portfolio that can keep evolving without accumulating the kind of debt that requires another ground-up intervention in five years.

What's visible is the outcome: customers asking for more of something they used to resist. That's the real before and after.

Good design work doesn't come from talent applied domain by domain.

It comes from treating every product, every constraint, and every team as part of the same system — and designing accordingly.

The work shows where that produced something. This chapter is about the methodology underneath — how it formed, what it holds, and where it shows up when there's no finished product to point to.

Concepts

These principles didn't come from a workshop. They came from shipping things that couldn't be patched once they left the building, from watching users encounter interfaces that assumed too much, and from working inside organizations where the loudest voice in the room was rarely the user's.

The interface has to do the hard work. Not because it's a principle I hold — because I've watched what happens when it doesn't.

The organization is part of the system. Technology developed for one product line shouldn't stay there if it solves a problem somewhere else. A wireless protocol proven in Verdant's hospitality hardware found its way into Sensi's room sensor architecture — not because the products share an ecosystem, but because the expertise already existed and the problem was the same. The same logic applies to platform decisions, component patterns, and retail packaging. When knowledge compounds across products instead of staying siloed, the whole portfolio gets stronger. That's not a design principle — it's an organizational one. But it's inseparable from the work.

Designed for development. Before a feature gets designed, it gets interrogated: Does it work in the tech stack as is? Can it ship in stages? Is it reusing patterns — not just visual styles — from elsewhere in the product? Developers build in the path of least resistance. The job is to make sure that path leads somewhere good.

Formation

I came up through brand design. Identity, packaging, print — work where the canvas is fixed and every decision has to earn its place, and where the artifact ships to a printer and cannot be patched. That instinct didn't leave when I moved into product. It just found new constraints to work inside: hardware, firmware, regulatory requirements, OEM relationships. Brand design taught me to treat every touchpoint as part of the same product. Product design taught me that the product is bigger than the screen. Each discipline sharpened something the last one couldn't — and the combination is unusual enough that it keeps proving useful.

US 12,608,066 — Low Power Detection
(Awarded · 2026)
Patent pending — Segment display character set

Practice

I built a portable demo kit because the sales team needed to show the product somewhere without a power outlet. I build self-serve files so marketing and support teams can update screen content and export hardware and app screenshots without routing every request through a designer. I consulted with Trane's internal design team on their premium touchscreen thermostat — an extension of the Touch 2 interaction model into a different product line, by a different company. I am currently advocating for a shared retail packaging system across the Sensi and Verdant product lines — a manufacturing and brand coherence argument that has nothing to do with any single product and everything to do with how the portfolio presents itself as a whole.

None of this has a UX rationale. All of it comes from the same place the work does.