Two Rectangles: A Prototype Story
This story goes back 30 years and I no longer have the sheet of paper with two rectangles on it that hung on my office wall for quite some time. Those two rectangles were proof that the problem we faced can be solved. This is what it looked like:
The rectangle on the left represents the space where the task list had to be printed, the one on the right was the place for the appointments.
Printing those rectangles at the exact right locations, matching the dimensions to the preprinted forms, proved that we can do this. The project could proceed, because with this out of the way we knew how to solve every bit of it.
The Problem
The company was selling a lot, over 260, different beautiful preprinted forms that people would buy to put in their beautiful, mostly leather bound, Day Planner binders. The current version of the app printed only on 4 blank forms, representing the 4 binder sizes. The thinking in the dev team was that it would not be possible to support printing on all forms in the 7 months we have before the unmovable release date.
Here how we stated the prototype problem:
- Reduce the problem from printing 260+ different pages to maybe a dozen components that can print within a specified rectangle on a page.
- Describe the pre-printed forms in a human readable data file using the dimensions of the form elements measured in inches.
- Govern the printing based on the above data file.
If we can do this, then we can get the text printed even between the lines printed on those pretty forms.
We had to prove the idea with a prototype. And we had to prove it quick, because if we think that this feature won’t make the release, then we’ll have to work on the next valuable feature. The pressure was on! Printing was by far the most requested feature.
Modeling the Page
After doing a quick analysis of the problem, we concluded that there are eleven distinct elements on the pages that we had to print. We had to capture the dimensions of the page elements. What would be a convenient data file format? We were all familiar with the Windows .ini
files, so that’s what we picked. We renamed the extension to .pdf
for Page Description File. The “other” PDF just wasn’t that popular yet.
The Prototype
The proof that we can do this became simpler than we initially thought. Adopting a coordinate system, we set out the measure the page elements from the side of the page, and transcribed the measurements directly into the data files representing the page.
Why did we choose human readable data files? Because this allowed someone to put a ruler on the page, and immediately type up the measurements in inches, without doing any further math. This critical design decision allowed us to enroll the entire Technical Support Team to create page description files. The dev team created about 20 or so. The rest was created by the technical support folks.
This activity also served as training for them. By the time the product shipped, they knew everything there was to know about printing, and also knew how to fix just about any printing problem they encounter.
Conclusion
A well chosen prototype will de-risk the project and help the team validate design decisions early, when the cost is low, and the investment is minimal.
Once the risks are reduced, the development can proceed at a fast pace. As features are getting completed the morale visibly increases and the team is feeling better and better about the accomplishments, which in turn helps them focus and succeed beyond their original expectations.
Go ahead and prototype something today!