May 3rd, 2009

The power of authority

After completing a number of different projects I came to appreciate how differences in people’s perceived authority change how you can run and successfully complete a project.

When starting a project you can have many different stakeholders, all with their own idea of how they want an interface to work and look like. It is our job to take all of these different aims and comments and produce a professional usable interface that everyone is happy with.

There are a number of problems that can affect the success of the project:

  • Design by committee — decisions for the design get decided by everybody and anybody
  • Designers do not have any input into the decision making process
  • Stakeholders worrying and changing parts of the interface that actually work well
  • Constant and repeated changes to the design

These issues normally produce a final project that is late, unusable and the stakeholders are unhappy with.

Lack of authority and trust

These issues come from a lack of trust. A lack of trust in you and in what users are capable of understanding and in the designing process. Now if you are lucky, you are in charge of the entire process, overrule people (diplomatically) when you need to and to say no to constant design changes.

Now me and many other people that don’t live in this happy position. Instead we suffer from a lack of perceived authority. I say perceived authority as there are number of tricks you can use to improve how your authority is perceived and by doing so increasing the success of the project.

User testing

Often there is a lack of trust in how designs and interfaces work. When people want something changed it can be because they are worried that users will not understand. Although you may understand design and interfaces they feel they understand their audience better. On the other hand decisions can be made that you know will impact on the usability or are superfluous but the stakeholders are adamant that they want it.

Although you can keep on saying you know better, no one will believe you until they trust you or you can back up your information. User testing can be your back up. I have radically changed designs, user tested them and then reported back the findings to the group and had them approved with no arguments.

The reason was that I explained all of the issues, explained the testing with the users and the positive outcomes from the testing. All the concerns and questions they may of had I had already answered through testing and the explanation of that process to them.  As I have already tested on their user audience, most of their concerns were already mitigated.

It is worth adding that although user testing in this way is a good way of changing a interface and proving your own ideas, user testing is also very good at pointing out which of your own design assumptions are causing usability issues, and they are normally the ones you would never suspect.

By showing you are doing your homework and reporting back how you know your designs or interface are working you gain authority to significantly influence the final design or interface.

Get a process agreed

Rather than constantly have to change designs, get a design process agreed by all parties. Have a set number of designs reviews.  By design I mean images or an actual developed interface. Stakeholders comment on the design and you feed these comments and changes into the next iteration. If you follow the first point with user testing you can make sure that ideas that will cause issues with users do not have to be incorporated.

I like to have three iterations where we show a design or working interface for comment. I make sure everyone realises that after the third iteration only critical issues will be addressed. It also means that comments like “can we have a lighter shade of blue” two days before go live can be bounced back.

I am normally really busy running multiple projects at the same time so I may not be managing the process for a project. As a result, I always discuss the design and development process whoever will be managing the process for me and get them on board with this way of working, they then champion the process and manage it for me with the stakeholders.

By following this you can increase your authority and control the amount of changes that are made over the run of a project.

Trust

This one is a but harder the first time you run a project with a group or client. The first time you work with someone there can be a lack of trust. If you have the good opportunity to work with them again, you will probably find it better to work with people due to the gain in trust you both have after a successful first project. I have found this especially true for internal projects when I first work with someone.

What about you?

What tricks do you have, let me know below.


You should follow me on twitter here

Share the love

Comments

Feel free to join the discussion, or trackback.

Elena says:

You raise some good points here - especially getting to the up-front agreement to a process which is then used to control the volume of changes.

I’ve also found it useful to agree who has decision-making authority early on e.g. does the designer, project manager or user/customer have final say on how a particular requirement will be delivered (note that I’m not saying *which* requirements will be delivered, let’s assume the decision on that are already made or addressed via another process)?

Finally, I’ve also found that giving the customer a choice e.g. “we can either change the design of XXX or go live on July the 1st as planned” can certainly help focus the mind :-)

Join the conversation

Head of teddy bear appearing over the footer