Keys screen.png


8-month development of industry-first access sharing architecture to support large residential buildings

Output: New data model (system architecture), completely redesigned web product 

Timeline: August 2017 - April 2018 (8 months)

Weekly team: Si Dhanak (PM), Misha Ponizil (Eng) , Jordan Sorenson (Eng), Deepak Bapat, Jonathan Kieliszak (Eng)

My role: UX Research and Design, Information Architecture

In August 2017, I was initially tasked to bring a grouping feature to our existing product. These features required a completely new vision for access management and I led our entire software org through a 5-month design process. 

Where we began: How do we improve our MVP? We needed to understand our customers.   

In December 2016, two frontend engineers had singlehandedly built an MVP called  "Latch Manager" for property managers to add and remove tenants from their buildings. This "MVP" quickly became our product offering and our customers relied on it to provide access to everyone in their buildings. However, we didn't have a collective understanding of who was using our system or how they were using it.

April 27, 2017: Let's get our ideas out!

Two weeks after joining Latch, I felt entirely overwhelmed by how many different ideas there were to solve different problems. Our Operations and Support teams had ideas to address customer friction points, our engineers wanted to solve technical issues they had run into and our product team had already prioritized features for the next half. We didn't have a collective understanding of what ideas there were and what problems they were solving. To help our company develop a shared understanding, I organized a workshop where everyone defined a problem and a solution using a storyboard template. 


June and July: Understand our customers and drawing insights

I spent about 20% of my time with my UX Researcher hat on May, June and July spending time with our different stakeholders, usually doing contextual inquiries in their offices to understand their jobs and workflows. In July, I collected ~20 interview transcripts and organized a day-long interpretation session, where our engineering, ops, support and product teams read what our customers said and interpreted important issues and facts. 

 Contextual inquiry writeup with verbatim notes and bullet-pointed observations.

Contextual inquiry writeup with verbatim notes and bullet-pointed observations.

How would our team understand this research together? 

Research interpretations.png

Office affinity boards: Grouping insights into themes

20170711 Affinity diagram.jpg

Main findings: 

  • Property managers spend a large percentage of their time (50%+) outside their offices, letting contractors and other people in their buildings.

  • Access Control is typically outsourced to security integration firms. Property Managers have often not used access control software themselves.

small vs large apartments.png

Major problem: our system didn't work for our target customers with large buildings.

Latch had been originally designed for apartment unit doors, where a resident uses the Latch app to open their unit door and can share access guests. As our company developed its market strategy, we began developing a suite of products to be the complete access control solution for apartments. And in July 2017, our CEO and Director of Product chartered our H2 company-wide mission: become the complete solution for the Multifamily market segment. This meant our hardware products would be on every door and had to work for every stakeholder in the building. 

Problem: Customers had to assign each door to each person

 I designed a new door selection system but customers still found it very tedious!

I designed a new door selection system but customers still found it very tedious!

Understanding the context of these problems:

During contextual interviews, our customers had pointed to the same issue with their unique perspectives:

“There’s two things before I spend all this money on apartment doors: (1) I gotta be happy with this system, number one. From a software perspective, it’s all the users stuff - with the adding and removing simplicity. And (2) the grouping thing — it would be absolutely asinine to add 40-50 brokers each time we want to show and rent an apartment. If you guys show me this two months from now, and it’s great, then I’ll want to roll out Latch across all my apartments.”

- VP at property management firm

“I have to do it manually. It’s very time consuming and I’m very likely to create an error. For example, I moved in 16 people last month, but missed 1 person. I entered her information and she got the sign-up (email) but I forgot to assign her locks. I felt unprofessional.”

- Senior Property Manager at real estate owner

Competitive analysis

How did our customers solve this problem today? The contextual inquiries gave some insight into how our customers used existing access control systems to manage many different kinds of people across 100+ doors. 

2017.09.06 Prometheus access level research.jpeg

ICT Protege - "Access levels"

An access levels is a group of doors and the schedule each door can be unlocked.

This customer has a dedicated desktop work station where employees check out key fobs for vendors, themselves, residents, etc. Each key fob is "programmed" with the right access level.

20170607 understanding clearances - staff clearance.jpg

C•CURE 9000 - "Clearances"

A clearance is a group of doors and the schedule each door can be unlocked.

This customer has architected 11 clearances that can be combined in different ways, giving the right security to almost 1000 stakeholders in their office: maintenance, vending, employees, executives, contractors, vendors, etc.

I was tasked to figure out Latch's own grouping feature so we could meet Sales expectations

I began designing the Latch version of Access Levels / Clearances, and simply called it "door groups". This seemed like a pretty straightforward design problem and a tough but also straightforward engineering challenge. 

 Rough wireframe showing grouping functionality

Rough wireframe showing grouping functionality

I designed a phased approach for implementing Door Groups.

Problem: Designing the grouping feature required re-evaluating our existing access architecture

The challenging aspect of the grouping feature was figuring out how it would fit into our existing access architecture. Our Backend Engineering team had spent the summer of 2017 developing a solution to neatly organize different permissions, including access, by predefined roles:  'Account Owner', 'Administrator', 'Operator', 'Installer', 'Occupant', 'Guest'.

User roles.png

How would access be created via these "Roles"?

I spent many long evenings trying to figure out flows that would support all the different stakeholders.

I tried synthesizing every access requirement: 

Figuring out how to create access for each stakeholder raised really difficult questions, for example:

  • What if a 'resident' was also invited as a 'guest'?

  • How would live-in management staff (like a super) be given access?

  • Can temporary access codes be given to people with "permanent" access?

Struggle: There wasn't a coherent way to create access.

Our customer research showed 'User Roles' wouldn't work

  • Property Managers didn't want de facto access because it was a liability. Contextual inquiries showed that they only gave themselves limited access and never to a private unit unless requested by the resident.

  • There were cases in which people needed multiple 'Roles', for example: the live-in super is both an Administrator and Occupant.

What was our vision for access? We needed a new information architecture.

After such significant cost developing 'User Roles', the Backend team wanted us to envision the complete architecture solution that would work for every stakeholder. They wanted us to be sure before ripping out the their new system. One of the first challenges we needed to address was internal: our Design and Product orgs had different visions of access: Design worked on the Latch app (iOS and Android) and Product worked on Manager apps. 

September 16: Can we unify our vision for how 'residents' and 'managers' create access? 

We brought Design to the table to whiteboard out how access would work on both the Latch app and Manager app. This was one of those amazing moments where everything clicked.

 Discussing how access could be created.

Discussing how access could be created.

What would a unified information architecture look like? 

We had a pretty good idea of all the functionality we needed but didn’t know what the right object model should be. Where would all this functionality go? Who needed to use it? 

  • Whether person would use temporary code, permanent code, or app

  • Whether person needed a Latch account

  • The schedule a door can be opened

  • When access begins and ends

  • Whether access can be shared

  • Whether a photo is taken at a dor

  • Whether a door accepts codes

I abstracted this functionality into simple UI objects and began working out functionality workflows.


  1. We need to use a template / metaphor to distinguish different accesses. 'Access', we realized, was too abstract and nebulous.

  2. Our power hierarchy was different pieces: (1) Access grantors and (2) Access holders

I iterated based on these insights, creating an architecture with "passes" representing access.

In this architecture, Pass Granters could choose a 'Pass' type ("Day", "Guest", or "Member") and then add door groups or single doors to that Pass. 

Second access architecture.png

Epiphany: What if a 'group' and a 'pass' were the same thing?

 It was still really cumbersome to create access because it required selecting groups or single doors each time. Other access control systems worked this way, but this prevented managers from managing access directly by group. If we made the door grouping and the 'pass' the same thing, then creating access was as simple as giving someone a pass! 

I redeveloped the Information Architecture based on Access = Pass

Key advantage: Now people can be managed for each pass. The pass becomes both a grouping of doors and a grouping of people. 

After an arduous few months, I presented "Passes" to our entire software team and CEO and got sign-off to proceed with this new access architecture. 

2017.10.31 - postits prototyping.jpeg

Problem: How would everyone use this new architecture? What was the UX? 

Now that we had reached consensus about the object model. I began prototyping how people would actually interface with it. We had to ensure that residents and manager alike could use it. 

Insight: I realized that we didn’t need to have three different apps anymore; we could have one app that all stakeholders used. This would make our company incredibly efficient, allowing us to consolidate teams and solve the same problems together. I began prototyping an app that could be used by all stakeholders alike.

Challenge: I needed to prove how usable this new vision of access could be and win the confidence of almost our entire company. To do this, I began creating rich prototypes showing how access could be created and managed. 

Screen Shot 2017-10-27 at 18.14.43PM.png

"Passes" Prototype

Passes - invite and make pass.gif

Invite and make Pass in-line

Select Pass and finish inviting

Heuristic analysis and feedback

I tested this with our team and one of the main criticisms was that the UI felt very cumbersome: when inviting or creating a pass, the UI required you to be stepped through many screens. The 'pass' itself felt cumbersome: why would people have so many cards in their 'wallet' or 'passbook'? We had a “keycard” with all accesses on it. What if everyone had a card with any number of access “stamps”? 

2017.11.02 card with many accesses.jpeg

Eureka! What if people just had one card with accesses on it?


Make a card and add stamps to it

Screen Shot 2018-03-15 at 21.44.02PM.png

UI exploration for how to give "stamps" on a card

What were these “stamps”? What was Latch's metaphor for access? 

I presented our entire story to our Chief Design Officer and CEO and tried to portray access with materiality and harmonized with our hardware and visual design standards. 

I began re-designing the prototype using the "circles" metaphor. I called the circles "Keys".

Developing new prototype based on "circles"

Screen Shot 2018-03-15 at 21.16.44PM.png
Circles - invite and make circle.gif

Invite and make circle in-line

Select circle and send invite

Challenge: How do we know this new vision fits our customers' mental models?

Our team was very excited about our new system but wanted feedback from our customers. I had to prove to our team our customers would use this new mental model of access where they gave Keys. I felt that showing our customers the prototype would be testing everything at once when I felt that we first needed to evaluate, conceptually, whether "keys" would be understandable. 

What if we just played a game using our new model? 

I devised a power-based game where people could create keys (represented by a color dot) and give this key (color dot) to someone. 

2017.11.06 filled out keys game.JPG

I tested with our team to ensure there weren't any kinks. I was surprised by how it helped other functions (like Electrical and Mechanical) feel included and some of their insights were incredible. One person commented, "It feels like I have a passport to the world and I can put different stamps on it."

 One person played "property manager" and had to complete different access provisioning tasks.

One person played "property manager" and had to complete different access provisioning tasks.

Testing Keys with real customers

I played our game with two different property manager teams in San Francisco. 

 Testing with property managers at three different buildings.

Testing with property managers at three different buildings.

Issues raised when playing game:

  1. Key "types" didn't make sense to them. They told me they didn't want to give a "guest" typed key to one of their residents.

  2. They initially thought of the key as being unique to a person, because they would make a key for each person. After a scenario Our customers didn’t understand that they needed to make a key first

Revised game

I redeveloped the game in the following ways to address these issues:

  1. Removed Key "types"

  2. I separated 'Make key' and 'Send keys'

I tested with a property manager in New York using the revised game and had none of the previous issues. 

2017.11.16 new keys game with daniel.jpeg

Problem: How would people create access using Keys?

Our existing access creation and editing workflow was a stepped sequence of modals.

Existing: modal-based.png

Problems with stepped modal-based system: 

  1. People had to first (1) create a profile and then (2) select the access -- in a rigid, linear sequence. We found that people sometimes wanted to find and determine the access parameters first, and then enter the contact details to send the access. The stepped sequence hid the information inputs so it was hard to know what was involved without stepping through: (0) choose access creation path, (1) create profile, (2) choose access. Could we combine these steps into just one simple flow?

  2. The stepped sequence relied on a lot of wordy guidance. Could we make the inputs more obvious?

  3. 'Import csv' (for creating access for many people at once) launched a parallel flow that was inconsistent with single access creation. This flow was also limited to "Resident" access and couldn't be used from the "Single Day" access (temporary codes).

  4. The content strategy needed refinement. There were two different access creation paths: "Resident access" and "Single Day Access". "Resident access" needed to be used for many different kinds of access roles, not just building residents. How could we make it agnostic to persona / role? "Single Day Access" was confusing because "Resident access" could also be given for a day period. Time wasn't the differentiator; the access method (code instead of app) was.



Using an 'invitation' metaphor, I designed an input system where there was one creation screen. 

Access invitations.png

Problem: What would we actually build? I had to deliver a specification in less than a month!

I only had one month to deliver the final specification. Our engineering team was incredibly panicked because they felt the prototype showed a “complete redesign”. How would we feasibly implement a new architecture? 

 How would our UX work on both web and mobile?

How would our UX work on both web and mobile?

How would our app be responsive to both mobile and desktop?

I realized that the desktop experience could really just be a big phone app. This constraint would require me to design the experience to be very simple. I used a modular design system so that the mobile and desktop experience was exactly the same.

Screen Shot 2017-12-11 at 22.42.45PM.png

How would navigation work? 

There were two types of experiences that our system needed to accommodate: (1) creating things (like an invite or Key) and (2) drilling down to find something. Creating things felt like it should happen in isolation, focusing the person on the work they're doing. Drilling down and way-finding needed to show as much context as possible so people could easily switch between areas on the site. 

Screen Shot 2017-12-12 at 17.44.38PM.png

I explored a system where the person always had context on where they were.

One problem that happens when creating something complex or drilling down is losing context of how you actually got there. I designed a system where the other screens were still visible as "cards".

Our engineering team concluded this would be too difficult for our initial scope.

Wayfinding and Navigation experiences.png

How would door selection work?

This was the most difficult interaction problem. When making a Key, the creator had to select between as many as 100+ doors and choose the schedule. 

2017.12.19 how would door selection work.png

Final specification

How do we test how well our system works? 

We needed to ensure our customers could use our system but what new aspects should we test and how should we test? I helped our team articulate what new functionality we had and how we expected it to improve the experience. 

Usability Testing

Some of our hypotheses needed to be tested qualitatively. I structured our usability testing with a discussion guide to address qualitative questions. The main issue I needed to test was: would our customers understand that they'd need to make keys and then give them to people to create access? (((Would our system require training manuals??)))


  1. Employee takes resident on tour

  2. New resident moves in

  3. Another resident moves in

  4. Change hours to gym and rooftop

  5. Vendor needs access

  6. One resident breaks their lease

 I experimented using Google Hangouts. Our customer shared their screen and everyone watch the test while they worked.

I experimented using Google Hangouts. Our customer shared their screen and everyone watch the test while they worked.

Critical findings:

  • Each customer figured out they needed to create a key first

  • Our customers wanted guidance for how to make keys

keys popup.png

On April 1st, we launched our new vision for access!

Link to demo:


Password: password

The cycle continues: How can we improve Latch Manager? 

During implementation, our team developed an intimacy with our new product and had many ideas for how to improve. I organized a gathering session where we wrote issues and ideas down and organized into themes. 

2018.04.03 how to improve manager.jpg