Sometimes you can’t just code it and get it right first time. Sometimes you actually need to think about things before you start cranking out the code. Nevermind that mostly you don’t have a hope of figuring things out until after you start coding, a little thinking won’t hurt, right? How can it hurt to try and understand things?
One thing that I’ve only recently discovered is that people who are trying to draw a flowchart of a process or are trying to come up with a look for a report or web page do a weird thing: they start thinking that their sketch is a real working design. They start to think that they have “solved” it and they have “the” design. I’ll tell you what is bad about that: at that stage you understand about 12% of the problem or maybe 7% of what the system is supposed to do. If you have managed to understand the whole problem in your mind and solved it right you have either: got a simple problem, so get coding; or, you’ve mistaken the problem and won’t find the issues until you do start coding.
One thing that I’ve found really helps is to make people work on paper. The paper sketch emphasizes that the models are all throwaway anyway and they will spend less time polishing the visuals and making sure that they are using the “right” flowchart shape and more time thinking about the ideas. The less time people work on a thing, the less they get attached to it and the less they think that it is “their baby” and needs to be defended against changes. The other thing is, you can’t make a paper sketch and kick it over the wall to “them” and expect “them” to implement it. The sketch nly makes sense as part of a conversation, and there is nothing better than a conversation for conveying intent, and fulfilling intentions is what design is all about.
Also, when you are working on paper, make sure that you are using a felt pen or other chunky marker. Don’t try to write with a mechanical 0.3mm pencil thinking that you’ll be better off being able to cram stuff on. Less is more, you don’t need to include the actual details of what types you are using or what shape the button will be, don’t get hung up on that! Using a big marker constrains what you can get on a page. can’t get enough on? Use bigger paper and keep sketching big!
You will struggle with the detail-oriented folks who think that details are more important and think the big picture is “obvious”. Possibly they think that everyone “gets it” already and there is nothing to think about. Or, there are those who are smart enough to handle more than one layer of detail; they might think they can handle all the levels of detail at the same time. How do we cope with these people? My only suggestion is do some drawing of your own, radically re-orient all their concepts; keep their details but invert and intussuscept all the big things. Twist and turn and show them their own ideas upside and see if they can pick problems. Not just layout; but change the timing, the chronological order, any hierarchy you can find, any chicken-and-egg, invert everything and shake it up. If you can’t find any problems then keep those details, it might work! If it all looks different once you’ve started thinking laterally you might convert them to thinking BIG first.
It seems a damn shame that we still haven’t got anything as fast as working on paper. I’ve used Google Notebook for working on brain dumping web searches and throwing ideas down using and a lot of success in work capturing unstructured and semi-structured requirements and use-cases using the excellent Microsoft OneNote, but it is still nowhere near as fast as using a piece of paper to sketch and draw. I’m hoping that I can try using a graphics tablet or tablet PC and OneNote. I have a feeling that the ability to draw and the use of OneNote’s OCR stuff (did you know windows 7 has OCR on TIFF images for free? So you can index images by search if there is text in the picture).
Then there are the UI sketch tools like Balsamiq, which I like very much but still aren’t as fast as paper. And, of course, when I draw a picture I want it to be a picture of the database design and the conceptual links and which system module that thing lives in and a picture of the UI on one page.
Of course I’m not the only person touting this; it really echoed stuff I read on Nielsen about paper prototyping and how fast it is to do a cycle with users compared to how long a real UAT takes. The other favourite of mine is the 37 signals blog on using a sharpie to sketch a UI.