Lessons learned from implementing Highrise's custom fields feature

We recently added custom fields to Highrise (below) which allow you to keep track of extra details beyond standard contact information like phone, email, address, etc.

After the launch, we had a “looking back” conversation to see what lessons could be learned from the process. Three of our findings:

1. Add to an existing design before trying a new one.

When you begin work on a new feature, try to add it within the context of the existing design, evaluate it, and then make a decision about how to proceed based on that experience. That way, you quickly get a good sense of what works in the existing design and what doesn’t. You might even discover that the new feature fits into the existing design without any further work required. (Huzzah!)

We started with a different approach when we tackled the custom fields project. We began with a completely new design for the contact edit page and pursued that design (below) for most of the project.

In the end, we decided to discard this design because it wasn’t the right solution and it introduced a bunch of new problems. It took us a long time to make that decision because there was a lot of work involved in developing the new design. And most of that work was not giving us good feedback about the nature of the problem we were trying to solve.

When we reset, we discovered that some of our assumptions about custom fields were wrong. For example we assumed that shoehorning custom data into the contact page sidebar (right) would make the page too cluttered and inconvenient for people. But we failed to actually try it out to confirm this assumption. When we finally did try it, we discovered it wasn’t bad at all.

2. Resist the urge to make something special out of something boring.

Custom fields aren’t the sexiest feature we could have worked on. Plus, we were building them based on customer requests instead of our own internal needs. Because of that, we mistakingly tried to make the project more interesting with indirectly-related work, like a redesign of the contact pages, streamlined contact dates, bigger avatars, and fancier ways to save data. None of these things were required for us to launch custom fields, but we were tempted to tackle them because they were more fun.

Adopting all those extra concerns obscured the reality that custom fields could actually be a very tiny project. When we finally threw out all the extras, the feature seemed embarrassingly simple. Nonetheless, our customers love it. The lesson here is the tiniest version can be good enough.

3. Storyboard complex interactions instead of building them immediately.

We tried to build out the redesigned edit page so that every interaction could be demonstrated for real and then evaluated. Since there was a lot of complex interaction on the page, most of the work involved in this process was Javascript programming which took a long time to complete. And programming the interface early made it difficult to change the design as we learned more about the problem.

Creating a storyboard of all the states is a more efficient approach for developing pages with complex interactions. It takes much less time to generate storyboards and they are easy to share and discuss with everyone. We used this approach when we worked on bulk operations and it worked well. Everyone was able to see the design early and understand how it should work. From there it was much simpler to divide up the work and build the feature quickly.

Our storyboard for all the screens for the Highrise Bulk Operations project. Storyboards like this illustrate the complete flow so everyone’s on the same page.