By the end of the quarter, you'll be required to submit a web-based process book, detailing (1) the process that led to your team's final design and (2) your specific contributions to the process. Traditionally, process books are printed, bound, and placed on a coffee table, but you'll be creating a web page instead, since this is more useful to include in web-based portfolios. Below, I detail what a process book is, I provide some examples, and then I discuss my expectations of your process book for this class.
what is a process book?
Traditionally, process books are usually used to communicate to clients where a design came from (usually so that clients understand why they're paying so much for the design!). Your process book should tell a coherent story about the process that led to your team's final design, while also detailing your role in the emergence of your team's final design.
Here's one process book by my friend Jeff Nichols, from when he was a student in a design class at Carnegie Mellon. What's good about this process book is it's consistent visual design. It tells the story of where the design came from with words, selecting sketches and diagrams from the design process to convey how Jeff went from just an idea to a detailed design for a tool called Magic Lens. You can see the full example on his website.
Here's another example from a design firm called GD Loft. Notice how each page uses clear, but distinct visual elements to tell the story of the design process. What's best about this example is the visual clarity of each of the pages. While each page has a distinct visual style, there is consistency in the faded colors, the fonts, and the effective use of whitespace.
Both of these are quite different in their visual design, but they both do a nice job of explaining the origins of the design.
good process books from previous quarters
Here are five examples of process books that did a nice job communicating the team's process and the student's contribution to it:
All of these received a perfect or near perfect score.
So what about your process book? Even though you designed as a team, you will produce your own process books as individuals (thought it is okay to share content from your process, such as sketches or critiques; just make it clear what was your work and what wasn't). Your process book should include:
Things you created as part of your process, carefully selected from your work this quarter. You should decide how to break down your process; you might decide, for example, to follow the structure of the homework assignments and have ten steps. Or, you might look at your process and decide there were really four big transitions and tell the story that way. It's up to you to decide what to include and how to structure it. Anything you created during the quarter could appear in your book, from notecards, sketches, or homeworks, to sketches on napkins never turned in for credit. You can also include things your team created together, but in these cases, you should explain your contributions to the collaborative work.
Exposition about these artifacts to tell your story. For example, you might describe an artifact and how its creation moved your design forward. You might explain how one design took you to a dead end. You might also include other work from the class (lab or activity deliverables) that gave you an idea for a prototype. For examples of exposition, look at Jeff's process book above or find more examples online.
Your process book must comply with the following constraints:
- Your book must include your full name, a title, and must say "INFO 360 Autumn 2012".
Every other aspect of the book is up to you. There are no other restrictions on what is inside: you must decide on every aspect of the material and presentation and ensure it's in support of the story you're trying to tell.
You'll be required to submit a URL to your process book, hosted on your UW student web space or some other hosting service (e.g., Google Sites). The design for it is completely open-ended: it can be a single page, multiple linked pages, a series of images you created in Illustrator, or even just a URL to a PDF document with a more traditional process book. As long as it satisfies the grading criteria below, your process book will fare fine.
design your book
A process book, like all other things in this course, is a designed artifact. Therefore, you should utilize the design skills you learned throughout the quarter to design your your book. Think of a vision for how to communicate your process that unifies everything inside of the book. Even better, conceive of a vision that is consistent with the goals of the design project. Sketch it; plan what will go on each page with a storyboard; prototype pages before you finalize them. Only after you have a design for your book should you actually create the book.
A good process book—and one that deserves an exceptional grade—will have the following qualities (detailed in the rubric below):
It is clear from reading the book through what process the design emerged. The book should explain not only what decisions were made, but how they were made. Did an insight come from a user study or an observation? Did it come from a long discussion with your team at a coffee shop? Unlike your design specification, this is a chance to tell the story behind the decisions. The process book should detail the evolution of your design, from the beginning of the class, until you and your team felt the design was finished. Therefore, if you felt you were still making design decisions while writing the spec or making your video, then write about that.
The book tells a story. A book that simply lists a series of events will be much less compelling than one that describes the tensions and ambiguity early in the process and than relieves those tensions with whatever breakthroughs you experienced. Stories have a beginning, middle, and end; they have conflict; they have resolution.
The main character of the story is the design problem and solution, not you. A book that focuses on you and your team, instead of the design and design process, is not a good process book. You should talk about you and your team to the extent that it makes it clear how you moved the design forward.
The book reflects on the quality of the design process. It's one thing to say where decisions come from; it's another to point out that a decision was really unintentional, or that it was heavily influenced by a particularly outspoken team member. Good process books will speculate about the merits of your decisions and what you might have done differently at various points in the process.
It clearly identifies your role in the team work. I encourage you to include team work in your process book, but it must be clear what your role in it was. And put your role in context; how was your work combined with your team's?
It complies with all of the constraints listed above. Specifications that violate the constraints will not be accepted for credit, so be sure to follow all of them.
If you find these criteria to be vague, it is because there are many ways to achieve the above qualities. If you want to ensure you get a good grade on your process book, design your book: sketch it, plan it, get lots of feedback throughout the process, and only then should you make the actual book.
tools for creating web-based process books
If you decide to create a pure-web based process book (as opposed to a PDF document, for example), there are many places you can host it: