Propfolio

1. Components without clear purpose or meaning

The house-shaped icons in the screenshot below do not have explicit meaning. While the blue icons labeled "vacant" imply the other two styles (green checkmark and red 'x') have something to do with occupancy, but it's unclear. Furthermore, making the 'vacant' icons blue implies vacancy is a "neutral" status relative to green's "positive" and red's "negative." From here, you might infer "green" signifies "occupied." But if green means "occupied," and blue means "vacant," what does that make red? What's worse than vacant? Condemned? When asked, Sam and Luke were unsure.

2. Designs did not account for how data actually gets into the app

The designs assumed a preexisting connection to some database, but they did not account for any empty state. How, then, does the app know what data to show? If each user has a unique portfolio of their own properties, how does the app know what those properties are? Does the user input them through the app? How? Is it one at a time, or can they bulk import a CSV? What does the app look like when the user first logs in and has no properties? 

The file was full of omissions like these which, to play devil's advocate, are understandable when you're still in the brainstorming phase. But now that we'd decided to proceed, we needed to address them.

Example: The “Files” Panel

Take a look at the key screens below: “Dashboard” and “Property Profile.”

These designs share essentially the same layout, except Property Profile has an added “Attach Files” module in the bottom of the right sidebar:

On its face, it’s perfectly simple. In Figma, all you have to do is assign the files container a boolean prop you can toggle on or off. No problem. And in development, that’s exactly what I did.

/* 
 * this is a stripped down sample for explanatory purposes, 
 * which assumes all non-primitive types used in the interface declaration 
 * are imported previously.
 *
*/

interface SidebarProps {
  user: UserAttributes;
  notes: Note[];
  files?: Files[]; //optional, since we might not even be showing it
  showFilesPanel?: boolean;
}

export default function Sidebar({user, notes, files, showFilesPanel}: SidebarProps) {
  return <>
    <NotesPanel user={user} notes={notes}/>
    {showFilesPanel && <FilesPanel user={user} files={files}/>}
  </>
}

Hang on, though. This is passing down files as props from a parent component, meaning we’ll still be loading the files even if we don’t intend to show them. That’s a big problem for performance, especially since the screen where files won’t appear is the Dashboard. The Dashboard screen displays aggregated data from every property, so we’d be loading every single file the user’s ever uploaded, and we wouldn’t even be displaying them.

It’s a simple fix; we just refactor to only load the files if showFilesPanel is true. 

But wait, now we’ve got another problem. 

Alright, then, so we need to refactor. We’ll only load the files data if showFilesPanel is true. 

But wait, there’s another problem. 

Example 2: “Oops, we didn’t think of that.”

Design forgot to account for the fact that there’s nowhere for the users to look at all their files at once. They can only view files by going to a single property. If a user forgot which property they attached the file to, then they’re out of luck. 

Furthermore, what if they have a file that doesn’t pertain to just one specific property? Do they just assign it to one at random? That’s not helpful. 

Again, the solution seemed simple. They should have a “My Files” tab where they can manage all their files in one place, whether attached to a property or not! However, this too led to an exponential cascade of follow-up questions:

• How should it visually distinguish between attached and “free-floating” files?
• Can you attach a free-floating file to a property after uploading it?
• Can you move files from one property to another?
• Can you rename a file?
• Can two files have the same name if they’re linked to different properties?
• What if I upload a file from the Files tab, is it a different flow than uploading one from the Files panel on a Property Profile?

Great. Now, we’ve got to go back to Design and get clarification before we can proceed.

Giving Teams the Right Tools to Communicate

This is an unavoidable part of the product development process, but when designers and engineers share a similar mental model, you can get through these hiccups much faster. With a system like LiftKit, the UX Engineer can simply mock up their alternative and bring it back to the team for approval. 

Without it, the engineer would have to go back to design, describe the problem as best they can, wait for a redesign, and go back and forth until the fix is sufficient.

In the above scenario, efficiency relies on the two parties’ written and verbal communication skills. But as anyone who’s watched an introverted developer try to explain states and props to an extroverted designer in the span of a 30-minute Slack huddle can tell you, it’s not the most efficient way to do things. 

My experience has been that the average dev would much rather simply mock up the thing they’re trying to describe and show you the thing than try to put it into words. I’ve also learned that this is the quickest way for projects to get back on track.

Maintaining momentum. That’s the key. And there’s no better way to do that than to give both sides of the team the power to create.

<AnimatePresence> with Live-Filtering Lists

Tabs, Modals, and Recharts Graphs