Archive for the ‘design process’ Category

Design at Facebook


A good summary of the Facebook design team’s philosophy and approach to design. There are quite a few that I have learned through my experience and would definitely agree with.

1. Share early and share often. Sharing with the team and users helps make the design better.

There is no perfect design and getting feedback from others never hurts. Feedback often provides fresh perspectives, helps you realize things that you might have missed and makes your design stronger. Even if all the feedback is what you’ve already thought of and considered in your design, it at least proves that your doing your job.

2. Get your hands dirty. Designers need to know how to code.

I think the point here is that an interactive, working prototype always provides much more information than static mockups. Often visually appealing interfaces just don’t work when you actually try to interact with it. Also, testing the design in the context and with real content reveals so much more information and validates the design. If designers can code and develop interactive prototypes on their own, have the ability to plug the design in to test it with real content, the iterative design process is much faster and effective at improving the design earlier on.

As mentioned in the article, understanding the medium is also important for developing realistic, applicable designs. Designers tend to err on the side of simplicity. A lot of this can be solved by developing interactive prototypes, testing the design in context and with real content and by understanding the medium. From my MHCI capstone project, I learned this as many more design issues were revealed after the design phase while actually developing the prototype.

3. Don’t fall in love with your design.

Another good point. This is also why a lot of the design work shouldn’t be done individually as designers tend to become attached to their own work. Developing concepts, drawing storyboards on your own before meeting as a group has always caused problems in my experience. Developing on top of each others ideas and making it the group’s idea instead of just one person’s idea is a key in successful design work as a group. Smart designers should also be aware of this and be willing to accept others ideas and that their own is never perfect.


Focused Brainstorming


There are times when you want to do blue-sky brainstorming – forget about the constraints and come up with crazy ideas that might lead you to revolutionary software designs. But there are also times when you want to come up with creative, but realistic ideas that can actually be developed into a concrete design. Here are the steps that my project team took today which led to a very productive and fun brainstorming session.

1. Understand the needs and constraints – You need to understand what you’re brainstorming about. Understand what the users’ problems and needs are, and what constraints exist.

2. Come up with brainstorming seed questions -You might be able to brainstorm directly from the needs and constraints you’ve developed in the previous step if the problem isn’t too large. But the scope of our project is pretty big and it needed some processing to be digestible. We came up with what we called “design challenges” or “brainstorming seed questions”. Some examples could be “How can you make instant messaging notification easy to notice, but not annoying?”, “How can you track multiple instant messaging conversations?”

3. Brainstorm and visualize the ideas – ALWAYS DRAW! Coming up with an idea you can write down in a few words might take 10 seconds. Being able to draw even a rough sketch makes you flesh out the idea and think about important aspects of it. This could take 5-10 minutes or even more to do, but it’s the process of validating the idea and developing it to make sense. Also, brainstorming ideas can be pretty vague and a drawing is one of the best ways to get your idea across to the team. Another thing we did was to do some brainstorming on your own before coming to the brainstorming meeting. Doing some work ahead of time made it possible to go through many more ideas in the limited amount of time.

4. Build on top of other ideas – Don’t criticize other people’s ideas and don’t get attached to yours. Every idea that you toss out to the team is no longer yours. Try to build on top of others’ ideas. This is the typical brainstorming process, so I won’t elaborate too much on this part. One thing that went well today was to prevent the team from going too deep into each of the ideas. You want to get all the breadth out first before you dive deep.

5. Critically examine the ideas, refine and re-brainstorm – This is where you critically question each idea. Think of how this fits into an actual user scenario. Think of all the different ways the idea or feature has to work. This will help pull out details or constraints that you might not have thought of.  Refine ideas, further develop them. This might lead to new ideas that might solve the problem in a better way.

Another thing to remember: even brainstorming sessions, just like any other meeting, needs to have a well thought through process and a goal which the whole team understands. Otherwise, you can end up just going around and around throwing out ideas that aren’t really helpful. Brainstorming is a fuzzy process that is used in different ways and it’s important that the team understands what you want by the end of the day.