Category

Cheap Ideas

Cheap Ideas
Social Software Manifesto
03.16.08 | Permalink |

Some ideas of how to prioritize concerns while building social media properties.

Following Users over Directing Users
Community Ownership over Company Goals
Version 0.1 over Version 1.0
Responsive Team over Efficient Team

A reflection on how to work while developing products that are built upon user-generated content or social networks.

Following Users over Directing Users
Don’t tell users what to do. If you ever find yourself thinking, “Well, we want direct them towards , so let’s…” Remember that user’s will use the product however they’re going to use it. Follow them. Make their lives easier.

Community Ownership over Company Goals
I was once told that the myspace founders told Fox Interactive Media to f-off when they were told to put in a bunch of ads. If the community owns the site, the community will grow. Don’t kick off content because it doesn’t align with the companies immediate goals. Another way to put it is company goals follow community goals.

Version 0.1 over Version 1.0
Increment and iterate. It takes a long time to build a product that will be used. Get out fast and get feedback. Don’t hold back and wait for the product to be perfect.

Responsive Team over Efficient Team
Favor getting changes out quickly. Even for the sake of efficiency. Always keep the system in a state that can where new versions that can be launched quickly. If the team can’t launch anything but small patches because they’re slogging through a 6-month project, that’s a problem.

Agree? Disagree?
Cheap Ideas
Paper Prototyping
03.02.08 | Permalink | 9 Comments
Cheap Ideas, Innovation & You
Idea to Implementation
03.01.08 | Permalink |
I had the opportunity to be a guest lecturer at the National Institute of Design in Bangalore, India today. I taught a session titled ‘Idea to Implementation’.

My goal was to have the students conceive, build a prototype and test a product – in essence go through the entire product ideation lifecycle.

Here was the challenge: Invent and Build an Alarm Clock
- Brainstorm
- Create a Scenario
- Build Prototype
- Test Prototype
This was an experiment for me as well. I wanted to see if we could achieve all these things in such a short period of time. How fast can you get to a nonfunctional prototype?

Brainstorming:
I introduced the rules of brainstorming and the class split into teams to get to work.

I haven’t been satisfied with the post-brainstorming activities like multi-voting, so I asked them to do more explicit sorting with a technique called ‘funneling’.

When you pour a bucket of water into a funnel, what happens? You get a single stream of water. Funneling as applied to brainstorming is used to clarify ideas at various levels of abstraction. The levels we used were ‘users’, ‘needs’ and ‘features’. At the end of the brainstorming session each team had a prioritized list of users, their needs and the features that would serve those needs.

Who are our users:
One group came up with a lot of non-auditory methods of waking someone up. They were going back and forth between building an alarm clock for a deaf person or an elderly person who was hard of hearing. They made a decision to go for the elderly. When they started thinking about their needs in this context, it led to ‘remembering’ over ‘waking up’. As a result, the features were focused around creating a mechanism for reminders throughout the day. (If you’re retired, you don’t need an alarm to wake up and go to work!)

Create a Scenario:
I asked each team to tell a story about their alarm clock in action, because a list of features isn’t sufficient to understand how this product will be used. I didn’t really care how they did this (storyboard, written narrative, acted-out skit, video, etc). Each team decided to ‘act-out’ their alarm clock in the form of a skit and the results were hilarious. Afterwards the product ideas were opened up for critique. For example, one group used water as a startling mechanism and classmates challenged the practicality of that idea.

Prototyping & Testing:
Each team built a low-fidelity prototype of their product using ‘found’ materials in the design lab. Using objects like water bottles, tape, string and paper, each team constructed their prototype. To test their newly-invented product, members of another team poked and prodded the prototype to see if they could make sense of it.

The process for testing was simple. First the team came up with a list of tasks they would ask of the user, then each member of the team picked a role to play during the usability testing. There was one person would be the ‘guide’ to set the stage, ask the user to perform tasks with their device and ask questions to understand what the user was thinking. Another person played the role of note taker. A third person manipulated the non-functioning prototype to make it come alive.

Thoughts:
From an Agile / UX / UCD perspective, I was impressed that each team was able to go from idea to prototype in such a short period of time. It makes me wonder if we shouldn’t be creating more prototypes. Teams could utilize lower-cost methods of documentation: skits vs storyboards, paper prototypes vs ‘clickable’ prototypes. Rather than doing a high-quality job with fewer ideas, what if a cross-functional team could churn out many low-quality prototype concepts? Would that shallow effort yield more knowledge than a deep-focus in one area?

Special thanks to Mamata Rao, a faculty member at the National Institute of Design for the opportunity to work with her students. What a fantastic group!

I designed a class borrowing ideas from other folks at Yahoo like Todd Hausmann, Gale Curtis, Matt Fukuda and Dan Wascovich, Kevin Cheng, Anand Nair and Anupama Kamath. I also incorporated techniques like prototype testing from Marty Cagan, and paper prototyping from Jeff Patton.