Scrap
Scrap is a simple tool for collecting and sharing scraps of information, like a camera roll for things you want to remember. It began as a design research project at Carnegie Mellon in 2012, and subsequently developed into a series of interface design and web development projects. Scrap is an ongoing project, so the work shown here is a summary of the design process thus far.
Research
We began Scrap as a design research project. Through two Small Undergraduate Research Grants (SURG) from Carnegie Mellon in 2012 and 2013, we sought to understand how people organize information in physical contexts and collaborative situations, with the intent of using these findings to inform the design of a digital product
Findings
Over the course of the research phase, we isolated four salient tendencies in the ways people structure and share information in the real world.
Spatial
Overwhelmingly, when using notebooks, whiteboards, sticky notes, scrapbooks, and other physical means of collecting and organization data, people group information spatially, typically using scale and position to communicate relationship and importance.
Organic and evolutionary
These structures were predominantly organic, often only making sense within themselves and evolving slowly over time to reflect the needs of the moment. As people progress through a project, the way they group and prioritize information could change dramatically.
Seamless transition between digital and physical
Even though the focus of the project was on physical means of recording and grouping information, we couldn’t help but notice how seamlessly people move between digital and physical tools.
Fragmented and forgotten
Over the course of a given project, we found that the data collected was inevitably forgotten. Notebooks and whiteboard drawings are often lost, and digital information is scattered across emails, various social tools, and files, making it difficult to reflect on or improve one’s process.
Goals
These findings informed our selection of three goals, in descending order of priority, for the digital product we were to design in the next phase of the project.
Spatial and relativistic
We were intent that the product take advantage of the primal efficiency of our spatial memory, combining the reliability and shareability of the digital product with the subconscious ease of spatial organization.
Collaborative
Physical tools like butcher paper, sticky notes, and whiteboards facilitate and invite live collaboration more naturally than most digital tools. At the same time, of course, digital tools allow for simultaneous or asynchronous collaboration across physical space. We wanted a product that was innately collaborative from day one, so that the best of these two ways of working could be brought together.
Evolutionary
One of our most important and surprising findings was the speed and degree to which collaborative projects change over time. A digital tool whose design is informed by this way of working should accommodate this chaotic and unpredictable process.
Broadly speaking, the product design and implementation phase of the project can be divided into four phases.
- An aggressively spatial zooming user interface.
- A minimal, recursively structured linear interface.
- A project-focused linear interface.
- A hybrid two-dimensional interface focused on information density.
1 Zooming
For the first couple of years of the project, we explored zooming interfaces. There is a substantial decades-old body of research on these interfaces, and we used this as the foundation for our work in this area. Purely spatial organization made sense — it allowed for information architecture of each project to evolve dynamically and leveraged users’ unconscious spatial memory, something that many interfaces do not. These prototypes were fun to design and build, but in real world use, we ran into some substantial problems.
Though we explored a wide range of approaches to designing a purely spatial organizational interface, a few principles remained consistent throughout the process. In every iteration, the product consisted of a collection of user-created spaces — each of which typically mapped to a real-world project — in which users could freely organize bits of content, ranging from YouTube videos to text notes to webpages, by position and scale.

Initially, we explored producing an iPad app, but found that, in spite of its other virtues, users didn’t view that platform as a place for productivity. Since we didn’t want to fight two battles at once — building a product people wanted to use and convincing them to shift their productivity to a new platform — we shifted to developing a web app for the remainder of the project, with an eye towards mobile applications in the future.




We explored a broad range of visual design languages. We converged on a heavy, graphical approach that accommodated dramatic shifts in scale and gave our product a distinctive visual personality.
Problems
Lack of affordance
The product did not present itself in a way that instructed the user as to its use — a blank sheet of paper can be very intimidating. This did, however, create opportunity for testers to come up with organizational schemes we hadn’t anticipated.
Decay
Spaces became less useful over time. Structures that made sense at the outset of a project would often become ineffective, and it placed a significant burden on users to reorganize their content.
Demanding on users
The flexibility of the interface had a dark side: it was too demanding on users. It required significant effort for a user to keep a space orderly, which served both naturally organized and disorganized users poorly.
Inscrutable to code
While we did develop a clustering algorithm that would attempt to construe taxonomic relationships of stored items based on relative scale and position, it never worked well enough to earn the trust of users.
Potential
However, zoomable spaces worked well as contiguous environments in which multiple people could work simultaneously. And they allowed for emergence of natural organizational structures. We also learned that a distinctive interface comes with an inherent benefit: people came to the project without many preconceptions.
2 Linear
While developing the zooming user interface, we explored an alternate approach that exemplified the opposite — a strictly linear, explicitly hierarchical linear interface. The product architecture — sharable spaces containing nested fragments of visual information — remained the same (it even used the same database), but interface structure was philosophically antithetical.
This design direction attempted to address three of its predecessor’s weaknesses:
- The very steep learning curve of a totally spatial organizational system.
- The requirement that the user invest significant effort — or any effort at all — into keeping their spaces organized.
- Poor readability of textual content.



A strictly linear layout addressed these concerns. By default, the interface sorted everything chronologically, so even if a user put no effort at all into organizing their content, the space would maintain a baseline of orderliness. Moreover, there was only one organizational variable: position in a linear sequence. Gone were scaling and pixel-by-pixel, two-axis positioning. And of course, a strictly linear interface — whether horizontal or vertical — supported the use of a baseline grid and uniform typographic design, leading to a significant increase in readability.

This phase of the project presented an opportunity to standardize the layouts of the various kinds of content users were collecting.
Findings
After designing, developing, and using several iterations of this approach, we isolated a few areas for improvement.
Lack of visual hierarchy
While the product supported explicit hierarchies in the form of stacking, the visual uniformity and linearity of the interface poorly accommodated the retrieval and reorganization of data.
Low information density
We overcorrected the poor typographic experience provided by the zooming interface. While readable and rigorous typographic design is important in the abstract, we found ourselves and our testers weren’t actually saving very much purely textual content. Therefore, we concluded that a visually denser, less typographic interface layout would serve users better.
Importance of projects
In pursuing this direction, we failed to grasp the importance of projects as an important construct in the minds of users. We presented the product as an organizational tool, without considering that the spaces users were creating most often mapped onto their real world projects. In our next phase, we redesigned the top level of the interface to reflect this.
3 Packs
Goals and communication
Even though the project began as general organizational tool, we eventually found it necessary to constrain the project to a fixed problem space when promoting it from prototype to real product. We reconceptualized it as a tool to keep everything for a project in one place, with a focus on simple projects like school projects, vacation planning, and side projects. In particular, we focused on how the tool allows you to organize things by why they’re relevant to you, not by what kind of thing they are.
It’s easy to traverse multiple tools, like Dropbox, Pinterest, notes, and email, when working as an individual. And there are many great tools for coordinating larger projects and more complex teams, like Slack, Basecamp, and flow. But small projects — planning a family vacation, a group school project, or managing a weekend project — are harder to manage. Stuff gets lost in message threads and between multiple accounts. You have to manage permissions and sharing separately for every service. And tools like Dropbox and Google Drive too focused on files; most of what we share are links, videos, and other things not found in your file system.
To make it easier for people to understand the project and how it might fit into their lives, we realized the stated use case of the product should be narrower than its intended use. We experimented with embedding the content itself — a link would produce a view to the webpage — but dialed this back so you can open music and videos in line.
Core navigation
Each project was a big, color-coded “pack”, within which collaborators save notes, links, videos, and more. These cards could be easily stacked and rearranged as the project evolved.
Most people maintain only a handful projects, so we kept the top level of the product really elementary — a spread of big, simple projects. Originally, Scrap allowed you to organize cards however you want, an anarchic approach that demanded too much of the user and made the core purpose of the product unclear.
Scanability was a priority, so reduced our previously two-dimensional layout to a one-dimensional list that expands to fill the largest dimension of display. We wanted each project to be a respected as shared space, not to be seen as a dumping ground for content. Each item was surrounded by ample space, while still allowing users to quickly skim through the content.
Visuals
From the start, we wanted to stand apart from the baroque complexities existing project management tools. Instead, through a deliberate contrast of sober type with exuberant motion and color, we sought a juxtaposition of crisp minimalism and playful buoyancy. From the core navigation to the typography to the motion design, borrow certain mechanics and metaphors of tools from the real world, without appropriating their materials and aesthetics.
Project-specific accent colors indicated the current project at a glance and give each project distinctive visual character. We developed a generative color palette for this purpose.
A consistent but varied application of Neue Haas Unica allowed text to stand out where necessary and recede other contexts.
Website
The website promoting the app uses three example projects to illustrate three critical features.
Highlighting the projects keeps the focus on the core purpose of the product — a home for your projects — and allows the visual character of the interface to function as an identity for the project itself.
4 Grid
Bookmarking
Despite the clarity that a focus on projects brought to the product, we realized that it was the wrong contextualization. The proliferation of group messaging in both work and personal contexts made it difficult to argue that any other product could be a home for your projects. More importantly, we noticed that we and our testers weren’t using the product that way. Instead, we were using it in conjunction with many other tools — email, messaging, Dropbox, Pinterest, etc. — as a catch-all bookmarking tool.
These insights led to a significant rethinking of the product. We dropped the orientation around projects and refocused the product around saving things you find on the web or phone — a camera roll for stuff you want to remember. This was prompted partly by our observation that people of widely varying skill levels, ages, and cultural backgrounds reflexively screenshot things they want to remember.
This change in purpose led to the first significant change in product architecture since the project’s inception. We borrowed the organizational model of the iCloud Photos platform, which maintains a chronologically ordered, automatically grouped Photos view, and a separate-but-equal Albums view that allows users to manually group photos. This model made sense for our product, since we realized that forcing users to categorize everything they were saving was excluding many uses for the product. At the same time, it allows for users to create organization where necessary. Users of varying degrees of fastidiousness found this model more approachable than its predecessor.
Layout
In addition to changes in the structure of the product, this refocus brought major changes to the interface itself. A prioritization of visual content over textual content made information density a higher priority than linearity and typographic consistency. In particular, a rigorous typographic system is less valuable when the content is mostly visual. Most of the typographic content being saved were screenshots and clippings of other webpages, the contents of which vary widely in size, color, typeface, and general readability.
To address these changes, we created a maximally dense two dimensional content view. The interface was split into a chronologically sorted “Recents” tab and a user-curated “Packs” tab.
Labels
After using this, however, we concluded that this layout was unnecessarily heavy and complicated given the underlying simplicity of the content. While designing an interface for dragging and dropping labels onto cards as a means of categorizing them, it occurred to us that we should simply use this as the interface for moving between collections.


Semantic cursors and depth
Currently, we’re exploring the use of depth and context-specific cursors to create affordances and progressively disclose information in layers.
Extension
A critical component of this phase was the design and development of a browser extension that allows users to capture whole webpages, objects on pages (like embedded videos), and even clippings of pages with one or two clicks.
Mobile
At this phase in the project, we also made a preliminary pass at designing Scrap for mobile.
Android






iOS





