Build in Progress was an online community for makers to document and share DIY projects as they’re being developed. The app enabled users to organize their design process into branches, showcasing design iterations in a project.
Making often involves an iterative cycle of testing and re-designing in response to setbacks as well as serendipitous discoveries. Anyone that has designed before knows that projects rarely work on the first try; instead, they are constantly tweaked and refined to function as intended. Yet, this iterative process is rarely shared in traditional forms of recipe-style documentation, where parts of the process are edited out when creating step-by-step instructions. What might documentation look like that captures the full story of how a project was created?
I started the project with a several goals for supporting process-based documentation:
Bring transparency to the design process
The platform should be a venue for sharing experimentation and iteration throughout a design process. The visual representation of design process should convey its iterative nature. Additionally, the community should encourage knowledge sharing about successful and unsuccessful techniques in an effort to help others.
Encourage feedback in progress
Users should be able to solicit feedback as they develop their projects by reaching out to others in the community for advice. By documenting throughout the design process, authors continually build context for others to refer to as they provide feedback.
Create opportunities for authentic reflection
The social community of the site should foster authentic reflection, enabling designers to communicate their process in ways that can help serve other like-minded creators.
A project on Build in Progress consists of steps that can be organized into branches by clicking and dragging step nodes in what was called the "Process Map." The Process Map enabled you to see, from a birdseye view, the overall structure of a project. You could choose to navigate the project by clicking on steps in the Process Map or chronologically by clicking the left and right arrows above the detail view for each step.
Each step could contain images, videos, and text descriptions, along with attached design files. Users could ask for advice to pose a question to the community:
Active questions would then be displayed on the homepage so anyone visiting Build in Progress could help out if they had ideas.
Over time, additional features were added to the project page to aid with organization. For example, labels and pins were added so that you could mark important moments in the process.
For a build log, check out the very meta Build in Progress project on Build in Progress.
One of the wonderful things about creating an online community is that you discover projects from people you've never met before. These are some of my favorite projects that were documented on Build in Progress by members of the community:
Virutal Reality Tour of MAL : This project from students at UC Boulder documented a crowdfunding initiative to build a virtualy reality tour of the awesome Media Archaeology Lab, a home to functioning vintage computing technology open to the public.
Woodside Uncicyle Mechanics: This project is from a school that uses unicycles to teach data analysis, robotics, and more.
Elucidator-Kirito's Blade: A project about fabricating an anime-inspired prop.
Tower Defense Arcade Game and Box: A collaborative project from middle school students creating an arcade game.
Designing and 3D Printing Chess Pieces: A high school student's 3D printing project.
In my dissertation work around sharing design documentation, I refer to process documentation as "makethroughs" since they are shared throughout the design of a project. (This term builds off of the practice of "playthroughs" in the video game community where gamers live-sream their process of playing a game.) Through interviews with Build in Progress creators, I uncovered three major themes regarding makethroughs:
Documenting throughout the design process rather than after a project is complete provides new opportunities for facilitating feedback. taking advantage of this opportunity to garner feedback may require users to be more ‘vulnerable’ by revealing weaknesses of their project. This is quite different from instructional documentation where documentation is not shared until a problem is ‘solved.’ However, in a safe and supportive community, opening up about the potential weaknesses of a project invites others to leave constructive feedback.
The fact that make-through projects are incomplete may make them more inviting for others to leave feedback. As one user stated, “It was really helpful to get feedback during the process, as opposed to, “Here’s my final project. What do you guys think?”
Mke-through documentation can serve as a venue for creative storytelling. Instead of being a list of instructions, make-through documentation can provide outlets for makers who enjoy writing about their design process in creative ways.
By enabling expressive storytelling, make-throughs introduce human elements to design documentation. They begin to reveal the context in which a design is created, which further personalize the documentation. In other words, the documentation itself becomes a form of creative expression in which the maker can communicate their personal journey of creating a design.
Because make-throughs capture both successful and unsuccessful experiments, they can be used as tools to communicate the effort that goes into creating. Many projects on BiP revealed struggles that, yet the final documentation also show how users were able to persevere and use alternative hardware to build their designs.
As instructions typically only shows successful steps, all of their documentation regarding their struggles would normally be excluded. Having space to showcase these efforts can be especially important in educational settings where problem-solving efforts are, in many was, more important than the tangible output of a project.