IKIWISI – How to solve the “I’ll know it when I see it” dilemma

IKIWISI!
“I’ll know it when I see it!” That seems to be the current mantra in software/web development.  It means stakeholders don’t know what they want their final web product to be until they see it.

Software and web developers have tried to accommodate these make-it-and-we’ll-see requests through technologies like the WYSIWYG (what you see is what you get) editor.  Products like Protoshare, IRise, and Axure have taken this a step further, creating clickable prototypes which not only gives stakeholders a visual representation of what the site will look like, but can also provide an indication of how it will “breathe” – or to put it in other words, what it will be like for a user to traverse the site: Will it be intuitive? Crowded? Does prioritization of items on the home page make sense? You get a basic answer to these questions with these products.

But it’s an uphill (and unnecessary) battle to try to take specs, create the product in its entirety, show the stakeholder the final version, and expect a quick approval. In fact, since most people (including sophisticated software developers) don’t know what they want until they see it, there’s a good chance that all your work will end with a, “Hmmm. No. That’s not it. Try again.”

So how do you solve the puzzle of what your customers really want, so that you can both be profitable?

I think the solution is to create the final product iteratively.  This high-level chronology is what I use to create websites, and it’s worked well. The process goes like this:

1. Create the Site Map: This includes agreeing on the goals of the homepage, and should incorporate the most recent specs. Without a site map one has almost no framework to work from. The site map will also help you see how the pages relate and will give you an idea of flow through the site. (You will need to communicate that flow through discussions.)
2. Design the homepage and any pages with unique functionality or unique user interface.  This can includes search pages, search results pages, user input pages (forms), etc. Share the designs, make sure that the customer agrees with the overall look and feel. Details can be worked out as you’re moving forward.
3. Begin building the “shell” of the website with live links/navigation and on a server that all stakeholders can easily access.  Usability testing (at least informally) can begin to take place at this point.  If you expect stakeholders to start understanding what they want at this point, you’ll realize that they’re going to request changes.  It’ll still be early enough in the process at this point where you can embrace those changes – which will make your client very happy.
4. Code the remaining functionality of the site.  Unit tests can be written between steps 3 and 4 if that is something your organization engages in. Upon completion of the coding, all unit tests should be passed, and post-production testing should take place. I like to show the client the un-skinned functionality to make sure we’re on the right track.
5. Skin the site.  That is, do any visitor-side programming that needs to be done (CSS/HTML). Make the site look pretty.  Get final approval from the stakeholder.
6. Push the site to live.

Following this order in production of a site can help eliminate the IKIWISI issue from killing your man hours. And remember, keeping stakeholders in the loop throughout the whole process will save developers/designers hundreds of hours of re-dos, redesigns, revisions, etc.