Lessen Inc.

Property management software for owners, project managers, and service providers.

Company

Lessen offers a unique tech platform that helps connect property owners with trusted service providers – think of it as the Uber for property management. Lessen’s tech suite powers drastic efficiency gains in turns, renovations, repairs, and maintenance work.

Role

The main scope of my responsibilities involved designing and shipping key features for new products spanning mobile, web, and tablet devices. As lead designer for the tablet app, I was responsible for collaboration across teams and disciplines, executing end-to-end product design strategy, and contributing to and maintaining the design system.

Timeline + Tools

2022 - 2023

Figma, Miro, Storybook, React Native, Zeplin, Jira, Trello, Confluence, FontAwesome, Adobe Creative Suite.

Skills

User research, varying fidelity visual design, designing for accessibility, story mapping, collaborating across disciplines, enhanced prototyping, usability testing, remote collaboration.

The Problem 💣

Construction management. That’s the problem!

It’s no secret that repairs / renovations / turns / general contracting can all take a loooooong time. Finding the right service provider and making sure that work gets done correctly and on time is… rare.

The Opportunity 🙏

Efficiency!

In other words, a two-sided platform that pairs vetted service providers with property owners in need of work. The powerful technology suite powers dramatic efficiency gains over the course of a project resulting in quicker completions and greater transparency between client and vendor. The technology suite includes:

Vendor Mobile App: This is where vendors (painters, plumbers, general contractors, etc.) can source jobs. These are the “drivers” in the Uber analogy.

Client Web App: This is where clients (people who own a portfolio of single or multi-family homes) can source vendors. These are the “riders” in the Uber analogy.

Internal Tablet App: This is where Lessen Field Project Managers (FPMs) manage projects. They’re in contact with both vendors and clients to make sure that work gets done correctly and on time. I was design lead in this vertical.

Final Designs and Deliverables

Helping Lessen’s Field Project Managers (FPMs) keep track of their assigned projects, communicate with vendors and clients, and take action to make sure every project gets completed on time.

So… who is this product for, anyway?

Lessen employs about ~500 staff. Of those 500, about 100 work on the tech platform – product, design, engineering, etc. The other 400 or so are Field Ops – these are the people responsible for managing the actual projects, whether they’re sitting behind a desk in Miami or the “boots-on-the-ground” in Atlanta. Field Ops is mostly comprised of Market Directors, Project Supervisors, and Field Project Managers (FPMs).

My primary users were FPMs.

FPMs are the “boots-on-the-ground” folks who drive around in their trucks and make sure that each of their assigned projects is moving in the right direction. A typical day for an FPM might involve visiting six properties, doing two formal walks (I’ll get into “walks” later on), and communicating with vendors and clients to discuss dates, financials, squatters, etc.

Quick Note

Truthfully, a lot of this work and lingo is kind of niche, so I’m going to do my best at balancing the what with the why – although let’s be honest, the why is what you’re most interested in, no?

Also, there’s a lot to unpack here (an entire app, in fact) so I’m just going to focus on one single feature: Change Orders.

I’ll now walk you through my design process for the Change Orders feature. You’ll see flowcharts, low fidelity wireframes, high fidelity wireframes, and final deliverables.

Change Orders at a Glance

What is a Change Order? It’s a formal request to change a project’s scope of work.

Here’s an example scenario: A client originally wanted one large vanity mirror in the master bathroom, but now they’ve decided they want two smaller mirrors in front of each sink. So, we’ll need a Change Order to document this request and make sure all appropriate parties are involved in its execution.

Like many of the features in the app, Change Orders affect multiple verticals, and therefore must be designed in such a way that the solution is holistic and functional across the board. To achieve this, my first step in this process was to draw out a flowchart diagram to show the various possible paths a user might take in creating and submitting a Change Order request.

I generally like to spend about half of my total design time in this phase of the end-to-end feature development process. I’ve found that iterating here, rather than later on in high-fidelity, is a whole lot easier and will ultimately result in a more valuable product.

What we learned from the flowcharts:

1. Change orders cannot exist in a vacuum. They’re highly dependent on input from other users.

2. Clients shouldn’t see the same UI that internal folks see, but the data still needs to map between the two platforms. Kind of like the Uber analogy; riders and drivers see different screens, but they both see a dollar amount.

3. Only one internal user should be communicating with the client, otherwise we may encounter duplicative or inaccurate data.

Low Fidelity Wireframes

The low fidelity screens began to lay out the foundation of the UI. Hierarchically, I placed Line Items into their respective category on a property (eg. “Bathroom”) to organize the structure of a scope. Functionally, I navigated users to a full-screen overlay when editing the contents of a Line Item to align with users existing mental models of this type of interaction inside the app.

Note: “Line Items” are the pieces of work included on a scope (eg. “Bathroom Mirror”) and they have certain attributes, including a description, quantity, price, and photo.

It’s worth mentioning that my goal for V1 was to ship a working MVP and collect feedback. Lean UX, or whatever you want to call it… I’m generally a fan of this approach since it prevents you from going down rabbit holes. As Steve Krug says, “When fixing problems, always do the least you can do.”

The on-screen elements here are intentionally simple. Various forms of inputs, status tags, standard mobile navigation… nothing fancy.

When designing in low fidelity, I like to pretend that the design system doesn’t exist. This helps me focus on solutions for the problem at hand, rather than solutions that our design system supports.

I’m not super picky about which tools I use for low fidelity wireframes. I’ve used Figma, Sketch, Whimsical, Excalidraw, even pen and paper. I’ll use whatever allows me to build the infrastructure of the UI without getting bogged down in pixel-perfect detail.

High Fidelity Wireframes

Upon moving into higher fidelity wireframes, I explored various methods of organization and navigation in the project scope. The project scope is a culmination of all the Line Items associated with the project, and Line Items live in categories… so there were a few directions I could take this!

It’s important for the project scope to be organized in a way that resonates with our FPMs since this is where they spend most of their time. A project can’t proceed if the Line Items aren’t worked on, and a Line Item can’t get worked on if the FPM can’t find it.

These screens were made in Figma.

Left: Category cards. Once the user taps into a category card, they’re brought to a new page and they see all of the Line Items inside that category. Benefit here is a clean UI with plenty of white space on each category card, but the user is unable to see all Line Items at once.

Left-middle: Category accordions. Once the user taps an accordion, it expands to reveal the Line Items within. Benefit here is theoretically fewer taps and pages, but users may lose sight of where they are in this list.

Right-middle: Secondary pill navigation. The blue horizontal bar with interactive pills allows users to jump between categories with ease. Benefit here is users can see all of their Line Items on a single screen, but can’t multi-select or use advanced filtering options.

Right: Sort & filter. Users can view all Line Items at once or filter to choose specific categories. Benefit here is advanced filtering options and the ability to keyword search, but limited screen space to see the entire list of Line Items.

While I personally preferred the right-middle design, I ultimately chose to proceed with the right-most design. This decision was informed by a brief round of usability testing that resulted in the keyword search and advanced filtering functionality helping FPMs locate Line Items faster, in turn helping them create and submit Change Orders faster.

This was an important reminder for me. Regardless of what you think is best for the user, the data may say otherwise!

More High Fidelity Wireframes

While the organizational structure of the project scope evolved through levels of fidelity, the Line Item screens remained relatively consistent. User feedback validated the efficacy of the layout and structure of the Line Item pages, so no major changes were needed.

Note: A significant portion of my user base is colorblind. I’m not totally sure why that is… perhaps it’s just coincidence. Regardless, the high fidelity designs incorporate accessible design principles to accommodate colorblind folks. One recurring theme you’ll see in the high fidelity designs is the combination of color and text. We learned that we couldn’t rely on color alone to convey information, so almost all on-screen components include text, iconography, or a combination of the two.

Unfortunately, I can’t provide an interactive prototype of this feature, but this video captures what the user experience of creating and submitting a negative Change Order looks like.

More Screens and Deliverables

As lead designer for the app, I was tasked with delivering all sorts of features outside of Change Orders. While Change Orders was a relatively large (and fun!) feature to work on, it’s really only a small slice of the full functionality of the app.

Included in the V1 release of the app is the ability for FPMs to view and manage entire projects, review and complete assigned tasks, manage Work Orders, communicate directly with clients and vendors inside the app, and complete property walks.

Side Note: Property walks are a key part of the FPM’s daily responsibilities where they visit their assigned projects to validate the project scope before construction begins, make sure the project is progressing once it’s begun, and make sure all work has been completed successfully toward the end of a project. Each walk has it’s own distinct flow and set of requirements, so you can think of these as individual features.

There’s too much to cover here in just a few paragraphs, so please ask me about anything that sparks your interest.

Designs and prototypes were all built in Figma, handoffs included a combination of an interactive prototype and a Zeplin package, and all reusable components were captured and built using React Native in Storybook. As a startup, a significant amount of effort went into designing and building a robust library of reusable components across mobile, web, and tablet devices.

Here’s a fun little problem we solved – you might get a kick out of this.

Have you ever wondered how half-bathrooms are captured and reported on a property listing? Me neither.

But, it turns out it can be surprisingly complicated, and it varies depending on the market. In some markets, full bathrooms are captured using whole numbers, and half bathrooms are captured using integers of 0.5. So, a house that has two full-baths and one half-bath would show: 2.5 BA

However, the issue with this method is that a different house in the same market with one full-bath and three half-baths would also show: 2.5 BA

To solve this, some markets have evolved to capture half-baths as integers of 0.1, so a house with two full-baths and two half-baths would show: 2.2 BA

Obviously this discrepancy leaves room for error and confusion, so our solution was to separate the fields entirely, and simply capture and report the number of bathrooms as two separate queries on the backend.

A house with four bedrooms, two bathrooms, and one half-bathroom would show: 4 Bed | 2 Bath | 1 Half Bath

Takeaways

I wish there was a way to hand you a tablet and have you create a Change Order or update the completion date for Renovation #8609. Unfortunately, due to the nature of this being an internal product, that’s not possible… unless you’re an FPM reading this 👋

My point is this: after almost a year of working on this app and its complimentary counterparts, I’ve learned that I love owning projects from end to end. The responsibility of ownership is a bit daunting at first, but once you get to the point where you can teach others about your product and see their eyes light up when they understand the value – that’s really fun and rewarding.

I also learned a lot about user research and usability testing. During my time with Lessen, I developed a great appreciation for DIY usability testing (linking Steve Krug’s book one more time in case you missed the first one). I learned, or perhaps re-learned, that your product will be better off in the long run if you get it in the hands of users early and often. If you spend months and months trying to make it perfect without ever showing it to anyone, you’ll probably end up missing something big.

The last key takeaway I’ll mention here is that your product should work for your user. I’m not saying that you don’t need to make it look nice… but a client facing platform doesn’t need to look like an internal tool, or vice versa.

Thanks for reading!