How to Plan Software like a Pro

Potential clients come to us every day concerned about planning their software and how to get their vision across. This is our core offering at FaceySpacey--helping actualize your vision in a way that closes the communication gap 100% with the programmers. I'm going to explain some of our methods right here (although this might put us out of job).

I personally use Paint, Powerpoint and Excel. I build the exact piece of software or website in paint and then I put it into Powerpoint and show every single possible interaction as well as any calculations and how the calculations interact with the database. To show interaction with the database, I show screenshots of tables built in excel.

A lot of the other more specialized tools are just fluff. You need to get straight to the point and visualize it as it is and be able to get right into it right away. Copy and paste screenshots or already existent software and web sites/applications and paste them into paint and copy and paste chunks or pieces between paint windows to achieve the UI you want. This is how you should start. MAKE YOUR SITE LOOK EXACTLY AS IT SHOULD IN PAINT! Take the nav-bar from Youtube, take the newsfeed from Facebook, take the "People You May Know" box from the Linked in user homepage, etc. Paste each chunk into one Paint file. Then start renaming things and re-arranging the sub-components of each component you dropped in. If you need drop-down menus and other forms, just google image search "drop-down menus" etc.

Try to use components from sites for which you would like to mimic the design. Eventually, you'll be giving this stuff to a designer. So capture the essence you will be going for later on now. Once you're done with this, You'll have 2 options depending on your time-framed: Put the exact diagrams you made into PowerPoint and do the remaining 75% of the planning work while the designer designs the pages, or have the designer design the pages AND THEN put those into Powerpoint. Do the later if you have time. Do the former if you don't.

Once you're in Powerpoint, you're going to realize that your diagrams will need to be modified to most easily show some interactions--most specifically ajax animations and the like. You will see that your web-page changes (or desktop application) as the user clicks certain things. You're going to have to go back to Paint, make a more default version of this page (stored in separately), and then you're going to paste that default version into Paint, and you're going to start pasting little chunks in again that represent all the different states of the page. You'll store each of these states in the same folder that you store the default main version. I often call this folder for websites something like: "Ajax Popups."

Regarding Organization, you're going to want to organize all the diagrams for your site/application in a perfect folder tree system just as the site/application would be stored on your server. You're going to want to make a separate version of this whole folder tree once you're ready to enter the Powerpoint phase so that you can gear this new folder tree towards the default versions and ajax popup type stuff mentioned above. The first folder tree will have the most common state for all the page designs (although not the somewhat empty "default" state), and you'll want to deliver that whole folder tree to your design to work on while you do the powerpoints.

Next, you do the Powerpoints. Generally, the first thing I will do is get myself acquainted with the app by doing a Powerpoint that represents the core offering of the app, even if this powerpoint encompasses many pages that otherwise should be addressed individually. For instance, if you have a site where one type of user submits something to another type of user for the other type of user to modify (for example: imagine a site where people submit information about insurance policies), you will have different tools for specific to each user, but you won't want to explain those two sets of tools in detail yet. You'll just want to show this interaction as being the central flow the application. Then in other Powerpoint presentations you'll focus in detail on each tool and maybe do multiple Powerpoints for different sub-tools.

How will these look? Well, you'll have pretty much two types of things you show in the presentation:

1) things popping up and appearing as a result of an action a user does

2) the calculations and database calls necessary to facilitate these actions

Often they will appear together, and often it will be one or the other. The point will be to be as specific as possible. Write mathematical calculations out, don't just explain them. If certain actions can lead to multiple results, don't let your developers guess what will happen. The hardest thing in planning software is that all features can have several sub-features, and all sub-features can have several sub-sub features and so on. Agile development practices propose not to go crazy here. It's important to keep it moving. You can add myriad sub-sub-sub features later. Illustrate exactly what you want to happen, but don't go crazy.

So that's pretty much it for now. Once you get savvy with the Powerpoint interactions, you'll realize that there was way more options than you even thought possible. It's at this point where you'll experience doing this on past projects will come in handy and you'll start to anticipate features you even knew were part of the program before. And you'll start to make smart decisions about how in depth to go, and whether to make it so every checkbox selected leads to another group of checkboxes to select from or whether to just stop at the first, maybe 2nd, sub-feature for now.

Remember, the reason we do software is because of the barrier to entry. The point is that we don't need much human resources and physical resources to be very successful with software and the internet. Do everything you can to keep your barrier to entry at a minimum, and plan your software with out every frill. Add them later in stages. Here's some helfpul links:

http://en.wikipedia.org/wiki/Agile_software_development

http://en.wikipedia.org/wiki/Waterfall_model

http://en.wikipedia.org/wiki/Extreme_Programming

HINT: A Repeat Waterfall Model based on simple iterations of what you're going for is a good place to start. Check out those links and you'll know what I'm talking about.