Finalizing UX

When I came on board with my latest project three weeks ago, we spent some time defining the sort of minimal functionality that we would need to get the product out the door. We were building a sort of minimum viable product (although not as minimal as Eric Ries might like). The (non-technical) founder had done some extensive user testing with a contracted-out version of the site, and we decided we needed to really strip down the features to the bare minimum.

After defining the requirements, I set out to build a roadmap of feature building. Having never developed with nodeJS before (which we were moving to) and developing on nights and weekends with other developers who were also moonlighting, this was more guesstimating than anything. But when it came down to it, I had put together what I thought was a reasonable schedule to get all of the functionality in there.

I built in a buffer of two weeks (or a 50% increase in the schedule) for something labeled, vaguely, “Finalizing UX”. I knew that after we had built all the basic functionality, we were going to have to make some changes to how everything works based on walking through it as though we were first time users. There are some things you simply can’t vocalize as important until you see them missing from the functionality. So I put in this large chunk of time solely to finalizing the end-user experience, so we could put out a product we were proud of, while still sticking to an aggressive timetable.

Well, week 4 starts tomorrow, and we look like we’re in a position to deliver the basic functionality. But I just got off a 2 hour phone call where we decided that we need to make some changes in order to really clean up the user experience. We needed to tighten up the viral loop, which meant changing some of the approval procedures. We needed to change how posts got displayed (more client-side, less server-side), and we needed to change how we communicated with people (email, facebook, both?).

So, those two weeks will be time well-spent. Sometimes it’s just as important to know what you don’t know (or can’t know) ahead of time, and build it into the schedule anyway. It worked for me (this time).