Turn that idea into Reality

Often we find the challenge of turning an idea into reality quite daunting. And rightly so, its not easy. But the fact is, if you apply a) a process, and b) the discipline, you can get this done.

The discipline is difficult and really up to you, but the process can certainly be challenging, and this is something I can hopefully help with. Before we get into a process (which I am going to keep simple for this first post), there are some principles that you should also keep in mind. If you have ever heard me speak, these are the principles that I always go on about, and here they are in an abridged version;

• Keep the idea simple, you may have grand plans for it, but what is the simplest thing you can do to get into the wild. I call this your Minimal Success Set. Which is the minimum amount of features that you can apply to your product for it to be called “a product”
• Don’t worry about problems you don’t have. You will start thinking into the depths of the different challenges you might have, but if they are not holding you up now, don’t worry about them. In fact, this is the best time you don’t have to worry, and you can start building, because you are starting from a fresh slate.
• Can you operate or support the application when you go live? Think through the details of what happens once you get it into the wild, will there be human processing that will need to occur, even emails that will need to be processed. You need to consider what the impact of this would be. I once worked on a project that required human intervention to process every subscriber’s content on-line. Seemed like a great idea, and the impact was 30 minutes for each account. But when we analysed this, I could only process 16 subscribers per day, but that meant I was just processing subscribers, and the costs were not significant enough to hire someone. So I had to re-engineer this concept real damn quick!

There are many other important principles, but these three are the good ones to consider when starting out. The next step is to have a process; and by the way, the process will help you with your discipline, because you will see a solution to deliver a product.

The below process is based on a more detailed 9 step process (which I am going to publish in the next few days). This subset is a great start. The first 6 stages focus on the areas that a product manager would be concerned about. The last three are more technically driven. All-in-all, this is what I call a top-down or user centric process, which not only works really well, but is also accepted as best practice these days.

Here are the 6 user centric steps in the process, with some detail;

1. Brainstorm to firm up the concept.

You have an idea, now you have to make sure that it is valid. I am assuming that your idea has a commercial benefit, so you therefore need to make sure that it is commercially viable. This is also the time that you want to try and take the steps where you minimise what you are going to deliver, and start doing some thinking about how the customer will interact with your application. Start to answer the questions like; what will this thing do (and NOT do) in the first release? How will it make money? How much of my time will it need after it is launched? What kind of customers do I want, and therefore, what is my product’s personality? Minimise, minimise and minimise again, until you get down to what the absolute basics of the application are.

2. Write a scenario

Earlier this week, I wrote a post on how to write scenarios, they are extremely useful at this stage. They describe your users and the process they would go through on your site in plain English. It is essentially a creative writing piece. You come up with a model for your user, you then describe in a step-by-step format on how the user will accomplish their goal. A scenario models only one path, usually the most common path a user will take. And often can include the intention of multiple users. Don’t omit this step. Scenarios are fun to write, and because they are usually not constrained by technology are generally going to be the best experience that a user can have in the application. When doing the next steps, you always come back and compare it against your scenario.

3. Sketches

Use paper, whiteboards or software tools if you are comfortable with them. Start to sketch out how the screens will work. Try and put as much detail as you can, but also try and minimise as much as you can. Don’t skimp out! It is so easy to say “and after the user clicks the submit, they see a confirmation screen. We don’t need to sketch that – its straight forward!” No its not!!! You are a) leaving yourself open to interpretation and b) not apply consistent behaviour. If you assume that the confirmation screen is just another screen, what purpose is it really providing? Just another screen? What can the user do here? How do they get back? Can we just show the same form with a confirmation message? Can we show a details page with a confirmation message? Could we simplify with Ajax? until you actually do it, you don’t know. Remember, it is easier to screw up a piece of paper than to refactor code, and change application behaviour. This is also a good time to take a friend (you trust) through your application, and get a second opinion.

4. Design

I find the design really important. This is where you start to get a feel for your application, particularly its personality (Something I think is very important). Work on a template design, something that you are going to apply to all your screens, then start working on a couple of screens. Try to use the correct copy instead of Lorem Ipsum. You will start to get a feel for the application. Think about the personality of the application based on who your potential customer will be. If you are targeting a youth market, then is your app look-and-feel ‘youth’ like? Does it come across as a 18-35 year old? Do you envisage the customer and the application having a relationship with each other? Work on the design until you think you have nailed this. Although with style sheets, you can always change the design, getting it as close as possible at first, means that you make lighter work later.

One thing that I will also add here that I like doing, is that I like to make sure that I leave some flexibility in my design. Things like size of titles, colours etc. The reason I do this is twofold; firstly, you just don’t need this detail, and secondly is for psychological reasons. As you go ahead to build and test your application, you are looking at your screens day in and day out. You quickly get bored of them, and start asking yourself the inevitable questions of “did I get this design right? Seems stale now, what can I do to improve it?” By adding the missing design elements, you tend to find that you keep it fresh and stop second guessing yourself. Again, just something I like doing.

5. HTML Screens

OK, once you are happy with the fundamental design, it is time to start building screens. This is where, if you didn’t cut any corners on Step 2, that you will find this to be an easier process. Mainly because you start to identify similar screens. Again, do your best to not cut corners though. Build every screen that you need, as it will make your coding experience much more pleasurable. If you can walk through your scenario using HTML screens, you are doing quite well. And you are half way there.

The interesting thing here is, how far do you take your Ajax at this point? With frameworks such as Rails and Grails, many of the Ajax functions are available out of the box, so you may not want to hand build everything in the HTML. I use grails a lot and what I like to do at times, is when I have taken my HTML screens to the point that I am writing Ajax code, I now start writing the HTML within the Grails framework, which means that I start building the actual Ajax around the framework tools, and also start putting real links without any real logic behind the scenes. This should be pretty straight forward, and again, make lighter work for you in the future.

6. Write the code

This is where you start finishing the project. Notice I say finishing, and in some ways you feel like you have just started? That is because we often get caught in the trap of writing apps from the bottom up; design the database, work out functional code and then the design. But that is wrong. DB admins aren’t the users of your application, its people that are interacting with the UI, so you should take the top down approach. And that is exactly what we did with this process.

Now that we are writing the code, we work out what the actual stories are from our scenario and start writing the code by writing the tests first etc. I am not going to go into what a purist Agile, Test Driven development tirade is, but I think most coders know what best practice is these days, and should strive to get as close as possible to that (even though it is not realistic to do so at times).

So there it is, a process that you can clearly follow. I haven’t gone through the details of how to launch in the market, but that post will come soon. There are so many ways that you could run this process, and find a more optimal way for you to work, but this is what works for me that means I can get a running product much quicker than fumbling over myself.