The Trim Comes Last
December 20, 2011 § Leave a comment
The basement in our house was recently flooded by Hurricane Irene. Our basement had 4 feet of water, so we had to completely redo it. The first thing that the builders did was strip everything down to the studs. Next they added the framing and sheet rock. Once the walls were up with the proper electrical and plumbing, the painters came in. Then the carpet. And finally the trim. What was amazing to me is how much the last step (i.e. the trim) changes perception of the room. The visual of the room goes from disaster area to bare, to better but still ugly to wow…that is a nice basement. That last step takes only a few hours, but the impact on perception is amazing.
Why am I writing about my basement on an entrepreneur blog? Because I take a similar view of product development. The early stages of development is sausage making, i.e. it is ugly while it is happening. It is purely concept until the framing is set. Then the walls have to go up, which I think of as the basic page functionality. The electricity and plumbing are comparable to the back-end infrastructure. At this point in the project, you have a bunch of ugly pages that functionally work. The next step is you start adding the paint and carpet, analogous to the first part of the designs. And finally the trim. What is hard to communicate to outsiders is how much more attractive the site will be once the trim is added. They see the painted walls, i.e. the first round of designs implemented and assume that you are done, which of course, you are not. From my perspective, there are two ways to deal with this communication gap.
- Keep your app behind a firewall until the trim is up. This has the benefit of withholding first perception. The downside of this approach is that you don’t get any user feedback.
- Put your app out there, bare for the world to see and see where the UX breaks are and where the design feedback is. This has the benefit of getting raw functionality feedback. The downside of this approach is that first impressions (i.e. seing the site while it is still sausage making) will need to be changed.
- Note there is a hybrid third option which puts the site out there, but behind a password. This approach works for some products, but not others. I.e. it works for products where the user interaction is individual. Any heavily social product can’t use a password or it will annoy invited friends.
With my product, I chose option 2. I know the downsides. It was an informed decision. I chose this approach for one key reason:
- I believe that you gain really valuable feedback on user flows when the raw product is in user’s hands.
Let them tell you what path they want to go on, rather than you telling them. Once you have this feedback, it is easy to add navigation paths to the product. But I like getting raw feedback on usability before adding these paths.
One other important caveat. Don’t market the site while you are in this phase. Just show it to friendlies, i.e. people who will give you the most credit for the improvements. Let them use it in its rawest form. Let them complain about “this” being confusing or “that” being ugly. Talk to them while they are using the product. See where they click, where they get tripped up. Then you know where to fix and where to emphasize in designs. With a house it is easy. You know where the couch goes. Where the TV should be and where the bathroom needs to be. They are known entities with few realistic options. But with new web applications, it is hard to know. So, I believe, that you start out with a hypothesis and you test it with real feedback and you iterate fast.