Tammie Egloff's Usability Blog

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

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.