Archive for the ‘Concepts’ Category

January 25 2012

Product Design Guild

by Hang

The Brief:

Designers learn best by working with other designers. However, modern team sizes mean that virtually all startups can only afford to hire a single designer and an entire generation of designers is emerging that has never had that experience. I wanted to create an organization that would increase the proficiency and productivity of designers by providing them with a chance to do the kind of collaborative design work one might find in a studio based environment.

The Problem:

From the start, I wanted the Product Design Guild to be an organization that great designers would want to participate in. Great designers, by their very nature, are busy people so, as well intentioned as they may be, lower priority commitments inevitably get bumped. I thought that the only reliable way to convince busy people to come was if coming would save them time over not coming. That is, spending an hour designing at the Product Design Guild would be more productive than spending an hour designing alone.

The Solution:

The Product Design Guild holds meetings once every two weeks in the Bay Area and once every month in New York. Each meeting lasts for 6 hours on a weekend with lunch and space provided by a different sponsor every week. Each meeting starts with introductions consisting of:

  • Your name
  • Your project
  • What you’re really good at
  • What you need help with

After the introductions and lunch, meetings are left deliberately unstructured and members self-organize in order to work most effectively.

Membership to the Product Design Guild is open to experienced designers only and I personally vet every single application for the Bay Area. During the meetings, we have three rules:

  • You need to bring work
  • Be intensely helpful
  • People are trusting you, don’t be a dick

From the beginning, the Product Design Guild was deliberately structured to set itself apart from other meetups in a number of distinctive ways, all towards the aim of being a more productive space than solo design:

  • Effective design collaboration requires understanding and trust. By pre-vetting our members, any designer can start working with any other designer and know that their suggestions come from a place of expertise and experience. This allows for groups to form and disband fluidly and rapidly.
  • Our rules set up an expectation of helpfulness and productivity that affects the conversational tone. Because one of the shared requirements is that everyone has to bring work, conversations are started around the project.
  • Each meeting is 6 hours long which allows for designers to fully explore the depth and nuance of a design problem. The timeframe naturally affords in depth exploration.
  • Setting each meeting at a different company allows designers to be exposed to multiple design cultures.
  • During each meeting, I am constantly figuring out who should meet who, trying to maximize the utility of having lots of smart designers being in the same room as you.

These deliberate design decisions have resulted in the steady, high quality growth of Guild membership and transformative experiences for those who attend.

My contribution:

  • I founded the Product Design Guild
  • I run the meetings for the San Francisco Chapter, including finding sponsors for every meeting
  • I am responsible for all marketing & promotion.
  • I lead the creation of the South Bay and New York chapters by finding appropriate local leaders, mentoring & communicating the values of the guild and providing assistance and guidance
  • I vet all memberships for the Bay Area
  • I moderate the private Facebook Group

More reading:

January 25 2012

Apture

by Hang

The Brief:

Apture was a contextual search startup (now acquired by Google) that allowed users to gain in page, rich media search results through text highlighting. At the time, Apture was just about to release Apture Hotspots and was seeking new strategic directions for its product. I was brought on to provide strategic thinking about potential new avenues for Apture to explore.

The Problem:

Although Apture had great reach, it had to strike a delicate balance between providing utility when needed while also not being annoying when not needed. This tension meant that the designed interaction was so unobtrusive that engagement was low. Apture Hotspots was one new way of bringing the Apture experience to a broader range of people. What were some other ways to balance these two competing needs?

One of the ideas that I explored was in how best to surface ambient behavioral information from people that you cared about. For example, if you were reading about Cleopatra, would it be useful to know a friend had also been researching Cleopatra a few months ago? When & how would this be useful? What would the privacy norms around this be and what would be the best way to present this to the user?

The Solution:

In order to gain insight into these questions, I built Ambient-Wiki, a prototype to be used by internal Apture employees only. Ambient Wiki used a browser plugin to log every Wikipedia page that any Apture employee visited and broadcast this only a shared, ambient display in the office. Simple annotation features were also provided and annotated entries would make an entry extremely prominent on the display.

It was decided that Wikipedia entries were innocuous enough that privacy was not a major concern but interesting enough that they provided an insight into co-workers curiosity.

Findings:

Over the 4 week period that AmbientWiki was running, we discovered that the threshold required to start a conversation was relatively high. However, people did enjoy the voyeuristic element and paid attention to what others were searching. AmbientWiki primarily sparked conversations when you saw someone else searching for something that you have knowledge of (rather than the other way around as we had thought). Unfortunately, it wasn’t possible to integrate these findings into any solid product direction.

My Contribution:

  • I conducted several user studies on Apture’s existing product
  • I created animated interaction mockups of new interactions for new bottom bar and close window behaviors
  • I coded the AmbientWiki internal app, including a Chrome Extension, a Ruby on Rails backend and a HTML+CSS+JS frontend.
January 25 2012

Peel

by Hang

The Brief:

Modern smartphones are capable of replacing a myriad of single purpose hardware devices, including the remote control. To date, most smartphone remote apps presented a rather literal translation of a remote control interface onto a screen. At Peel, we instead believed that this was an opportunity to fundamentally rethink what a remote could be and to fully exploit the power of an internet connected smartphone. In particular, a smartphone remote could serve as a gateway into a shared social television experience.

The Problem:

Existing social television products were largely uncreative concepts and I didn’t believe they captured the true power of a compelling social experience. I was tasked with figuring out what social experiences peel should build to serve as a key differentiator in the remote control marketplace.

The Solution:

I designed several potential social experiences for Peel:

Peel Overlay: Peel Overlay is like a mobile Quora for television. It allows real time, question asking and polling of other users watching the same show and also integrates with data sources like imdb and Wikipedia to allow it to automatically answer questions like “What other shows have I seen this actor in before?”.

Peel Groups:

Different people will watch the same show for different purposes. Peel Groups allows people with a similar purpose to find each other, organize and engage in a shared experience around a show. Sports fans can use groups to bet on whether their team will score this field goal, jeopardy watchers can compete to see who can answer correctly the fastest, watchers of cheesy sci-fi can make fun of the same show together. Groups allows television watchers to convert from a solitary experience into a shared social experience.

Peel Recommends:

Peel Recommends provides an elegant and lightweight way of notifying friends about a show they should be watching right now. It optimizes the sharing process by remembering who you’re most likely to share with and what mode of sharing they prefer and reduces the friction of sharing a recommendation down to just 2 clicks.

 

May 9 2010

Awesome Comments

by Hang
In 2008, I did some thinking on how to improve commenting on the web. While the product itself ended up failing, this was the genesis of some of my formative ideas on building social software as a holistic process.
April 23 2009

Friennuendo

by Hang

Summary:

Friennuendo is an attempt to add social nuance and avoid social awkwardness when sending a friend request to a newly made acquaintance.

The Inspiration:

In real life social interaction, friendship is not formed through an explicit request. Rather, it occurs over a gradual period of increased bonding. The implicit nature of friendship allows either party to deescalate from friendship while maintaining face for both parties. Because each friendship gesture has plausible deniability, mutual ignorance is maintained.

In social network sites, because friendship requests are explicit, the potential for social awkwardness exists. People fear sending a friend request and having it rejected due to a misinterpretation of the closeness of the relationship or receiving a friend request and then being forced to decide between explicitly rejecting or uncomfortable accepting the request.

Friennuendo is an experiment in whether some of the social nuance of real world friendship can be brought into the online world in a usable and effective manner.

The Concept:

Friennuendo allows for traditional unilateral requests but also introduces a concept of “mutual requests”. Mutual requests only trigger when both parties have made some move towards friendship and reveal no other information if this is not the case. This way, one person is able to send a mutual request and be secure in the knowledge that the other party will never discover this unless they also reciprocate interest.

The Design Space:

The first iteration of Friennuendo used the metaphor of a line and visibility. By default, both participants would start on the left side of the line and the person to be friended would be on the right side. Users can move in discrete steps across the line and if one user moves to within the visibility range of the other user, a friend request is sent. The first iteration of Friennuendo also included the idea of private areas in which only the owner could access. Private areas allow users to “hide” from unwanted friend requests by always remaining invisible.


First iteration of Friennuendo

The building of this first iteration of Friennuendo illustrated a number of design dimensions which affect the ultimate social semantics. Tweaks in these dimensions allow the system to express different social nuances:

  • Discrete vs Continuous: Movement can be either stepwise or continuous. A discrete model allows users to performed fine grained reasoning about “if I move 2 squares and they moves one then…” which would not be possible with a continuous model.
  • Number of steps: Altering the size of the strip affects the social nuance of what it means to move forward. At its simplest, requiring only a single move to be visible to the other person is mechanistically identical to the conventional “Add as friend” system. Adding more steps allows for expressing both a wider and different range of social nuances
  • Visibility range: Moving within the visibility range reveals your interest but does not mean that friendship is automatic of guaranteed. How close someone needs to get before they are visible also has deep implications on what types of messages can be expressed.
  • Private Areas: Private areas provided a buffer against overly aggressive seeking of friend requests and also allowed a user to “hide” by moving their avatar backwards so they could never be visible.
  • Unequal Visibility: In the initial design, me seeing you always implied that you can see me but it is also possible to create a model in which my visibility may be greater than yours.
  • Single step vs Multi step: The initial design was based on a draggable slider which allowed the user to move multiple steps at a time. This could potentially indicate to the user that, in order to become friends they could skip over the notches and just drag the slider across. Implementing forward and backward buttons suggest to the user that he or she should only take one step at a time without actually limiting the user in his or her actions.

Iterations:

I decided to explore the use of Friennuendo within an online speed dating platform. The results of some preliminary user testing indicated that the main difficulty with using the original implementation was that it did not suggest the right mental model to users. After going through several iterations, we created a prototype that had much better results in testing:


A jungle and grassland metaphor was helpful in conveying the idea of visibility but did not work thematically for our designs.

The first iteration of the new slider was conceived with jungles and grassland. Each user would have their own jungle, a portion of the playing field so thick with growth that the other user couldn’t look or step into it. This gave users a private safety area to retreat to. The area between the two jungles would be covered by grassland, with grass thick and high enough to obscure part of the playing field, but with enough visibility for the players to eventually find each other.

The Jungle and Grassland concept proved an excellent metaphor for the functionality of the sliders and the speed dating venue. However, visual representation wasn’t considered appropriate for a dating site, a sentiment echoed by peers and users.


Another iteration that didn’t quite do what we wanted.

Another design focused on a horseshoe shaped path on which the visibility issue would be solved by adjusting the line of sight as users moved around the curve of the path. Eventually this design was deemed too abstract and too complex to create as a low-fidelity prototype.


Final paper based prototype that we used for ad-hoc user testing

The eventual implementation preserved the isometric view from the jungle sketch but made it into a more neutral lawn. Private areas were abandoned in favor of letting users “escape” by moving off screen.


high fidelity model we used for formal user testing

This model was converted into a high fidelity mockup and eventually into a prototype:

A product pitch that we made to demonstrate how Friennuendo would work as a prototype.

Conclusion:

Friennuendo is potentially an interesting new form of social interaction which promises to allow for new ways of communication. However, for Friennuendo to be successful, it must be placed within the right context, possess the right mechanics to foster healthy rather than pathological social behavior and be presented in a way such that it’s intuitive and appealing.

April 20 2009

Friendbo

by Michael

Note: Friendbo is currently in the process of being commercialized by my colleague Michael Toomim and I no longer have any direct involvement in the product. Please direct inquiries to him.

Summary:

Many people have complex privacy needs which are poorly met by current social software design. People may want to show one facet of their identity to their boss and another to their friends and yet a third one to their family. Most social software currently asks you to explicitly manage your privacy by manually assigning people into discrete groups but this only poorly models how humans actually negotiate complex identity presentations. Friendbo is an attempt to build a more humane privacy interface by controlling access through the ability to answer personal questions.

For more details on Friendbo, see: http://www.friendbo.com/

April 20 2009

Fashionista

by Hang

Summary:

Fashionista is concept work I did in 2007 for a mobile social networking company in Australia on based on some observations on teen cell phone use. This work pre-dated the iPhone, twitter but still seems relevant.

The Inspiration:

In communities in which unlimited text messaging is common, it’s not atypical to see some users send between 100 to 200 text messages a day and certain heavy users regularly top 1000 text messages, an average of 1 message every minute. The majority of these messages are being sent to, at most, 5 or 6 of their closest friends. What is the content of these messages and how do we explain this behavior?

Peaks and Heartbeats:

If you were the draw a graph of the level of “excitement” that you experience over the course of a fortnight, it might look something like this:

Among the course of your life would be a series of peak experiences, experiences that are in some way out of the ordinary. So far, social networking sites have been primarily oriented towards the sharing of peak experiences but peak experiences does not explain the heavy texting patterns of teens. There simply aren’t enough peak experiences to fill up that amount of content. Underneath the peak experiences is what I call the heartbeat of your life. The heartbeat is the regular, periodic patterns that make up the bulk of your life. While this heartbeat is somewhat predictable and mundane, it also contains variation and what I call “texture”. Every day you might have lunch but you have something different each day. Every week you might go shopping but you buy different groceries on every trip. The texture of your heartbeat is information that is too mundane, even for Facebook. The texture of the heartbeat only makes sense when viewed in context: that I had a banana for lunch today is only interesting to those who know what I’ve had for lunch every other day of the week. As such, connecting and sharing your heartbeat is something that is done only between close and intimidate friends. It is this heartbeat that explains the communication patterns of teens. Each text message alone doesn’t convey much information but the aggregate of hundreds of messages over a day give teens a finely nuanced perspective unavailable through any other communication medium.

Exploiting the heartbeat:

Mobile social networks are uniquely positioned to capture this heartbeat data and take it to the next level. But for this to happen, they need to support the structure that puts such heartbeat data within a context. Fashionista is a tool for highly fashion aware women to show their friends what they’re wearing right now. Every morning, a fashionista user wakes up and decides what to wear, how to style her hair and how to accessorize herself. Once that’s complete, she takes a photo of herself in the mirror with fashionista and this image is automatically beamed to her close circle of friends. Over breakfast, she receives constant updates from what her friends are wearing that day as well as comments from her friends about how much they love the boots she’s wearing. Later, as she’s planning her social activities for the evening, she receives another pulse of notifications, keeping her in touch with what her friends will be wearing. Each notification conveys the subtle rhythms of the day. Not only what are you wearing but what time did you wake up? What does your facial expression tell me about your mood? Where are you going to be tonight and how do you feel about it?

Conclusion:

Mobile social software is still largely an unexplored space. We are currently in the phase of translating desktop style interaction onto the phone but very few truly native phone apps exist. One new ability that the phone opens up is this ability to share the heartbeat and Fashionista represents a class of apps that could have only been built on the phone.

Addendum:

Since 2007, the mobile landscape has changed significantly. The iPhone has redefined mobile software and twitter has gone mainstream and several highly innovative mobile applications have gained widespread success. Yet the few attempts at mobile social networking still try and replicate the desktop model of sharing. Twitter is probably the closest to hooking into the heartbeat but it’s still not there as it doesn’t have the appropriate privacy controls to segregate content meant for close friends from those meant for strangers. I’m excited about push coming to the iPhone as I think this will be the turning point for heartbeat apps. Heartbeat apps, by definition reside in the periphery rather than the center of attention. They need to be glanceable and the content needs to be absorbed effortlessly. The ideal solution would be for Apple to open an API to control the home screen but push, if implemented right would get it half of the way there.

Copyright ©2009 BumblebeeLabs — Theme designed by Michael Amini