Ok, so you get the idea that you have to get your layouts very precise and thorough. The next thing to know is that these layouts can’t be crappy “wireframes.” Checkout what a wireframe is: http://en.wikipedia.org/wiki/Website_wireframe . Lots of companies say they’re building wireframes to spec their product. Every time I hear that I laugh! That’s the stupidest crap ever. It’s not thorough enough. Just look at that image on the right side of that page. Notice the box with the X through it. That’s not thorough enough. For the list of attachments, what if the list of attachments doesn’t precisely fit in that box? Does the box get taller and now there are 3 boxes on the same row that are not all equal in height and therefore don’t look as good as initially imagined in this crappy wireframe? Does it get scrollbars? Is there paging in that box? This wireframe didn’t cover that information, and most don’t--and that’s just the beginning of all the sub-features your application needs to be complete.

Wireframes, whatever they are, do not go deep enough. All they are is just placing little vague components on a page that too generally represent what should go there. What you need to do is graphically design how every page will work, and then pin-point potential problems (e.g. missing paging links) and then design those in, and repeat.

So the technique I’ve pioneered--and say that because I think have--is copy/pasting elements from other applications/sites and combining them into basically a collage that represents one of the pages I’ve specced. Let me explain that further: I visit a web application that has a user interface that I like, then i click “print screen” and paste it into graphic design program, and crop out the full-featured component I need and paste it into the current layout I’m working on. That means my “wireframe components” are real components from other sites/apps.

The next thing I do is have our designer start designing what I have. Then when she makes cool components according to the branding style she’s been working on--and as I’m continuing to evolve the page--I grab her components and drop them in instead, i.e. replace what I copy/pasted from another site.

The idea is that real graphically designed components will drastically change your view/opinion of how your application should function. You’ll learn all you truly need from what other sites/apps have. And then on top of that, the graphic designer needs to get the best influences for what you want as possible. When you’re using interface components from other sites/apps, you’re inevitably picking components not just for function but because of the beauty of their style. So that means you’re also giving hints and clues to influence your designer’s direction, and therefore save time and money on the graphic design aspect.

What will ensue is a rinse & repeat process where you’re grabbing components from other sites,  while your designer is branding them in your app’s style (which is also evolving simultaneously), and then you’re replacing the components from other sites with the one your designer made. If you’re doing this correctly, you’ll have magic moments where you completely change one interface component to another one that is a lot more beautiful that accomplishes the same function. The reason this happens is because you’ll look at what your designer made and realize it didn’t work as well as you thought.

Now imagine you planned your entire application with black and white wireframes, and then you get to the end where you’re forcing your designer to design with such tight layout requirements. What will happen then is you’ll realize you need to change your whole plan because the ideal interface is something totally different, and in fact causes changes all the way down to the application server code, and of course the clientside Javascript/jQuery code. This is why you need to experiment with what you’re application will look like when it’s done very early on. It’s why you must examine how complete features turned out on other sites, and try to emulate those in all their details. It’s why you must try them out in combination with your other components and elements on the page, and see if it works in your case. What worked on another site might not actually end up working on your own site because of everything else going on in the page.

Creators of these other sites/apps ended up solving problems that there is no way for you to know you will have until you get to a phase where you’re testing your application. The only other way to think of these things is through your own experience of knowing potential problems from your past completed apps. However, if you’re new to this, you won’t have that luxury. You know how many times, I’ve seen page layouts missing paging, filtering and sorting for lists of data! Too many. Those basic things can drastically change the design of the page, and also can definitely change the inner workings of your application code. Filtering data can sometimes depend on complex relationships between the entities in your system. If you’re coders don’t know you plan to filter the data in certain ways, well, they won’t write the code to do so. I need to see a dropdown menu with a list of all the filter options! I.e. just the dropdown with the name of one filtering option in it is not enough. That’s how thorough your specs must be.

Be thorough in your layouts. Force yourself to imagine farther and farther into the features of your application until you truly can’t go any farther. So may say this risks a never-ending stage of “analysis paralysis.” For some that will be the case. That will be the case if you’re new to this for sure. But if you’re new to this, it’s only going to get worse once you start development. And what’s worse: a costly phase of development that takes forever and possibly never completes? OR, a painfully long phase of planning that doesn’t cost you much because you’re doing it yourself? I think the answer is pretty clear. If you’re serious about your application you’ll finish the planning phase.

Honestly, it’s taken me years to get as good at speccing as I am. It’s taken me executing many products I thought I specced 100%, and realizing I didn’t to learn what I need to add to my specs next time. That’s just the reality. That’s why I recommend doing software as a business (i.e. for clients) before you jump on your own startup, and of course start small when you finally do your own startup. You need to learn from your mistakes. If you’re new to this, you’ll inevitably make many mistakes. So do all you can on your own dime, and if you’re not technical, that means making specs. Send your specs to a professional to review and point out things missing. Hire FaceySpacey simply to do that. Have meetings with your developers along the way about questions they have. Borrow as much as you can from other full-featured launched applications as you can, and play off what they got right. Make these layouts your life. It’s your playground. Get quick at re-arranging them. Constantly ask yourself the questions of what’s missing and what other features I need to truly make this sing. When you know all the things it needs, then peel out as much as you can that’s not crucial, and replace them with the simplest way to patch up the hole. But lastly, if you’re new to this: do something so small and get it launched, and see all the work that goes into getting it launched, and by doing so give yourself a dose of humility which will come by seeing all the things you missed in the planning phase that was ultimately needed before it could go live.