June 04, 2021
Starting from early in the process, I had implemented an “engineering UI” built with Storybook JS . This would embody all the core functionality and expose all the parameters. This allowed me to begin prototyping and to experiment with customizing notebooks for my personal daily use and insight.
Eating My Own Dog Food
Notebook Version 1
Notebook Version 2
Notebook Version 3
Notebook Version 4 (Current)
Using the “engineering UI”, I ran some experiments to observe the process of creating a notebook with an everyday printer and paper. The iterations I went through (below) helped me understand 1) the more important things about making notebooks and 2) how to down-scope my list of feature ideas to a critical set.
This article documents my findings and shows the latest iteration.
- Choose notebook size
- Choose notebook binding and orientation
- Choose source paper size
- Choose pattern
- Choose pattern color
- Decide page number setting
- Preview in browser
- Set up browser
- Print Test Sample
- Fold or cut pages
- Bind text block
- Cover decoration, etc
Set up notebook
Set up paper
I synthesized my observations during dogfooding and researched how notebooks are described in the marketplace. The following workflow is what I came up with:
|1. Set up notebook||2. Set up paper||3. Print||4. Assemble|
|User Goal||Establish basic or external “specs” of a notebook||Establish internal look of the paper||Produce all pages (text block)||Put raw materials together into final notebook|
|How Folio Forge Helps||Get started quickly and easily with a template or choose from notebook based on paper size.||Show live preview at all times.||Print previews and test prints to help print with confidence.||Page numbers are pre-arranged to minimize manual labor.|
Below are the same workflow stages in more detail:
The degree of usable customizability is one of the fundamental value propositions to this app.
One implication of this level of customization is that we’ll need to deliver customized instructions depending on their browser and printer capabilities.
Help the user visualize
The design should help visualize the consequence of the user’s selections to help them maintain the vision of the result. In addition, the design should give the user immediate feedback after she makes a choice, such as when selecting a page orientation or the color of the print pattern.
Choosing notebook size and orientation
The first iteration explored layout, providing easy access to controls and helping the user maintain sight of the result of adjusting the controls.
One idea was to let the user define several sections within a single notebook, each having a different pattern. I had thought it might be interesting to offer this as a distinguishing capability since I didn’t see anyone else offering this level of customizability.
Spoiler alert: It wasn’t until I made a notebook with different types of filler that I realized it was a bad idea. See the second iteration for details.
Choosing notebook size and orientation
Animated walkthrough: Choosing notebook size and orientation
Choosing a print pattern
Animated walkthrough: Choosing a print pattern
Compared to the previous iteration, I added more fidelity to which types of help to give the user. I also hint at the ability to “Print Detailed Instructions”, and “Print a Test Run”, which seemed they would be valuable from my “dogfooding”. Still a way to go, however. Without user testing, it will be difficult to predict where people get stuck battling with printer issues.
I abandoned the last iteration because it overly focused on adding sections to a notebook, which I discovered should not have been in the core set of features.
With the wrong feature out of the way, I could focus more on the design’s core. As a result, the second iteration felt more resonant with what the app needed to be.
One of the breakthroughs for this iteration was realizing just how visual the selection process could (and should) be. Again, this is related to the principle of favoring “recognition” over “recall.”
|Iteration 1||Iteration 2|
Letting the user fiddle around with settings.
Be sure to let the user see the result from changing settings and tweak it until they are satisfied.
|The gallery approach lets the user look through the number of possibilities and pick the best one.|
|Result||Too fiddly||Felt much better *|
Lesson learned #1: Having the wrong feature considered as the core functionality is costly! Luckily, not as costly as coding up the wrong feature.
Lesson learned #2: If no one is doing a particular thing, there could be an excellent reason not to be ignored.