Don’t Develop Features, Build Designed Products

When faced with a hard deadline you are forced to make decisions fast. Below I am going to detail briefly the design decisions that took place to deliver PlaygroundCommunity for the hack::data competition.

As I stated in my last post, Developers’ Weak Spot, time and time again I fall for this trap. In PlaygroundCommunity I started all wrong. I thought, after my success of the Kindy Web Site, surely there must be a good platform for me to begin this site with. It could give me logins, forums, comments, Facebook integration etc. So began the search. I fired up the Microsoft Web Platform installer and had a look at the open source .NET based blog, forums, content management systems, to find something just right. What I found was that I had fast headed out in the wrong direction on a new project and completely wasted my time.

I did not design the product that I wanted. I had a feature ideas written down, but the problem is shopping list requirements are just plain wrong. They give the false impression that you have thought about your product when you haven’t. My motive for searching for base that had it all was that I did not want to waste anytime coding something that is already done. However, more time is wasted building the wrong thing. I started designing the product wrong. I went:

Idea > Feature Shopping List > Search for existing platform to save development time

After I waste my time, I started again. It still starts with the idea. From the idea you generally cannot help thinking of all the things the application could do. A feature shopping list. Only do this briefly. You don’t even need to write this down and can skip it completely. Coming up with features is usually easy. You need to put all that aside and think of the user experience (UX) and the work flow that is desirable for your users first. When that is taken into account, requirements that sounded good on their own, that don’t fit in the UX get dropped easily. The same goes for discovering features that fall out of the workflow that would not have been easily considered on their own. Always come from the user perspective when considering a new feature. It is like grocery shopping. You plan your meals for the week, check out the recipes and then build a shopping list based on what you need.

The solution for PlaygroundCommunity was to mock the interfaces to determine the functionality that is required. What I ended up with was 2 pages, with external services consumed with JavaScript. Nothing difficult that required a heavy, feature-filled platform to start from. Although this is very clear in hindsight, from my feature shopping list, it was not. Below are the mocks I did in PowerPoint Storyboarding, an extension for PowerPoint that comes with Visual Studio 2012.

PlaygroundCommunity Mock Page 1PlaygroundCommunity Mock Page 2

From here you can see how close the end product came. I had a few changes on the mocks after consulting a couple of people before I even started coding. It was easy to determine what could also be cut to be able to make the deadline. What makes it interesting is due to the clear scope I was then able to take a risk and use technologies I had no previous experience with, for my learning and improved user experience.

Technorati Tags: