Mockups and visual prototypes can be a great way to get feedback from users before investing too much time into a project. But what if there was a way to get that all-important user perspective with even less effort than it takes to develop wireframes or a skeletal prototype? And what if that method could also give you greater-than-usual insight into your end user’s workflows and needs? In this episode, you’ll see how embracing some mundane tools can lead to near-instantaneous feedback and iteration.
Video transcript & code
One of the most common applications of software is to build systems for tracking, managing, and coordinating human work tasks. Recently, I had a need to create a system like this. Specifically, I needed a way to coordinate and track household chores assigned to my four kids.
I decided to start with a master list of chores. As you can see, I chose the world’s most popular programming system: a spreadsheet.
I started populating the list, filling in the area of the house that the chores pertain to, the name of the chore, and an approximate idea of how often the chore should be performed. Since spreadsheets are schema-less, I didn’t have to spend a long time pondering how chore frequency should be represented.
Once I had a big list of chores to work from, I sorted them by frequency. I saw that most of the chores I had listed needed to be performed at least once per week. So I decided that my next step would be to break down the chores on a weekly schedule. I knew that this would leave out any of the monthly chores. But I judged that it would be easier to treat the monthly chores specially, then to deal with the added complexity of working with a full month view.
Next, I created an elaborate algorithm to evenly distribute the chores across children and days. Just kidding! I manually copied chores from the master list into the week view, relying on my judgment to balance the chores, based not just on amount, but on difficulty and on each child’s preferences and abilities.
At some points, a particular day or child would start to look overloaded. Since I was working in a spreadsheet, it was easy to drag-and-drop chores around until I found a distribution that made sense.
Once I had the chores broken down satisfactorily, it was time to display them out in a user-friendly way. My users are children ages 2 to 9, so I knew I wanted to present them with something simpler and bolder than a crowded week view.
For this task, I decided to switch to a word processor. This enabled me to easily play around with views based on a single day, or based on a single child. I settled on creating separate pages for each day. Then it was just a matter of copying from the spreadsheet to the document.
As I was assembling these views, I realized that I was running out of space per page. I decided to fiddle around with the page layout. Moving the name of the child beside their chore list instead of above it freed up a bunch of vertical space. This is where the choice of using a word processor really paid off. Using Photoshop to mock up these views would’ve given me far more leeway than I needed. Using raw HTML would have meant a lot of messing around in CSS to get the effect I wanted. Using a word processor allowed me just enough freedom to adjust the layout, while keeping the focus on the content. If I later need to publish these pages as HTML, it will be easier for me to work backwards from this concrete layout then it would be for me to code up the HTML and CSS from scratch.
Finally, it was time to publish this prototype application in a way that the kids can actually use it. As a technical platform, I chose: good old ink-on-paper.
Of course, there were bugs in the first iteration. Choosing to print the pages on paper meant that I could easily fix these issues in production by crossing out or adding entries with a pen.
As you can see, the end users also provided numerous annotations of their own! This is a possibility that’s completely missing from most software systems: the ability to directly annotate the screens as they are in use!
Using the prototype chore schedule also revealed issues that I never could’ve identified while I was designing it. Such as chores that I’d forgotten; separate chores that really ought to be merged into one; or child with a disproportionate amount of work to do.
If I had kept the chore schedule in software form, I would’ve had to find somewhere separate to note down all of these issues for future revisions. But because I chose a paper artifact, I could scribble these notes on the system itself as I was using it, without any disruption.
One issue that cropped up was resource contention. It was impossible for one child to wash the dishes while the others were still unloading the dishwasher. For the next iteration, I moved to dishwashing chore much later on the list, so that other children would have time to finish putting away dishes first.
This revealed a particularly important insight into the problem domain: with finicky temporal dependencies like this one, it would be important to always allow manual reordering of chores within a given day. A system that simply listed chores in order of entry or name wouldn’t cut it.
At this point, I had identified three concrete screens that are important for my chore organization system. A master list of chores. A weekly view. And daily pages broken down by child.
This gave me a solid starting point for a real software system. But I also realized something: for my purposes, it would probably be good enough to simply tweak the day pages I’d come up with as needed, and then print them out once a week. Or maybe laminate them, and use them with dry erase markers.
And this was a valuable piece of market insight: maybe the reason that there is no software as a service company making hundreds of millions of dollars off of household chore management is that for most families, a spreadsheet and/or a Word document are Good Enough!
The reason I’m telling you this story is because I think too often, when we set about to create mockups or prototypes for a software system, we do both too much and too little. We jump straight into investing considerable time in Photoshop comps, HTML mockups, or a skeletal software application. And as a result we miss out on what can be accomplished with existing productivity tools and physical artifacts.
When we developers talk about creating a system, we often think of it implicitly as creating a software system. But really, what people hire us for is to identify, clarify, and facilitate a system of work. What if we made our first approximation of that system using tools like pencil and paper, spreadsheets, and word processors that are accessible and writeable by everyone involved? We might just capture some early insights that avoid the need for rework later. Or, we might even discover that that the software we were planning on writing isn’t needed, and our efforts are better spent in a different area. Happy hacking!