Scrap

Scrap
2012–
Product design
Front-end development

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.

A recent prototype

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.

Splash page

Mobile

At this phase in the project, we also made a preliminary pass at designing Scrap for mobile.

Android

iOS

Let’s

Let’s
2014
Product design

Let’s was an iOS and Android app for getting friends together and organizing social events — something more robust than messaging but lighter than products like Facebook Events.

Over the course of fourteen months, I worked with four Carnegie Mellon computer science students as a product designer. Throughout the process, I was responsible for visual design, interactive prototyping, research, and setting the direction of the product, as well some front-end development.

iOS

Navigation

The interface is a horizontally paginated list of events you’ve been invited to or created, with the leftmost page being a composer for new events. The events are sorted chronologically, with the most recently accepted invitations towards the left, and old or canceled events towards the right.

Events

After months of exploring (and implementing) a few different directions, we settled on a crisp typographic layout somewhat evocative of print design. For both its clarity and cultural connotations, we wanted the design to evoke the aesthetic of event posters, without imitating them directly or sacrificing visual simplicity and uniformity.

Each event is assigned a random gradient (if you don’t like the colors, you can shake your phone to change them). The entire page acts as a giant on/off indicator, brightening when your accept the invitation and darkening otherwise. Canceled or past events are desaturated, and automatically archived after a day.

Initially, we thought events should be considered the property of the host. But after watching how outings and groups spontaneously form in real world, we concluded that each event should be the collective property of its attendants. For example, the event title can be directly edited by anyone, and all content can be seen by all users.

Sign-up flow

When I joined the project, the app was built around Facebook authentication. We switched to text message authentication because it led to fewer privacy ambiguities for users, an easier text-based invitation flow, and no credentials to remember.

Event creation

The biggest competitor to this product are messaging apps and SMS. Our product has to be simpler and more efficient than sending a few text messages. Therefore, we kept the event creation process simple: Describe the event, then check off the contacts you want to invite. These can be altered at any time by any invitee. Everything else — e.g., specifying time place — takes place in the event’s comment thread. We arrived at this modular approach after observing that organizing social events is ad hoc and varies from occasion to occasion and person to person — sometimes the “who” takes precedent over the “what”, or the “where”, or vice versa.

Guest list

Event invitees (whether or not they have accounts) appear in guest list below the event name. Invitees who have replied affirmatively (either with the app or over SMS) appear opaque and at the top of the list; those who haven’t responded are translucent, at the bottom. We don’t provide a way to reject an invitation, since we observed that invitees would not respond at all if they didn’t want to attend.

Anyone can invite anyone from their phone’s address book at any point in the event’s lifespan. This reinforces the notion that the event is the collective property of attendees, and a living entity.

Comments

Invited guests can reply to the event with comments. Clarifications, apologies for not attending, suggestions, and announcements would all appear here. Host comments are denoted by italics. To simplify the sign up process and visuals, we removed profile pictures in favor of names.

We decided (somewhat counterintuitively) to place the comments above the event because the newest and bottommost comments tend to be the highest priority. Conversely, the guest list is below the event because the top of the guest list is typically the most important to see first.

Android

Android Invite%20Search — Searching contacts for invitees

Android Message%20(Scroll%20bottom) — Comments

Android New%20(In%20Progress) — Posting a new event

Android New%20(Complete) — New event after posting

Android New%20User%20(Filled) — New user

Android New%20User%20(Confirmation) — SMS confirmation

Android development started quite a bit after iOS development, so our main challenge was to balance the distinctive visual identity of Let’s with certain elements of the (then new) Material Design language. The apps are functionally identical, but resemble siblings more than twins.

Web invite

Early on, we recognized the importance of the product working if none of your friends have accounts. You can invite anyone in your contacts to events — invitees without accounts will receive receive a text message with a link to a web preview of the event, where they can accept the invite and view the event description and guest list.

Website

For the promotional website for the app, our goal was to mirror the visual design of the product itself. This was reflective of our desire to make the interface itself the visual identity of the product. Rather then describing what the app did — the job of App and Play Stores entries — we illustrated its functionality through example. Earlier iterations followed a more conventional layout, in which the app (and containing device) would be contextualized as an artifact on the page, but this seemed needlessly expository.

Process

When I joined the project, it was structured around maps and geolocation. We quickly found this information to be irrelevant to the purpose of the product, not to mention creepy.

In the next phase, we decided to use geolocation to determine if people were at the event. This led us to produce a lot of interesting UI and algorithms, but made the product needlessly overwrought and complex.

When we threw out everything but the essentials, we were left with just the event description, a guest list, and a space to ask questions and post updates. This approach was fluid and easy to pick up to a degree that the others weren’t.

It also created a space for different kinds of imagery that could expand each event’s capacity for individuality and expressiveness.

Conclusions

In the course of developing this product, we learned a lot. These three stand out.

A rigorous and growing commitment to simplicity. Almost every improvement came of some needless feature or visual flourish. Early on, we realized that a mobile-first events product had to be simpler than texting your friends, not just simpler than tools like Facebook Events. We threw out weeks of work several times after realizing how little certain technologies contributed to the experience.
The product had to be useful if none of your friends use it. This might be conventional wisdom, but it took us embarrassingly long to give this issue the priority it deserved. Ultimately, this realization led to the most dramatic changes and feature removals, and the current design is a consequence of it.
The experience should reflect the workings of real social interaction as much as technology allowed, which was probably the most difficult constraint to work by.

Parcel

Parcel
Fall 2013
Product design

Created for Dylan Vitone’s Pieces Studio at CMU, Parcel is a news reading app with focus on elevating long form and investigative journalism in mobile contexts. Parcel was designed as a contrast to social feeds — it’s difficult for in-depth writing to standout amidst listicles and baby photos.

This meant the interface had to be a careful presentation of a handful of items, and the content should feel “finishable”, with discrete beginnings and endings. Parcel emphasizes the per-issue narratives, branding, and editorial voice of individual publications, rather than interleaving their content in a feed. At the same time, I didn’t want to merely reformat print layout and aesthetics for mobile, but rather borrow elements of the visual language of print to make it clear to the reader that this is worth your time.

From start to finish, Parcel was designed through a series of interactive prototypes with Framer.js.

Parcel consists of little magazines, each of which contains a handful of the best articles from that source. This elevates the long form content that often is poorly represented in mobile contexts. At the same time, this format seeks to present long form content in the best possible light within mobile constraints. Each issue is meant to feel finite — something you finish. And you can add and remove subscriptions with one tap in the Store.

Home screen

The home screen is a spread of the most recent issues, sorted in reverse chronological order from left to right. Old issues are automatically placed in an archive to the right.

It was important that each issue feel finite and self-contained. Above all, I wanted to reinforce that each was a discrete delivery, and that each was special. A horizontal layout evokes a spread of magazines on a coffee table, creating a strong visual distinction between navigation between issues (horizontal) and within them (vertical). I realized this was possible after noticing that the covers were recognizable even with just a slice of the logo showing, especially since your subscriptions aren’t likely to change on a regular basis.

Covers

From early on, I wanted to separate this product from the frenetic vertical feeds typical of mobile news interfaces, so I gave each issue something evocative of a magazine cover. At the same time, there were important reasons not to slavishly imitate the magazine. The smaller display, faster publishing cycle, and presence of media across multiple platforms meant that a canonical, specially designed cover rich in detail wouldn’t be viable.

Simplicity and visually impact are the priorities. The publisher specifies a key image for each issue, which will be used as the cover. And the use of icon in lieu of a word mark reinforces the feeling of compactness.

Articles

For the articles themselves, the goals were simple: they should be readable, consistent in layout, native to mobile, and not require inordinate layout work from publishers. I wanted to maintain focus on quality content, not interactive gimmicks, so although the product allows for publishers to specify custom typefaces and spot colors, no other customization is possible. This ensures a consistent experience for the reader as they move from source to source. The simplicity and consistency of the article template also helps it to fit into the workflow of a modern web-first publication, so images, videos, and pull quotes can easily be included.

Store

Process

A sampling of some prototypes I produced in the design process.

Saint

Saint
2015
Cofounder
Service design
iOS & development

Over the summer and fall of 2015, I worked with industrial designer Samantha Chiu to prototype a human-powered concierge service prompted by a question: Could on-demand services be made more useful and accessible by abstracting them behind a conversational interface?

We prototyped the service to gauge interest, understand how it might fit into clients’ lives, and assess the difficulty of the project. Samantha coordinated the concierge service itself, while I focused on designing and building its digital components. We tested the service with a couple dozen people, and in the process, designed an iOS app, implemented an SMS-based messaging system, explored business models, and designed communications for service.

Currently, we’re using our findings to inform a new approach to delivering the service. It’s been interesting to see service like Facebook M and GoButler explore this product category.

iPhone app

After narrowing down what the service itself might be, I designed and partially implemented an iOS app.

We eventually postponed the app to focus more on the service itself, and switched to an SMS-based experience, which allowed us to iterate much more rapidly.

Conversational

When we started, we thought, what could be simpler than a human conversation? While it superficially seemed like the most natural experience for clients — everyone knows how to send messages — it crudely masked underlying complexities inherent in the service itself. For example, how would we handle the handoff from one concierge to another? Where does one request end and another again? How does the client indicate which request they’re responding to?

A linear conversation looks simple, but that simplicity glosses over the way the system actually works.

Request-oriented

We then explored how the interface might work if requests were discrete, with messages pertaining to those requests (like questions and clarifications) being subordinate. In addition to better visualizing how the service actually works, it makes the purpose of the product much clearer and optimizes the interface for the most common actions. Testers more quickly grasped what the product was for and how they should talk to it.

Applying a richer structure to the architecture enabled us to explore a diverse variety of layouts. If the conversation is an atomized structure, it creates opportunities to use the typographic layout to drive more efficient usage and better elucidate the functionality.

Website

To elicit feedback on different ways we might illustrate a product we often found challenging to explain, we produced a few iterations of webpages explaining the service. This allowed us to iterate on the copy, layout, and examples simultaneously in response to feedback and the ways we were changing the service.

This was also how testers were able to sign up for the service. We built simple web app to keep track of users and billing information, and to route messages and delegate requests to concierges.

When someone signs up, they immediately receive a welcome message. As soon as they make request or ask a question, they’re assigned to a concierge. When the concierge marks the relationship complete, the connection is closed. If necessary, we collect payment information on a separate page.

View live.

Service

This project was the product of a couple of years of thinking about how one might best build an experience synthesizing the proliferation of on-demand services. There are countless “on-demand” services (admittedly of varying quality and plausibility), but no one will download thirty-seven apps for thirty-seven “Uber for _____” services. Our goal was to abstract these services behind a natural language UI, allowing us to bring services together to solve abstract problems.

This quickly changed. There were three significant phases in our approach to communicating about and delivering the service.

Ultimately, our goal was to make the product essential to just a few people.

On-demand everything

The first and most obvious iteration of the service was as a way to get anything on demand. While was easy to communicate the product, we increasingly found that the requests made were not beyond the scope of what people already knew services could provide (e.g., delivery and home services). We could fulfill requests of much greater complexity, but this was difficult for people to understand. Just as critically, it was not a service clients could make frequent use of.

Moreover, the services we were delegating to were often unreliable and mediocre. People need these things done, but in most situations, there aren’t any services that can reliably take care of them.

And of course, the emergence of services like Magic and GoButler eliminated whatever differentiating qualities this might have had.

Personal assistant

To test this, we responded Craigslist ads for personal assistants. The complexity and variety of clients’ expectations quickly made this infeasible, and it was hard to see how this service could amount to much more than an agency for hiring personal assistants.

We also considered structuring the product around home services. But here, too, clients’ needs were so varied as to make the pricing and scope of the product impossible to pin down. And we found existing cleaning services to be unreliable and inconsistent.

Bespoke

Faced with this, we realized what we should have done from the beginning: co-design the service with a single individual, without any presuppositions about what they might need or how they might want it delivered. Repeat this process with different individuals until patterns emerge. Where do clients struggle in their daily routines? What activities to they feel comfortable delegating? What can be most efficiently handled by third parties? What ought we handle ourselves?

This is the current phase of the project.

Business model

We had been discussing this idea for about a year by the time we had heard of Magic, but felt the service unusably subpar, and the business model unsustainable. We thought an entirely free service would lead to even lower quality and unacceptable compensation for employees.

So, from early on, even though it wasn’t our main concern, the business model was at the top of our minds. Our main considerations were sustainability and simplicity. We considered a few options:

Commission

Since the rapid growth enabled by totally free service was irrelevant to our goal of creating a few persistent clients, the closest thing we considered was charging a modest service fee on purchases. We experimented with different combinations of percentages and flat fees, but it never added up. Not only did a significant minority of requests involved no purchase (usually requests for research), but even a hefty service fee wouldn’t cover much more than minimum wage for the concierges. This wasn’t acceptable, and wouldn’t allow us to hire the best concierges. It would force us to optimize for speed at the cost of quality, and we observed that services that used this model persistently pushed clients to make purchases.

Service fee

A flat service fee on all requests was appealing for its simplicity, but suffered from a critical flaw: It presented a mental barrier to use of the product. Even if the client considered it worth the expense to have something taken care of on their behalf, having to make that assessment for every single request would’ve presented enough mental friction prohibit habit formation and the effortless we wanted.

Subscription

A subscription, despite presenting a high barrier to entry, accommodated our goals best. It encouraged frequent and habitual use, and allowed us to build a strong relationship with the client. And it suited our objective to maintain a handful of demanding clients. Of course, it also makes the product a very difficult sell, especially considering it’s hard to evaluate its value without first using in your own life.

Since our focus was on prototyping and evaluating the service, we never came to a decision on this. But it remained a frequent topic of discussion.

The Shadows

The Shadows
Spring 2015
Interaction design

Overview

With an issue like climate change, the actions of the individual have collective consequences. Enabling you to see how your lifestyle contributes to a global problem is critical to enabling you to minimize your impact.

The Shadows is a website to visualize and understand your impact on climate change — a virtual memorial that visualizes your contribution to a serious global crisis, and lets you explore the impact of cities, countries, and the whole species. By providing a simple and visually engaging way to breakdown the impact of your activities on the climate, the Shadows might represent the first step towards reducing your contribution to this problem.

There are many people who deny the science of climate change. This tool is not for them. It’s for the millions of people who have a basic grasp of the science and accept it, but don’t have a sense of how they, as an individual, are contributing.

Climate change is possibly the greatest crisis facing our species, so it can be difficult to connect your daily activities to their larger systemic consequences. It can be difficult to get a sense of the scale of the problem, and see who — be they individuals, cities, or nations — bears the most culpability. The Shadows is an attempt to remedy this.

Website

Project overview

Analysis

The Shadows is, at its simplest, a tool to visualize your carbon emissions to varying degrees of detail. This process must be very simple. Existing emissions calculation tools are very complicated, deterring all but the most determined. To mitigate this, the Shadows asks only a few questions, in conversational form, increasing the likelihood you will actually complete the flow, and that people you share it with will complete it, too.

After telling the Shadows a few things about yourself, you get a simple and familiar visualization of the causes or your emissions. This enables you to easily identify areas of improvement. For example, most people are unaware of the significant impact of air travel. The visualization lets you see this source of emission in comparison to others, like your commute. The visualization gives you a concrete sense of how your individual activities stack up against each other, and against other people’s.

Next, if you choose, you can add more details. Some people, for instance, have double-pane windows, which can significantly reduce your heating bill. Fill out this details by clicking on the shadows that represent your impact. By design, this is not a necessary step — even the most basic self-awareness of one’s impact is a tremendous improvement for most people, so specificity is not primary concern.

Weeks or months later, if anything changes in your life — e.g., if you move to a new city or replace your appliances with Energy Star-compliant ones — just return to the website and update your data.

Visualization

To give you a sense of your relationship to the larger problem of climate change, the Shadows visualizes your impact in the context of the impact of other people.

At a high level, the Shadows is a simple and engaging interactive visualization of humanity’s carbon emissions. If you zoom out to the highest level, you see a representation of the emissions across the whole planet. Click it to see how emissions are divided between continents. Click a continent to see how its emissions are split between its constituent nations. And so on, down to the level of individual cities and people.

This provides a sense of context for your impact and that of everyone else who has recorded their impact. The Shadows is presented in a visually contiguous space to give you an implicit sense of how your impact is connected to the bigger picture.

Above all, visual simplicity and uniformity communicate that we all share the same atmosphere. Emissions from anyone, anywhere affect everybody.

Sharing

As a website, sharing the Shadows is as easy as sharing any other link. The Shadows is meant to be a visually engaging and accessible experience. This ensures the Shadows is easy for people to discover and share. As a tool intended to increase comprehension and awareness for individuals informed about — but not engaged with — the issue of climate change, ease of access and visual novelty are critical.

After analyzing your impact, you are encouraged to share an image of the visualization on Facebook, Twitter, or with individual friends. This increases the potential reach of the system and expedites the process of filling out the map with individual contributions.

Memorial

These parts constitute a participatory virtual memorial, built one person at a time. The illustration of emissions from nations and cities gives the experience structure and you a sense of connection to a very large systemic problem. This ensures that the experience is engaging and informative, even without much input from the public.

Over time, however, individuals would fill out the map. Individually, this informs you about your impact and helps you make the connection between your activity and the global problem. Collectively, though, this becomes a powerful collective statement from people who care about this issue, imparting you with an unspoken connection to other participants, and a sense of collective responsibility.

Process

Various prototypes

Audience

The audience for this project are individuals concerned about climate change, but not engaged with the issue. Specifically, these are individuals who accept climate science and have some sense of the severity of the problem, but do not have a sense of how their activities contribute to it. Given polling data on climate science acceptance, these would tend to be people born in the past fifty years, more affluent than not, and politically liberal. Conveniently, these are also people more willing and able to make the lifestyle changes this tool would seek to enable.

If the goal of the project is to simply elevate the awareness of the issue amongst people who are already somewhat engaged with it, guerrilla marketing might form the basis of an engaging awareness campaign. I experimented with ways of altering common objects in public places to call to mind their impact on the climate.

This, however, offered less depth and reach than a digital campaign. Given the access my audience has to technology, and the potential to tell a new kind of narrative about this topic through data visualization, I decided to focus on a digital campaign oriented around data and the quantified self.

Origins

Initially, it seemed reasonable to adapt this project to the quantified self trend. This might manifest as an app that allows the user to track their activities and see the corresponding impact.

But there were some critical problems with this approach. Most importantly, the data needed to calculate an individual’s carbon footprint tends to change very little over time. The size of your house, the city you live in, and the amount you y or drive tend to change very infrequently, and so frequent tracking is of little bene t. People also lacked basic comprehension and interest to use such a tool; it was difficult to make something both desirable and informative. Given how much data would have to be collected, such a tool would likely take too much time out of their life. Moreover, phone sensors are not good enough to get useful metrics, if the user fails to input the data themselves.

Consequently, I shifted the focus from daily tracking and towards one-off comparison against others. This was a simpler concept that resonated more with people. This also enabled users to connect themselves with the big picture. The potential to compare with friends makes for a more engaging process.

I considered visualizing comparisons between countries and other geographic entities, as well. In this process, I worked through a few simple and playful ways of interacting with this data.

Visualizations

These experiments, however, were lacking in depth and comprehensiveness. There was no story or clear purpose to the system, and the experience was visually bland. And so I explored a few other kinds of visualization.

Bubble chart

This shows scale clearly and can accommodate different depths of detail in one UI (countries and people, for example). A bubble chart also gives a the interface a more distinctive look. It has the potential to be infinitely scalable, while still maintaining a sense of overall context.

Line graphs

These are good for showing change over time, but the system would not be collecting enough data to justify this visualization.

Concentric circles

This was visually distinctive and engaging, but it was too linear to support richer relationships between data. It does not facilitate the comparison of different levels of hierarchy, leaving the user with little sense of overall scale.

Block

This carried many of the benefits of the bubble chart, but requires perfect subdivision of nested nodes in the visualization. I.e., a visualization of Pittsburgh’s emissions would have to perfectly subdivide into those of each individual in Pittsburgh. Unfortunately, the data are too inconsistent to support this. This was also as visually pleasing a visualization.

Flow

Much of the process was focused on the structure of the visualization and interface. I iterated through a few different sequences for bringing users through the visualization. How and when do they enter data about themselves? How do the different visualizations fit in the context of each other?

Eventually, I realized that the visualization and the personal analysis tool could be combined. By treating the interface as a single contiguous space, users both analyze their own impact and explore that of other people, as well as that of cities, nations, and the planet as a whole. More importantly, this gives user a strong visual sense how their impact is contributing to the larger problem. This system is also visually and intellectually poetic in a way that the others were not.

Visuals & Identity

With an interface structure and flow in place, I shifted focus to the visual identity of the system. As the core of an awareness campaign, it is critical that the identity be distinctive and captivating, without detracting from the simplicity and utility of the website.

A single color and “material” for the bubbles is important because they reinforce the notion that there is only one atmosphere and, though we might have separate carbon footprints as individuals or organizations or states, all of those emissions end up in the same place. Varying color, texture, or some other visual variable detracted from this core concept, and made it more difficult for the user to get an implicit sense of how their impact is related to the larger issue.

It was difficult to find a visual embellishment of the bubbles that didn’t seem gimmicky, distracting, or too difficult to implement. Blurring is an effect that suggests depth, is easy to modify over time, and can be used to create hierarchy.

Implementation

Given the audience and the importance of shareability, it was clear early on that this should be a web experience. D3.js is very flexible and allows for very sophisticated interactive data visualization library, so that formed the basis of the interactive prototype of the interface. While the data proved too complex and (my optimization skills too lacking) to produce a sufficiently performant prototype of the experience, designing and experimenting through code led to some compelling visual and interactive outcomes, and to significant changes in the visual language.

Vestige

Lunar Gala: Vestige
Winter 2014/15
Motion
Web
Identity
Print

As a creative coordinator for Lunar Gala: Vestige, the 2015 iteration of Carnegie Mellon’s annual fashion show, I was responsible for producing a web site, several motion pieces, and digital graphics, as well as contributing to the development of an identity system and some print pieces. I worked with creative director Katherine Frazer, motion designers Angeline Chen and Danae Paparis, web designers Victor Song, Zai Aliyu, and Daniel Kim, and web developer Salem Hilal.

Concept

Vestige overstimulates viewers with consumerist culture imagery, instigating an information high and overloading the senses. There is no breathing room, type and image overtake the page to fully immerse the viewer, forcing them to consume more. Our imagery juxtaposes this new, shiny, consumable content with a literal vestige of computer manipulation: compression. The content becomes degraded, and viewers are left with a mere fragment of the image they original had, though the colors and experience of Vestige’s materials remain wholly stimulating. In short, Lunar Gala Vestige is a critique of the corrosive cycle of overconsumption in digital times.

— Katherine Frazer, Creative Director

Website

In many ways, the website laid much of the groundwork for the visuals across media like print and video. After being developed for the website, the technique of dynamically compressing type and image was adapted to print and motion design. View live.

Motion

Promo Videos

In-Show Videos

Opening for Act I

Opening for Act II

Closing video

Print

In-show Program

18x24, double-sided.

Collection Posters

Posters advertising individual collections presented at the show.

Typefaces

We created four typefaces for use in collateral for the show. The main challenge was to develop distinctive faces that captures the sense of digital degradation, without getting too close to a familiar 8-bit aesthetic. We designed these faces with the intent of dramatically stretching and scaling them.

Deliverables

Deliverables
Fall 2014
Space
Identity
Print

I collaborated fellow communication designers Zach Bergeron and Sam Murray to develop a visual identity for a showcase of the work of the Carnegie Mellon School of Design Class of 2015, hosted at the Miller Gallery in December 2014. In addition to the identity system, we produced a series of posters and digital imagery to promote the event, as well the signage and print pieces used in the space itself.

Identity system

We sought to capture the irreverence and individualism of the Class of 2015 through a conscious perversion of graphic design tropes — visual minimalism, grotesk typefaces, grid systems — and the student work itself, producing an illegible and emotive scramble of letterforms and pieces from the show.

An excerpt from the statement accompanying the introduction of the identity:

Our show, Deliverables, will represent our class as the individualists and free-thinkers that we are. The show’s title acknowledges the constraints of our discipline but visually challenges that notion. The collateral takes what the public expects and transforms it. It alters visual design tropes to incite curiosity and dialogue about what design can be. We proudly highlight our work and we acknowledge how we’ve grown. We use what we’ve learned about form, material and composition in our curriculum to construct a functional, conceptual, communicative, expressive, and most of all, thoughtful public image for our show.

Print

Posters

Series of large format posters displayed throughout Carnegie Mellon’s campus and the local community.

Brochure

Series of programs distributed at the show, with a poster on the front and index of all items in the show on the reverse.

Space

We extended system into the space itself with variety of signage and some very large vinyl graphics. The show itself reflected the identity through a focus on the pieces themselves — as opposed to the classes in which they were produced — and the eclecticism of layout.

Facebook

Facebook
Summer 2013
Product design

Over the course of a summer Product Design internship on the Facebook Pages team following my sophomore year, I designed new presentations of content and features to make Facebook Pages more engaging destinations. I had varying degrees of free reign in defining what these features might be, and worked with two engineers to implement a new presentation of page content.