Posts Tagged Teamwork

Helping Remote Teams Visualize User Data

EarthHow do you communicate user data with teams that are not co-located?  This can be a common problem with larger companies. If you’re able to, you can travel to their location and run usability interviews with them as guests. If you’re lucky, you’ll have a team that will actually read your notes from individual interviews (yes, I have actually had teams read notes from EVERY participant – amazing! While this can mean a lot of time typing, it works well with some people. Just make sure they read more than one participant, so they do focus too much on one person’s needs/issues.).

I attended a UPA conference a few years ago. One of the more memorable presentations  (Usability Analysis Visualization to Improve Communication and Build Trust by Rally Pagulayan, Oracle) included a method of sharing data with teams: affinity diagrams. The method was labor intensive, but effective. Each piece of data was put on an individual post it note. Then, the notes were organized hierarchically on a wall in their lab. Any duplicate data grew into larger stacks. When other team members would come into the lab to see how the sessions were going, they could immediately see all of the important points. Also, for those team members that normally ignored feedback from the usability team (yes, you know they’re out there!), they were able to see all the data and had less inclination to argue.

I thought this method was interesting, but I tended to work with remote teams at the time. So, I came up with a similar method. Instead of using post it notes, I created PowerPoint and Visio presentations. Each page contained a grouping of data. The first page would contain information about the user group (age, computer experience, occupation, location, etc.). Other pages would cover a theme of user data (e.g. a specific portion of the website or task completed). Then, I would organize the data hierarchically. I wanted to convey the large amount of user data for certain points and make sure interesting, if not regularly brought up, data was easily found. I also wanted to put down some thoughts I had while looking at the data and watching sessions. A piece of sample data can be seen here:

 Affinity

I used a few visual differentiators:

  • Thick borders are used to point out repetitive data.
  • Dotted lines are used for comments from the UX tester.
  • Red borders are used for issues on the site, again using the thickness to illustrate highly repetitive issues. Other methods of differentiation may be needed if you work with someone who is color blind.
  • Participant numbers for each comment is listed to follow specific user needs. If one of the users was a manager and all other users are worker-bees, their approach to the website can be very different. Being able to track comments from both user types can be useful.

While I know this method requires a lot of work, it can be really useful for a couple situations. First of all, if you are new to a team and the team is unsure where you get your suggestions/designs from, creating these documents will help them see the huge quantity of data obtained via user sessions. They can also easily see where the repetitive data is. The data can be used for talking points to explain the design. After a while, hopefully you can earn the trust of the team and will no longer need to use these diagrams. Another time the diagrams can be handy is when you have an issue that is a “hot topic” for various members of the team. You can create a mini diagram for the area of interest. Seeing user data that is specific to the issue can help with discussions, although there are always people who will not change their minds, even with the data!

Leave a Comment

Balancing User Needs… aka Bartering

Bartering

In a perfect world, user needs would rule and the usability engineer can change any detail on the interface and add/remove any feature based on user interview data….. but the real world doesn’t work that way.  In reality, there are deadlines to meet and a lot of people who have a say in the final output. The development team has its own beliefs about what should go into the product and how it should be designed.  Additionally, they have to worry about the feasibility of building the actual product. The product team also has their beliefs and a vision that may go beyond what the users are currently thinking. The sales team wants something that will demo well. Even if the “demo-able” features are not always useful in the real world. So, how do we deal with this?

I try to really think about each of the features. I always ask for the entire list of changes/features that the user data points me to; however, sometimes I have to be willing to barter. Learning what to barter is where the art comes in. Any good usability engineer will rank or prioritize everything they feel should go into the design. Based on this prioritization, you can design what HAS to go into the site and what can be dropped. I try to ask myself the following questions:

  1. Is this something the user actually NEEDS or does the user just WANT it? If its a need, how many users need it? Is it something everyone needs? Then it should be high on the priority list. If you are told it is not possible to build, talk to the team and find out how much of the feature can be implemented. See if it can be completed over the next couple of releases, but try to get it in. If its a want, you can haggle. Let the team know you can push this feature off, if you get some more NEEDS in. 
  2. Will it hurt the users interaction with the site if its added/removed? This is not a feature that should be bartered with. If removing an old feature or adding a new one will actually cause difficulties for the user, it should not be done. If it is something that’s required for a sale, see if you can put it in the least harmful location.
  3. Is this a feature/design element that YOU want (as the designer) or does the USER actually want it? Sometimes, it is possible to get your wants for the software confused with what the user actually wants. Stick with the user data and this will not be a problem. If it is something that you like to add to sites as a value add, etc., it can be hard on your ego to let it go. However, remember that our job is to speak for the user. These are the items that we can barter with. Let the team know you can drop this item in place of something the user NEEDS.
  4. Is the item something someone else in the team wants, but the user hasn’t requested? Again, think “Will it hurt the user?” If not, and it will give you some good grace with the team to put it into your designs, do it, as long as it doesn’t interfere with the release of features that are required for the user to complete his task. 
    If you scratch my back, I'll scratch your's
    If you scratch my back, I’ll scratch your’s

Remember, everyone on the team wants the product to be a success.  If we all play nicely, we can build products that the entire team has been able to give input into and that fits the users needs.

Leave a Comment