tom haynes interaction designer

(Scroll to the bottom for the experience prototype.)

The theme for the IxDA's Interaction '11 student competition centered around the idea of collaborative consumption:

This year's focus is based on the concept of “Use, not own.” Great interactions can connect people to create opportunities for experiences that outweigh the “joy” of ownership. How can we reduce our environmental footprint by sharing products or services?

Jane and I were selected as finalists for the competition based on our submission video that explained our thoughts about a sharing system for apartment buildings (some process shots for that).

When we got to the conference we were asked to explore this idea further and create an experience prototype that we would present the entire conference in a 3-minute presentation.

Problems and new ideas

We knew there were problems with our original idea, and we spent a few hours listing and discussing them. How convenient would this actually be? How do people learn that it exists? How do people learn the social norms behind it? How is it adopted in a building? What happens when someone steals or damages something?

At the same time we also wrote down a number of new ideas. Could we use RFID to track the location of objects? What about letting people use their smartphones to scan QR codes on things? How could we implement game mechanics? What if people posted stories of how they used objects, as a way of building community around this system? What about using paper or stickers as an indication of where things were? Should people be able to collaboratively “request” things that aren't in the building, and then pool their money to buy them?

User research

In order to answer some of these questions and determine the feasibility of our idea, we needed to ground ourselves with some user research. So we took an afternoon to talk to people at the conference, asking them if they knew their neighbors, if they wanted to, if they ever shared things with them, and what they thought of our idea.

We learned that many people in apartment buildings don't know their neighbors even though they want to. People also said that they wouldn't feel comfortable sharing things with people they didn't know, although simple face-to-face meeting would be enough to get past the “total strangers” stage. After that, sharing wouldn't be too big of a step.

Pivoting

Based on these discussions, we pivoted our idea from “sharing can create social connections between neighbors” to “social connections enable sharing between neighbors.” Our focus was now to get people to meet their neighbors so then we could nudge them in the direction of borrowing things instead of buying everything new.

This new direction helped us generate the idea of a lightweight, online building directory. In its simplest form, the directory is an opt-in system that lets people put their names and preferred contact information on a website that is only available to people that live in the building. The site then gently urges people to list what they might be willing to share with their neighbors.

The directory also lets people print out posters to hang around the building, because we realized that we needed physical artifacts to get new people on the system, and also to remain backwards-compatible with the current way that people communicate with their neighbors.

Our name for this system is Know Your Neighbors.

Experience prototype

Here are the experience prototype slides that we presented at the conference. The story is visual so that people can experience what it would be like to use the system. We used photography to place the idea in the real world, and used paper sketches so that people focus on the experience instead of the graphic & web design.

Thanks

It was great to work closely with Liz Danzico and Andy Polaine on this idea. Getting regular feedback from them helped us iterate quickly and stay inspired.

Firefox released data from Test Pilot — their framework for collecting Firefox usage data from users that opt-in and install it — and asked people to visualize it. The data is represents one week of Firefox usage for ~270,000 people, and ~4,000 of them also filled out a survey with basic demographic information. I was interested in what usage looked like over time and by age group, so I pulled out Python, sqlite, and R for exploration and used Illustrator to clean it up.

Click to see it full-size and read my annotations:

I lived in Providence, RI during the summer of 2010 and co-founded a company called DataBraid. DataBraid’s goal is to make science simpler by making scientific data analysis simpler and more accessible to those without programming knowledge. Our goal was to take advantage of the cloud's accessibility, ubiquity, and processing power to improve researchers' experience of turning their data into meaningful results.

The story

The idea started in November of 2009 as an analogy: X is to statistical software (like STATA, SPSS, and Minitab) as Google Docs is to word processing software (like Microsoft Word). We saw people's frustration using complicated software that required programming experience or strange command sequences and didn't support the level of collaboration they needed. So we talked to professors and asked them about their data analysis and collaboration habits.

We found that many professors do need more collaboration support and have trouble with the syntax and programming requirements of current stats software. However, what they were really looking for is an application to use for teaching statistics that didn't necessitate also teaching a programming language. So we set out to support that from the start.

Our process

We tried to work collaboratively and iterate quickly. Our most successful interactions were those where we would quickly mock things up and make sure we were all on the same page before moving to HTML and CSS.

One example of this was a sharing dialog which was used to view or change the people on the project. The dialog had to support listing both viewers and editors (users with read-only or read-write privileges), adding new viewers/editors, and removing peoples' view/edit privileges. I whipped up a quick wireframe that attempted to treat viewers and editors as "Collaborators" and automatically save everything, removing the need for save and cancel buttons.

The feedback I got was that combining the two groups was confusing and made it hard to quickly scan to see the list of editors and viewers. Splitting them up replicates the "Invite" line but makes the separation between the user groups more explicit. We also decided that the auto-saving wasn't expected behavior so I changed it to more traditional "save" and "cancel" actions.

This was clearly an improvement, although the word "Add" was preferred to "Invite" because users don't have to accept an invitation; the project just shows up in their list of projects. We also decided to put collaborators first because we want BraidLab to be a collaborative site with many people working on the same projects. Lastly, the dialog needed a header so it was clear what this was.

This is the current iteration of the dialog. Typing an email address and clicking "Add" (or hitting enter) adds the person to the appropriate list. Clicking the "x" removes them from the list.

Some things I would change in a next version would be:

• better labeled (and better looking) buttons to remove people from lists
• a more clear indication of what this was changing (changing the header to Manage sharing for "Project name" for example)
• a more helpful "blank slate" state for first-time users of the dialog

Conclusion

I left DataBraid to come back to school after a successful summer of designing and coding a full Ruby on Rails application that paired with an extendable statistics backend than ran R code. I was exposed to everything from project management to icon design and learned a lot from the experience.

KidMall is a class project that started with the idea that empty storefronts in malls could be filled by giving children the opportunity to sell their handmade crafts. This could bring their friends and relatives to other stores in the mall, and thus be beneficial to both malls and child crafters. Throughout the semester I worked in a group of two to perform interviews, think about the business's information architecture, create wireframes of the main features, and compile a strategy report and presentation for the proposed company.

User research

We asked parents if they would be interested in something like KidMall and we found that some would be, but that there were certain things we could do to make their participation more likely. We created a table of observations and the architecture and features they inspired:

Site map

Before working on individual screens and features, we mapped out the entire site and made this architecture blueprint. We wanted a very simple structure and to eventually reflect this simplicity in the site's design.

Scheduling

We started by sketching out ideas for the parts of the site that would be new and different from existing sites. It was important for the scheduling page to be clear and easy to use. Scheduling started with this idea for a calendar that would then show open time slots after a particular day was clicked on.

We realized that people also had to choose the mall they wanted to schedule a time at, so we made a three-pane interface to support this. People would first select a location, then a date, and finally a time. This would all happen interactively on one page to make the process fast and easy.

Finally, we needed to integrate our Groups feature, where children could sign up with preexisting groups like art classes or scouting troupes. To simplify things, we put this on the same level as the different malls, so parents either choose a mall or a group and proceed from there. Here is the final wireframe, showing a state where the user has selected a location and date and is currently picking a time:

User page

Printing wireframe drafts and working together to make changes was a successful way of working together. Here we realized that we needed a way of adding new items to the gallery and that we needed to integrate the Groups feature into this page.

The user page also shows a feature driven by our original user research; we learned that most kids are too young to manage their own accounts, and that parents are worried about the time it would take to update multiple children's accounts. So we added a dropdown to the top of the user page for fast switching between accounts.

Strategy report

Download the strategy report (PDF).

Final presentation

I made this interaction map during a usability evaluation of DTE Energy's customer backend. The grey lists are subnavigations in the different sections (My Account, Billing/Payment, and Save Energy), so this shows how many different options there are for users. It also shows that some pages (like MyEnergy Analyzer) are linked from different items in different navigations, which makes it unclear what sections those pages are in. Lastly, Payment History is a dynamic page that lists the user's payment history, but it isn't linked to from the My Account navigation.

The fact that the interaction map can be confusing and hard to read is some evidence that the site could be better structured to have a clear outline and information hierarchy.

The Fall 2009 University Mozilla Design Challenge asked the following question about web browsing history:

How can we make sense of this rich source of data and how do we best present this data to the user?

My ideas

Seeing your browsing history can be helpful for a number of reasons, but one common motivation is needing to find something you visited in the past but without information to simply search for it. Perhaps you only remember that you clicked a link from Amazon.com, or that it was yesterday morning between checking your email and doing research at work. These are the situations in which Timeline could be helpful. Currently web history is displayed as a one-dimensional list that doesn't represent the highly parallel ways that people browse the web: opening documents in new tabs and windows.

So instead of display history as a simple list, Timeline includes additional contextual information to help people re-find the pages they were looking for. This information includes:

• the time of day visited
• the duration of the visit
• the browsing path to each page
• whether pages were opened in a new tab or a new window
• whether the page was bookmarked
• the “active browsing track,” or what pages were in focus and which were in the background at any specific point in time

Process

Timeline started with this sketch at a design jam:

That soon turned into a more refined prototype that shows a user searching for "firefox," clicking links for Mozilla and CNN in new tabs, and then clicking the Wikipedia link in the same tab. Eventually they closed the other tabs and kept Wikipedia open in the background while they opened a new windows with zappos.com, performed a search, and opened 4 sandal pages in new tabs. The heart shows that they bookmarked one pair of sandals. The solid line represents the page that the user was looking at, while dashed lines are pages in the background.

My hope is that common browsing patterns (like using search engines, opening many tabs, reading long pages, bookmarking things for later, closing the browser entirely) can be easily seen and serve as landmarks for "lost" pages.

I also made a demo video in which I explain more about Timeline:

I know that this will eventually need controls for changing the time interval shown. It will also need to be optimized for displaying different amounts of information (ten minutes vs. a whole day). A search or filter interface will also be helpful to quickly highlight pages matching a certain term.

The UM ultimate frisbee team was having a hard time keeping track of member finances in a transparent way. The treasurer collected receipts after each tournament and kept a spreadsheet of what the tournament would cost each player after being spread out across everyone that went to the tournament. He would update the spreadsheet and email it out but it was quickly out-of-date and players often didn't know how much they owed the team. Also, the spreadsheet became hard to read because the data was spread across multiple sheets and had complicated formulas.

My solution

To make this process better, I wrote a web application that has a page for each player with their balance at the top. Players can check at any point to see how much they owe, and the treasurer can update the site when he gets receipts or checks from players. The app automatically calculates balances based on how many receipts were submitted for each tournament and how many people went.

The site also makes it easy to see each tournament's per-player cost, and also shows the cost broken down by what the money was spent on. This provides some insight into why certain tournaments are more expensive than others, and can help the team keep costs down.

Technical notes

The site was built with the Django web framework. The pie charts are made with Google's Charts API. The ultimate team is still happily using the application.

I created this visualization of my personal email habits so that I could see if there were ways to more efficiently check my email. The visualization uses small-multiples graphs that also serve as timelines for an entire week, or as a calendar view for the entire time period.

Process

I collected email data by modifying the mail-trends package to make a CSV file of all my sent and received email. I also ran some scripts on my web browser history to make a CSV of all visits to Gmail. I loaded it into excel and made some preliminary graphs to see if there were patterns in the data.

Then I moved to Protovis and added toggles for received mail and email checks. I also added a control to change the bin size because different bin sizes show different trends in the data.

Conclusions

I learned that it's generally OK not to check email as much on the weekends because I get a lot less of it. There are also instances of what looks like sent mail "turning into" received mail in a few hours. Lastly, I do a good job of taking breaks from email completely, which I'm fairly proud of.

If I were to go further with this, I would break up email by type and see which are important and which are things like mailing lists, advertisements, and spam. It would also be interesting to see more explicit relationships between sent mail and received mail. How do threads develop? What is my response time like in relation to other peoples'?

As an officer for SOCHI (UM's Student Organization for Human-Computer Interaction), I've helped organize and run events for HCI students at Michigan.

SOCHI has hosted design jams with companies like Yahoo!, Mozilla, Intel, and Ford. We also organized practice design interviews and arranged a "Day in the Life of an Interaction Designer" with designers from JSTOR.

Linder cooperative

Shirt design for Linder. Printed!

Icons

The icon set used in BraidLab.

Logo

Proposed logo for the Ecumenical Center and International Residence. See the style guide for more variations and example usages.

Business card

Movie poster

Can you name all the movies? Click for full-size.