12 Lessons Learned for Getting Better Results from Developers


12 Lessons Learned for Getting Better Results from Developers

Posted using ShareThis


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.

Affinity Diagrams


The 8-month MHCI Capstone project has started a little over 3 weeks ago and we are well into the research phase. The biggest portion of our research is Contextual Inquiries and before that all happens, its good to know who you plan to interview and what is it that you want to learn from the interviews. I’ve found affinity diagrams to work very well for this process.

The main purpose of affinity diagrams in Contextual Design is to organize a wide range of ideas that are produced from brainstorming, usually in a group of multiple people. All the ideas are written on post-its and put up on the wall and everyone can group the ideas as they want. This is usually a process including discussion so that everyone understands each other’s ideas and there is a level of consensus in the grouping. An important thing to remember is that groups of ideas should be small, usually not more than 4-5 items. Also, group descriptions or group names should be descriptive phrases, not vague, general words such as “task management”, “search”. This all helps people think carefully about how they group the items. The following images show an example of how many ideas slowly create groups and become organized.

Another aspect of affinity diagrams that I’ve found to be very valuable is that they help the participants to understand different perspectives, create a common understanding and naturally come to a consensus, even without making decisions or compromises. Everyone thinks they all have different ideas and that the ideas conflict, but as you actually describe and share your thoughts, everyone realizes that they aren’t actually so different.

This has actually been proved in both of the two Contextual Inquiry focus setting meetings that I’ve had until now. Before creating the affinity diagram, everyone has different ideas on what to focus on and what we want to achieve from the CIs. But once everyone writes out their thoughts on “What do you want to learn from the CIs?”, shares the ideas, learns others’ different perspectives and realizes all the things you haven’t thought of before, all the participants have a much better understanding of each other and naturally achieve a pretty good consensus of the CI focus. We’ve found this to be one of the most valuable and rewarding parts of the whole process.

Carnegie Mellon – HCI Masters program


For people interested in the CMU MHCI (Masters of HCI) program, most of the information you need can be found on the CMU HCII website. The site UI is not attractive and looks out-of-date (I wonder why a lot of the universities’ HCI websites look so bad… When I was searching for schools to apply to, it made me wonder if they really knew what they were doing.) but anyways, compared to other schools, finding information on the program and the requirements for applying was so much easier for CMU. For most other schools, you need to look into the HCI website for information on their research, then go to the school’s graduate admissions page for information on applying. Application requirements from the school were to be found on the graduate admissions page, HCI dept requirements on the HCI dept website and sometimes additional requirements for international students hidden somewhere else and collecting all the information was a pain. But for CMU, all the required info was well organized and they even had a final checklist to make sure you weren’t missing anything to send to the school (a user-centered design!). For other schools, I had to create a big Excel spreadsheet with all the different requirements. But I see that CMU has switched to online application this year and I’m not sure how well that was designed.

One of the biggest differences of the CMU MHCI program compared to other HCI masters programs, and also a thing you should consider very carefully if you are applying, is that it is a professional degree program. Not much research and no thesis. Lots of classes, lots of practice and group projects including a 7-month capstone project with a client and tons and tons of meetings. The program is targeted for students looking for jobs as HCI practitioners after the program. If you’re a research-type person who wants to invent the next-generation input device or if you’re planning on getting a PhD afterwards, this is probably not the right program for you. But if you’re planning on a career as a user experience designer, usability researcher or anything like that, the practice you get in the program will probably be invaluable.

While some students in the program have found some of the group work and practice to be repetitive and sometimes frustrating, others, usually students with previous work experience, often say that it is very useful. Simply knowing the methods and actually understanding how and when to use them is totally different. There are several different HCI methods, the methods and process used greatly varies depending on company and also by the nature of the project. So learning the pros and cons of each method, experiencing how the methods work or don’t work in different situations and trying to find ways to make them work is very important to actually be able to use the methods in the real-world.

Another thing the program emphasizes is learning to work as a group. User experience/HCI work is usually done as a group process and is also more difficult since people in the same group tend to have different backgrounds – computer science, engineering, design, psychology and many more. Therefore, group work is a main part of many courses in the program including the capstone project so that the students get sufficient training to work as a group. And working as a group, especially when it involves things like design where people have strong opinions, can be pretty tough and stressful. Towards the end of the first semester, I’ve had weeks with more than 10 meetings and I’ve spent more than 30 hours – just meeting with groups!

The CMU MHCI program admits about 30 students each year. There’s also a joint MHCI program between CMU and the University of Madeira in Portugal which was started two years ago. There are about 16 students in the Madeira program who study at CMU in Pittsburgh for the first semester and then move to Madeira to complete the rest of the program. So the labs are pretty crowded with nearly 50 students in the first semester, but gets better in the Spring semester. Then we have about 7 students in the accelerated masters program, who continue their studies from undergrad and complete the masters program with one additional semester. As for this year, of the 30 students who are in the CMU MHCI program, about half are U.S. students, 1/4 from India and the rest mostly from Korea, China, Taiwan and a couple from European countries. There’s a good mix of males and females with slightly more males this year. As for the undergrad major for students, I’m not sure of the exact number and this probably differs from year to year, but this year, there are slightly more students from computer science and psychology followed by design and a few others from engineering, liberal arts and other majors. The admission board tries to make a good balance between the majors since at least one person from CS, psychology and design is required for each project group for the capstone project.