[caption id="attachment_2108" align="alignleft" width="400" caption="The first prototype of the Kitify front page. Notice I use the phrase "1999-style page reloads"."][/caption]

[caption id="attachment_2109" align="alignleft" width="400" caption="v0 of the actual site."][/caption]

This entry is the third in a series about Kitify, a web app I built that was intended to let DIY project creators easily sell kits for their projects. You can see all the published entries by clicking here.

Once I had the initial research for Kitify done, I moved on to what I think is the most important actual research step, which is building a functional product. The difference in feedback that you get between “here’s an idea, what do you think?” and “here’s a product, will you use it?” – and indeed, seeing whether people do use it once you let them know about it – is huge. I also like building things, so it would have been hard to keep me away from this step regardless!

First, I put together a mockup of what I thought a very early alpha could look like – the core of the product. In retrospect my plans for the core of the product were probably too simple, but I was focused on coming up with a feature set that could be put together relatively quickly and cheaply. I built some mockups in Balsamiq and annotated them heavily in order to fully convey everything that needed to be built, while I looked for a software engineer who’d be willing to do that for me.

Through a friend of a friend, I found an awesome developer who had real interest in the product and was therefore willing to take a bit of time to build the prototype for me. During the initial phases of the project, I learned just how out of touch with modern web development practices I was. I knew how to code in PHP (extremely helpful in being able to talk intelligently about design decisions), but I didn’t realize how (relatively) easy Ruby on Rails and other modern frameworks make it to build a fairly polished user experience, just as a foundation.

You then have lots of flexibility on top of that to build all kinds of technically-complex features that normal users take for granted, such as frequent communication between the server and client without page reloads, animations, and other snazzy UI components. My mockups say that page reloads are OK, but if you are working with a good web developer, you more or less get AJAX communication for free, for example.

The prototype looked really good and allowed me to gather more feedback about the idea and be taken (marginally) more seriously in receiving that feedback. As I mentioned, the main problem with Kitify wasn’t that nobody wanted it, it was that they weren’t willing to pay enough; it attracted the most expensive and difficult kits for sale since kits that are easier to produce become independent businesses.

Sending my initial prototype out to potential customers, and business partners, gave me some clues as to other directions Kitify could take, though I ultimately ended up not pursuing these.

[caption id="attachment_2110" align="alignleft" width="385" caption="How the site looks now."][/caption]

Once the prototype was built, I had to decide whether to build out a full application with all the features I thought were important for it to be a real product. The prototype wasn’t big enough – it couldn’t be used for much. But building out the full feature set I imagined would allow me to do tests with a real product that would actually encapsulate some of the assumptions I had been making (for example, what kinds of kits people would put on the service). In retrospect, there were probably cheaper ways to test my assumptions but, as I said, I like building things.

However, to get all these features built out, I would either have to pay a huge amount of money, or wait a very, very long time for the engineer I was working with to complete the project in his free time. I figured I’d better learn how to build a fully-functioning, modern web application – I already knew Javascript, but it was time to learn Rails. I’m good at learning from prototypes, so I started with what my engineer built for me, and went from there. For about two months, I worked full-time on getting what I would consider a “version 1” of Kitify built. You can check out the code here, or the site here – in the course of building the site I had to do lots of interesting stuff, like learn how to implement AJAX file uploads (by far the most time-consuming piece of the final product).

Eventually I learned that it’s much better, when you get stuck, to look for a simpler way of doing things rather than press on through. Problem-solving abilities can be a liability because you lose the heuristic of figuring out a new way when a problem seems impossible to solve.

The file uploads are a good example of this – what happens now on Kitify is that you click a file upload button, and you get a popup that lets you actually choose which file to upload. For a couple of weeks, I was obsessed with making it so that the file upload button led directly to a file upload dialog (no second button press) in all major browsers. It turns out this is impossible, and… actually doesn’t matter.