Project brief

Zentra

A retrofit access-control product and design system for multifamily properties.

Role
Senior UI Designer
Organization
Allegion
Period
2021–2023
Scope
Product interface, creative direction, and design systems
Status
Ongoing when documented / Retrospective

Brief

Allegion was expanding from access-control hardware into software for multifamily properties. I helped establish Zentra’s interface direction and design-system foundation across web, iOS, and Android while supporting the new brand as a creative director. The work focused on making a complex retrofit access-control system easier to understand without ignoring platform conventions or hardware constraints.

Operating context

Many existing apartment properties used one electronic system for perimeter access and traditional locks for individual residences. Property owners told the team they wanted a retrofit path that could unify access without requiring the network infrastructure common in new construction.

Zentra started from PureAccess, an Isonas web product built for commercial access control. The existing interface used MUI components and icon-heavy navigation, but research showed that property staff struggled with its language and discoverability. The team also had to support integrators who commissioned locks, residents who used mobile credentials, and staff who managed one or more properties.

Constraints

  • The product depended on Schlage hardware and an incompletely documented lock SDK.
  • Product direction and scope changed throughout the work.
  • Mobile developers needed usable interface definitions while resolving hardware integration problems.
  • Web, iOS, and Android each needed to feel like Zentra without ignoring platform conventions.
  • The team was modernizing an existing product rather than starting with a clean architecture.

Responsibility

I owned interface design and design-system direction across the Zentra web and mobile products. I created the color palette, refined parts of the logo concept and mission language, guided the brand’s product expression, and structured the Niwa design system.

The marketing and leadership teams partnered with Warehouse21 on the brand. Warehouse21 contributed logo directions, selected the Outfit typeface, and proposed the Zen-garden line motif. I worked with researcher Ginger White, interaction designer Dan Hernandez, product partners, and individual developers. Product and engineering owned product scope and implementation; I influenced those decisions through research, specifications, and design reviews.

Decision 01 — Share the brand, respect each platform

Condition

Leadership wanted Zentra to feel native on web, iOS, and Android while maintaining one recognizable product identity.

Decision

I structured Niwa around a shared core with extensions for platform and communication needs instead of forcing one component model across every surface.

Rationale

Shared tokens and brand assets could stay consistent while navigation, type, controls, alerts, and system behavior followed the conventions of each platform.

Tradeoff

Multiple libraries required more governance than one universal kit. The team had to define which decisions belonged in Core and which belonged to a specific platform.

Evidence

Niwa documented one Core library plus dedicated iOS, Android, marketing, and print libraries.

Decision 02 — Replace icon knowledge with explicit controls

Condition

Research and recorded product sessions showed that property staff did not understand several navigation icons or know how to expand the collapsed PureAccess navigation.

Decision

I simplified the side navigation, added a property switcher, moved profile controls to a predictable location, and replaced important icon-only actions with labeled controls.

Rationale

Property staff could identify common actions without learning an internal icon language. Integrators and staff who managed several properties also gained a clear way to change context.

Tradeoff

More explicit labels used additional interface space, but they removed the need to decode unfamiliar icons.

Evidence

The redesign addressed the language and discoverability problems found in customer research and product-session review. We did not capture a reliable before-and-after task-completion metric.

Decision 03 — Use native mobile patterns under deadline pressure

Condition

Mobile developers needed interface decisions while spending substantial time on the lock SDK and commissioning workflow.

Decision

I used standard iOS and Android patterns as the foundation for the early mobile work, then applied Zentra’s brand through platform-specific Niwa libraries.

Rationale

Familiar controls reduced the number of custom behaviors the team had to define while hardware integration remained the larger technical risk.

Tradeoff

The first mobile experience remained visually and behaviorally incomplete. It needed customer validation and focused refinement after the core commissioning and credential workflows stabilized.

Evidence

The mobile design files used stock platform elements for the initial commissioning and credential flows.

Decision 04 — Specify interaction quality, not only appearance

Condition

The legacy web product’s flexibility created ambiguous states and discoverability problems.

Decision

I documented component states, keyboard shortcuts, and tab order for redesigned web workflows.

Rationale

The specifications gave developers concrete interaction and accessibility requirements while making common workflows easier for newer users and more efficient for experienced users.

Tradeoff

Detailed specifications took more time to maintain as product direction changed, but they established explicit requirements for implementation.

Evidence

The design artifacts included the expected states and keyboard behavior. This retrospective does not have production accessibility-test results, so it does not claim verified conformance.

System specification

Niwa separated shared product identity from platform-specific behavior:

  • Niwa Core: Color, icons, illustrations, and shared design tokens.
  • Niwa iOS: iOS type, system colors, alerts, navigation, and accessibility considerations.
  • Niwa Android: Android type, system colors, alerts, floating actions, and system navigation.
  • Niwa Marketing: Digital marketing assets, email templates, and product communication.
  • Niwa Print: Manuals, resident materials, and other physical assets.

The web work used Tailwind CSS as a flexible implementation vocabulary for the redesigned interface. The mobile libraries retained native platform patterns instead of attempting to make iOS and Android identical.

Validation

The team interviewed multifamily property portfolio owners about retrofit access control. I also reviewed footage of property staff using PureAccess and used those observations to identify language, navigation, and discoverability problems.

The research supported the web navigation changes and the broader retrofit product direction. The available evidence does not include measured task completion, error rates, accessibility results, or adoption for the redesigned product.

Outcome

The team established the Zentra brand direction and began replacing PureAccess workflows section by section. Niwa created a shared foundation for web, iOS, Android, marketing, and print while preserving platform-specific decisions.

Zentra was still in progress when this work was documented. Without reliable adoption or quality metrics, the strongest evidence is the system structure, the detailed interaction specifications, and the way research findings changed the navigation model.

Revision notes

This project reinforced that interface quality depends on team focus and decision clarity as much as individual design craft. Incremental improvements helped developers move forward, but a more stable product vision would have reduced rework across brand, web, and mobile.

I would now test the mobile roles before expanding management features to tablets. Property managers, maintenance staff, and integrators move through properties differently, so an iPad-specific product should follow observed tasks rather than device availability alone.

I would measure navigation comprehension, time to change properties, commissioning errors, mobile credential setup, keyboard completion of common web tasks, and the adoption of shared Niwa components across platforms.

Contributors and artifacts