First Experience
A long time ago I had a whole weekend all to myself (for many years this has been very unusual). At the time I was living and working in Lusaka Zambia (sub-Saharan Africa) and my wife was going away for a three-day weekend to see elephants with the gals in Kafue National Park. True story.
I had long been arguing that the application I was working on, an Electronic Medical Record for the Zambian Ministry of Health, would be more effective if it was implemented in Java Swing instead of .Net WinForms (that is another story entirely). So I decided to take the three days and build a Java Swing prototype.
For a few months I had been envisioning in my head a superior user interface and experience. It was to include the best parts of our current touchscreen-based user interface but also include new concepts that were difficult to express in WinForms. So the question before me was how to start and how to organize my work so that I had a game plan.
Just Started to Draw
For some unknown reason I started to draw. I drew first the new flow-oriented patient encounter and then started to toy with the placement of the patient dashboard along with various other features. Before long I had several pages of user interface all sketched out in pencil.
Coding It All Up…
Over the course of the weekend and with the help of pitchers of iced Kenyan coffee I coded up each sketch. One just flew after another. I had never been more productive, there were no visual decisions to make, they were all there in the sketches.
When the weekend was over I was truly amazed with what I had accomplished. Three days had let me construct the application that I had in my head for months and had been arguing for, for longer than that. Not only was a compelling case for the switch to swing it was a great shot in the arm for me personally in terms of my confidence with Swing and my ability to rapidly prototype. In addition, the prototype was very well received by our Zambian engineers as well as by our ex-patriot management.
As it were, the stars were not aligned and ultimately we were not able to shift technologies from .Net to Java. However I learned an important lesson about the power of storyboards to enable high productivity.
A Bigger Project
Many years later (and hundreds of storyboards), when building a new EMR for the U.S. market, I returned to this methodology again, but took it to a new level. My role was as a “managing” architect and I actually storyboarded out the entire application from the general screens to the reusable widgets. I even storyboarded out the animation sequences. This time around it was a project in .Net 4 (beta at the time) using the Windows Presentation Framework (WPF) as the UI toolkit.
The new wrinkle I explored this time was exploring the user experience with the CEO and the Director of Product Development prior to building the system. We iterated a few times over organization and placement of several items until we all agreed on a set of drawings to code against.
Draw Once & Photocopy for All
This time I had my own team and my inclination was to enable the same productivity in each engineer that I had created in myself. To achieve this I simply made “the packet.” I simply photocopied all of my sketches into a 30-page packet and handed them out to each member of the team. As we went through and built out the UI components each engineer got assigned a page in “the packet.” Productivity was high and we quickly assembled the application based upon the drawings.
The moment that I sincerely knew that I was on to something valuable in a broad sense came in a post-meeting chat with one of my engineers. The CEO had outlined a new feature in the application that was going to require a few new screens we hadn’t planned for. I asked the engineer how long he thought it was going to take him to develop them. His reply was:
“If you give me the pictures again, one day, if I have to figure all that stuff out, one week.”
P.S. I will post some scanned storyboards from my past shortly.