Facebook Should Use Feedback Loops During Development

March 23, 2009

Many facebook users are unhappy with the new interface that launched recently.  A poll of facebook users showed 94% of users do not like the changes.   Just search for “facebook interface” on the site and you will see what people are talking about.   Finally, we can all see the benefit of online software with the possibility of immediate feedback!

How do you end up making changes to a site that so many of your users don’t like?  This question is hard to answer without more insight into the organization.  One way to reduce the chance of producing unwanted changes is to create healthy feedback loops during development.  Users love to give feedback if you provide the opportunity as we can see through the numerous responses to the new interface.

How to gather feedback

Here are some ways developers can gather feedback on their ideas and proposed changes.  I must say up front that I am not connected to facebook and have no idea if any of these processes were used:

Do usability testing – Usability testing is simple and effective.  Put your new site in a protected location online that users with permission can see.  Ask your approved users to do a series of actions on the new site.  Most importantly, ask them to speak their reactions out loud even if the reaction is negative.   You will hear and see first hand what changes you are making are good and what changes are perhaps not so good.  Here’s an online service to do usability testing that some of our clients have used.

Use focus groups – Find users who live within driving distance of corporate HQ, bring them in for pizza and project the new interface on the wall.  Start asking questions.  Take a lot of notes.  Repeat.  There is actually a methodology around focus groups, but an unstructured approach can also be very effective.

Prototype – Long before you code anything, create simple graphic mockups and email them to prominent users, bloggers (provided they are willing to hold their posts until launch), family members and employees.  Ask participants to email you their reactions along with any suggestions they might have.

Have a REAL beta! – Create a group of a thousand or so users who are willing to actively participate in a beta.  By “real” beta, I don’t mean putting out incomplete software for all users to play around on (gmail, your beta period is over!).  Let your beta users directly access the new site for a few weeks so they can get a feel for the workflows and functionality.  Provide a simple form for them to email you feedback.  Make sure you find users willing to try new features who will make the effort to email their comments to the team.

After reading about these various processes for gathering feedback, do you think that the developers at facebook might have been able to determine that users might have issues with the new interface?

If you want to avoid making similar mistakes, make sure that gathering and responding to feedback is an integral part of your development process.  Leave time in the schedule to make product changes.  One of the top reasons feedback loops fail is development teams don’t have time to address highlighted issues.

Let’s talk brass tacks

One of the top complaints about the new interface is that users are confused and often have to hunt around to find areas that should be easier to locate.  Some basic user interface elements might improve usability and decrease this confusion.  I have listed a few ideas below.  After all,  what good is pointing out issues if you are not going to offer solutions:

- Provide a consistent site wide bread crumb trail to help users see exactly where they are.   For example, how about showing something like Home > Photos > Albums > Napa Fall 2008 > Photo 2 of 18  on the page?  With a bread crumb trial , users can see exactly where they are and how to navigate back.  Some areas on facebook have a bread crumb trail and some don’t.  To be effective, this needs to be consistent and present everywhere.

- Provide site wide navigation that is always available.  Would it be so bad to have a menu bar or left side navigation or some other common control to access the entire site?

- Use labels and hints to help users understand what they are looking at.  For example, take the word “Highlights” on the home page.  How about a little helper text like popular updates from friends or something like that?  Labels with hints set the context for users and help reduce confusion.  I suggest reading Don’t Make Me Think by Steve Krug.  I had my own don’t make me think moment a few months back.

A real example – Events

Let me provide an example of what I am talking about using the Events feature.

I see more and more people putting birthdays into facebook.  Current birthdays shows up in the upper right corner of the home page.  I’ve never used the Events feature before and had thought these were just notifications.

On the current site, you have to click twice in that corner to get to Events.  That seems to be the only way to get there as Events don’t seem to belong anywhere.  I don’t see them in the menus or as links in other places.  These next changes would help users navigate Events, which would hopefully increase site usage as well as improve user satisfaction:

1) Put the label Events on the home page above the daily events.  This tells me this is an actual area of the product.  Heck, go crazy, even put small hint text like where you see birthdays or create your own events.

2) Provide general navigation to get to the Events area.  If you put them under your Profile, which may or may not be the best place, then have a sub-navigation under Profiles that lists Events and the other sub-areas that are part of Profiles.   This needs to always be available to users through the primary navigation I suggest above.

3) Show Home > Profile > Events when users go to the main Events page.

These changes reinforce Events is a feature and that it is located under Profiles.  Overall, users won’t feel as lost when they come to understand the layout of the site.

With a little bit of development process to support integrated user feedback, developers can determine the changes users want to see, which should in turn lead to a happier and more productive user base.


Collaboration Tips for Near Shore Development

March 11, 2009

Near shore development has a major advantage over outsourcing to locations around the globe for US companies.  The advantage is that all parties work in relatively the same time zone.  Teams collaborate more frequently because everyone works the same hours as opposed to being hindered by 24 hour communication delays.

GlobeLet me illustrate the point more clearly with a simple picture.  Look at the globe to your left.  You see North America where  Open Mountain is located and you see Latin America where our near shore partner Avantica is located in Costa Rica.  Now let me ask you, what countries are NOT visible? When it comes to real-time collaboration, countries that see the sun at the same time are at work at the same time, which means that issues can be discussed when they need to be and without delay.

In my posts about my experiences working with Avantica, I talk about collaboration a lot, but I don’t really define where it helps.  Nor do I provide any guidance on what we do based on years of near shore development experience.  Here are a few areas where we collaborate along with tips for enhancing the experience:

Product definition

The first step in the software process is to define what we’re building.  Product owners define requirements.  Interface designers provide graphics and work flows.  Everyone works together on user stories and functional specifications.  Our experience is that it helps to push the various parties to think through as much of the details as possible before we  start coding.  This ensures the engineers are working on valuable functionality and reduces the risk of re-work or of missing important aspects of a feature.

We find the best way to collaboratively manage product definition is through online document tools such as Google docs or Zoho.  Everyone references the same user stories, which is important for keeping everyone aligned.  The team avoids issues that come from developers reading an earlier version of a specification they saved on their desktop.  When we review documents in meetings, we see changes being made real-time and that validates we all have the same understanding of the decisions.

Tip: Use Google sites or some other online Wiki tool to collect information in addition to online document tools.  Some documents will come from designers using desktop tools like PhotoShop and FireWorks.  You will need a central location to store all your product documentation and an online Wiki serves as a functional central repository.  For the documents that are created online, you can embed a link to those in the Wiki.

Tip: If you are the project manager or SCRUM master, you should periodically save important information locally.  Online documents are easily changed by others and not all providers support tracking changes.

Project Management

Managers must know what each team member is working on and how long that work is taking to see how well the team is tracking to schedule or the burn down.  Tracking is harder to do when everyone is not working in the same building.  Project management software such as Rally Software or Version One enable teams to collaboratively track progress in a central location that everyone sees.  These tools support Agile processes well and enable all team members to contribute status updates in an organized fashion.  Basecamp and Zoho offer good general tools for project management as well.  Our teams find that making updates part of the process keeps everyone well informed  and allows management to see what areas need attention.

Tip: Track bugs in the same tool you use to manage projects.  In the beginning of a development cycle, features drive the work.  But at the end of a cycle, it’s all about bug management.  Using the same tool for both gives you oversight for the entire life of the project and also encourages developers to communicate bugs during development using a familiar process.

Team SCRUM

Our development teams tend to meet 3 times a week.  True Agile development zealots will tell you that you should meet every day if only for 15 minutes.  Either way, nothing beats regular discussion for managing a project.  Near shore makes this more possible. Far shore teams tend to limit meetings to once a week, which then turns the meeting into a status report, or they meet more regularly by extending the working day for the US team members.  We recommend meeting with Skype at least 3 times a week to allow the team to ask questions and reveal what they are working on.  In fact, if you achieve this, you will find all your other collaborative efforts are enhanced and supported by these regular discussions.

Tip: Use a low cost screen sharing product such as Acrobat ConnectNow or GoToMeeting to encourage code walk-throughs and interface reviews.  Start the Web conference each meeting so that if an engineer has an inkling to share, he can do it right then and there.  Imagine that, working with an outsource team and yet still talking to the engineers on a regular basis and still having the opportunity to review code.

Leads Meetings

Discussions with the team lead remind me of those back room discussions from political arenas.  You know, the meetings where all the real decisions are made.  That’s not really the case with software development, but often critical issues can be effectively resolved with a quick meeting of the key minds.  Some managers set up a regular time each week for this.  If that works for you, great.  We save leads discussions for escalation.  Leaving them off the schedule means they happen only when they need to and that makes sense since issues should in general be discussed openly with the entire team.

Tip: Use video with lead discussions to enhance communication.  Facial expressions and visual cues are extremely helpful when reviewing difficult issues.  Plus, when your lead delivers a snarky response, it helps to see if he is genuinely not happy or just yanking your chain.  Believe me, both happen although some leads aren’t as funny as they think they are (sorry guys).  Skype with video on a MacBook is awesome for this.   There is no setup and starting the video is as simple as clicking an icon.  Below is a chat from just this morning where we reviewed a few last minute changes to our release.

Video tip: When you speak, look at the green dot on your computer and not at the video of your lead.  This is like looking at the camera, and not the monitor, when you are on TV.

collab

Thanks Christian (guy in the larger image) for letting me (guy in the baseball cap) post your picture!


Near Shore Development Enhanced by Travel to Exotic Lands

March 6, 2009

We recently returned from another trip to visit our development partner Avantica Technologies in San Jose, Costa Rica. The trip was fantastic as was meeting with our teams to discuss what went well, what they liked about the products they worked on and what could be improved.

The picture below shows our CTO Tom Johnson meeting with the Avantica team that we have working with us on the solution for our client Brightstorm. I actually know all these engineers from a previous project, my last role as a company VP, and specifically requested them to work with Open Mountain.

blog-team-photo

We tell all of our clients they should plan at least one visit because meeting directly with the team enhances the understanding of the work and leads to a better unified solution. Ironically, clients take that part almost for granted and often ask us about the country and what we have seen. So far we have enjoyed the active volcano at Arenal, the wildlife of the Monteverde reserve and the warm beaches of Tamarindo (pictured below) among other places. But there is still more of the country we would like to see.

blog-photo-beach

I have to admit that I didn’t start down this path of near shore development to see an exotic land. I just happened to have a long time friendship and rewarding working relationship with someone from Costa Rica. Mario Chaves, Avantica’s CEO, and I worked together at many different companies and even went to the same college although we graduated different years.

The first time I worked with engineers from Avantica was at a small startup in the advertising space about 10 years ago. The lead was an engineer named Henry who is currently the Director of Development at Avantica. Henry is as smart as they come. I went to San Jose once to meet with him and the team. We spent the entire day collaborating on different aspects of the product.

I knew then that Henry and the team were up to speed on the latest technologies and as capable as teams I had worked with in the US. I could describe a problem and know by their questions and solutions that they understood the essence of the problem. That to me is the difference between true collaborative development and remote outsourcing. I want my team to have a stake in the product, to understand what problem we are solving, because that will drive the best result.

This last trip, as always, I stopped in to see my friend Henry. He was playing with a new Google Android phone and we caught up a bit. Henry is in the picture below along with some of the others we have worked with at Avantica.

blog-company-photo

Had I not had that first positive experience, I might not have centered Open Mountain around near shore development. I had high expectations based on my experiences as a US developer. Software developers work fast. We like to throw our ideas and brain storm. Some of the best product ideas come from engineers discussing a problem and shooting off on a tangent. This type of collaboration happened on my first trip to Costa Rica and has become a repeatable experience throughout the years working with the teams of Avantica.

I go back again and again to the country for the purpose of direct team interactions. But I’d be lying if I didn’t say that I also go to see one of the most beautiful countries in the world. After all, who would you rather be? The person reading this blog or someone in the photo below? How about both? Cheers!

blog-photo-sunset

Click the photo so see more pictures from our trip!