Design Archives - Jen Tindle

When I left real estate to start my own B2B software firm, one of my colleagues recommended that I read Donald Miller’s Building a Story Brand book. This was hands down one of the best recommendations that I received. Donald explains in simple terms how to communicate effectively with prospective customers. While both my cofounder and I came from the real estate industry, 71% of our customers came from inbound leads. This means that our customers found us via our website. They knew that we solved the problem they had and contracted with us to help. In other words, the Story Brand method works. Here’s how to build a Story Brand website for a B2B software company.

First, keep your front page simple.

Explain what you do in layman’s terms. If a complete stranger can’t understand the gist of what your firm does within a 3-second (or less) glance at your front page, then you need to redo it. You also need an explicit call to action. That way, if a prospective customer finds your site, recognizes that you solve their problem, they know what to do to get your help.

For example, my startup was a real estate data integration company. We integrated with property management software like Yardi as well as more standard applications like Salesforce. Our customers often complained that they spent too much time pushing and pulling data. They would rather spend that time on more value-add activities for their business. I opted to narrow the communication to exactly what we do and how we solve that pain point. “CREx makes it easy to get data out of Yardi, Salesforce, and more. Stop wasting time. Start generating revenue.” I then immediately gave prospects a call to action, “Start now.”

Show your value proposition.

Make it clear to prospects why what you do is valuable. Before we had customers, I estimated the amount of time savings that we provided. Once we had customers, I translated those time savings to dollars. Once again, I included a clear call to action to “Automate workflows.”

Give prospects a plan.

Tell them exactly what to do to solve their problem. We aren’t the heroes in our customers’ journeys; we are simply their guides. They need us to communicate clearly what they need to do to succeed.

One of the most effective ways to communicate a plan is by breaking it down to 3 simple steps. Here, I told them that after meeting with us, they would get a kickstart on their data journey. Then, I appealed to their self-actualization; they would “get noticed” by their boss or investors by using our software.

Provide authority.

If you have customers, here’s where you should show off your logos. People are “sheeple” after all. And before you say you aren’t, do you really not look up reviews of a restaurant before eating there? Yelp is successful for a reason!

4 simple steps to build a Story Brand website for B2B software

To recap, here are the 4 steps to build a Story Brand website for your B2B software company:

Keep your front page simple.
Show your value proposition.
Give prospects a plan.
Provide authority.

If you follow these 4 simple steps, then I guarantee that you will succeed in converting web traffic to leads. The Story Brand method worked for my B2B software company, and I’m confident that it will work for you.

Want more? Subscribe below.

MY COMMITMENT | Never sell or share your data | Provide useful and impactful stories

Your goal is to easily and efficiently allow users to create and select groups of items. Those groups may contain other groups, up to several levels of groupings deep. Each individual item can be part of multiple groups. How do you solve these myriads of groupings when designing an app? It’s not easy. This complex relationship is difficult to convey visually in a simple manner. Fortunately, my product mentor, head of engineering, and I put our heads together to design for groupings of multi-hierarchical relationships.

Our problem came from real estate. Here’s how groupings of multi-hierarchical relationships work in that industry.

Groupings of multi-hierarchical relationships in real estate

Owners and managers view real estate in many different ways. Property managers may group their properties by regional manager or by ownership group. Owners may group their properties by ownership structure. For example, owners may have a fund that consists of portfolios made up of properties. Property managers and owners may also view their properties by city or submarket. These are just a few examples; the point is that whoever owns or manages real estate wants to evaluate their properties across many different groups.

We wanted to make it easy for owners or managers to select properties, create and save groups of properties or groups, view groups of properties and groups, and see hierarchies of selected subgroups or properties within a hierarchy.

Some important criteria to note:

A property may exist in many groups -> users may want to view a property by city, such as Austin, as well as group it by property type, such as the entire multifamily portfolio
A group (as a subgroup) may exist in many groups -> users may want to group a manager’s portfolio into the regional manager’s portfolio, and they may also want to see the manager’s portfolio grouped into the state portfolio
A single property may not exist twice in any group -> users want to add more properties or groups to the view

Requirements

Here are the specific user requirements that my team and I identified.

User can clearly see which properties are part of which group
User can view many properties and groups at the same time
User can save or edit a view of properties or groups as a group
User can quickly distinguish among many selected groups or properties
User can easily see how properties fit in the hierarchy of a group or levels of groups
If user selects a subgroup or property within a group or subgroup while viewing more than one top-level group, the user can see which hierarchy above the property or group selected that it relates to

I’ll explain how to solve these requirements by showing my design iterations.

Iteration #1: Put pen to paper, aka the throwaway design

This is a basic, pen-to-paper idea of how a group, aka portfolio, contains multiple properties.

First, does this solve our requirements?

User can clearly see which properties are part of which group -> Sort of, although the drawings of lines aren’t great… probably a better way to show this.
User can view many properties and groups at the same time -> No, it would be way too complex.
User can save or edit a view of properties or groups as a group -> Yes, but why is the Edit Portfolio button so bright and calling to the user? Is the user expected to click on that a lot?
User can quickly distinguish among many selected groups or properties -> Sort of, but the lines are confusing.
User can easily see how properties fit in the hierarchy of a group or levels of groups -> No.
If user selects a subgroup or property within a group or subgroup while viewing more than one top-level group, the user can see which hierarchy above the property or group selected that it relates to -> No.

In general, the lines around the portfolio and individual property somewhat overlap and aren’t visually distinctive. Plus, the “Edit Portfolio” button is looming large for some reason. Do we expect users to edit portfolios often? Not at all. Then let’s scrap that as a call-to-action type of design and make it optional.

Iteration #2: Find inspiration and riff

Alright, we’re getting better. Kudos to my product mentor, Brett Collinson, for liking the groupings in Google tabs to this problem. Google tabs inspired this design.

Does this solve our requirements?

User can clearly see which properties are part of which group -> Yes, although the groups that aren’t selected aren’t as obviously separate from one another or the properties… the line in between does solve it but the user has to think. We don’t want users to think.
User can view many properties and groups at the same time -> Yes.
User can save or edit a view of properties or groups as a group -> No, it’s not obvious to a user how to do that on these screens.
User can quickly distinguish among many selected groups or properties -> Mostly, although it’s odd that the Austin portfolio is in a selected state at the same time as the two sub-properties.
User can easily see how properties fit in the hierarchy of a group or levels of groups -> Mostly, we don’t see more than one level deep here, so levels of groups have not been solved yet.
If a user selects a subgroup or property within a group or subgroup while viewing more than one top-level group, the user can see which hierarchy above the property or group selected that it relates to -> No.

We solved more of the requirements, which is great progress. I also liked that the button to add more properties or groups to the view is a circled plus symbol. It’s not a first-state button but still calls to the user.

There are still some issues with easily displaying multi-hierarchical relationships (i.e. greater than one level deep). I also didn’t love the line across the top. While this works well for Google tabs, it’s a bit “extra” for our use case. Given how complex these relationships can be, we had to solve for simplicity. I wanted something simpler, something that was intuitive AND minimalist.

Iteration #42: The answer to everything

Let me walk you through each of the screens and scenarios that we used to solve our requirements.

Above, I selected multiple groups (identified by the icon of a building with a “+”) plus a single property (identified by the icon with a building). The “Add Portfolio” button is back but in a secondary state.

I expanded the “All Multifamily Portfolio” group. Note how the “>” caret shifted to a “<” caret to the right of “All Multifamily Portfolio”. The user still has the overall portfolio selected as indicated by its purple background and transparent individual properties.

Now, I have multiple groups in a view with one subgroup selected. Note how the second-level subgroup has a “v” upside-down caret and is the one item selected for this view as indicated by the purple color.

Alright, let’s solve for multi-hierarchical groups. We’ll use a fund structure to explain. Note that we have a top level fund, the “All Properties Fund” in a view, of which the “All Commercial Fund” is a child entity. “Add Portfolio” changed to “Edit Portfolio” as well. We chose for the edit functionality to display only when one top-level group is selected, i.e. the “All Properties Fund” is what the user would edit if they clicked “Edit Portfolio”.

Let’s go a level deeper. I selected the “All Properties Fund”, expanded its components, and then clicked the “v” to see the children of “All Commercial Fund”.

Then, I selected one of the children of “All Commercial Fund”. Note that the top-most grouping is in a default selection state, while the other sublevel groupings (in this case, “All Commercial Fund”) are transparent. The “>” and “>>” indicate which level of the hierarchy each groups represent.

Let’s keep going! 4-levels deep now. Here’s what the hierarchy selection process looks like.

And here’s what it looks like after selection. Note how the right carets increase from “>” to “>>” to “>>>” etc. for each new level.

Finally, one last check. Does this solve our requirements?

User can clearly see which properties are part of which group -> Yes.
User can view many properties and groups at the same time -> Yes.
User can save or edit a view of properties or groups as a group -> Yes, although I recognize that having a child selected may cause the user to think that the “Edit Portfolio” button would edit that subgroup. Fortunately, we never had any negative feedback about this feature.
User can quickly distinguish among many selected groups or properties -> Yes, the bright purple colors make it much clearer. We also added shading behind each button to make it more obvious that they’re clickable elements.
User can easily see how properties fit in the hierarchy of a group or levels of groups -> Yes.
If user selects a subgroup or property within a group or subgroup while viewing more than one top-level group, the user can see which hierarchy above the property or group selected that it relates to -> Yes.

Conclusion: the final design of groupings of multi-hierarchical relationships

We finally solved the design of groupings of multi-hierarchical relationships. Woohoo! But before I let you go, let me briefly touch on some technical requirements.

When a user selected the + icon to add a property or group to the view, or selected “Edit Portfolio”, they would see a pop up with a list of properties or groups. We opted to filter out any properties that were already selected. This meant that if a property was part of multiple groups, the groups for which that property was in would be hidden from the selection view.
Our head of engineering is incredible and helped out with our design tremendously. Their expertise was mainly on the front-end, so to help explain how the back-end of this would work, I referred them to watch this video by the incredible Dr. Soper. In this video, Dr. Soper explains how recursive relationships work. Recursive relationships represent the groupings of groupings that we displayed above.

Now you know how to design groupings of multi-hierarchical relationships. You can apply this knowledge to any product or industry that has similar requirements to the ones discussed above. If you run into any issues, send me a note. Good luck!

Want more? Subscribe below.

MY COMMITMENT | Never sell or share your data | Provide useful and impactful stories