Whatever your profession, opening up your work for review by other people is a scary business. We often dread the feedback, fearful they will spot some flaw in our logic or that their comments may derail our work.
Web professionals are no different to anybody else in this regards. They often fear stakeholders commenting on design or arguing with us about user experience issues.
Different people react in different ways to this fear. Some people avoid the moment, choosing to work in secret and only showing their work when they absolutely have to and when it has been crafted to perfection. Others may show their work, but dismiss feedback as being ignorant and ill informed. Unfortunately both these approaches are fundamentally flawed.
The “don’t show” defence
The problem with not showing your work is that sooner or later you will have to. Eventually your site will go live and you will receive feedback from stakeholders whether you like it or not.
Unfortunately the longer you put off this moment, the more effort you will have put into the site. If people don’t like what you have done then that work is wasted.
If somebody rejects your work or identifies problems with it at such a late stage, the cost of making amendments is huge. The earlier problems are identified the easier they are to fix.
That is why as we work on the University of Strathclyde website we are endeavouring to show as much of our work as early as possible. We believe this is the best way to identify problems and get them fixed before the cost of change becomes too high.
We are doing this in a few ways.
An internal conference
Before we even started work, we were looking for feedback. We did this by running an internal conference within the organisation, with over 100 people invited. We had multiple speakers, workshops and discussion groups exploring what we wanted the site to be like. This was not only a brilliant way of getting feedback, it was also a superb way of building excitement and educating people too.
We met with a number of stakeholders on an individual basis to build up a better picture of the organisation and what it needed from the web. We always find these sessions invaluable as they help form our initial ideas about the site and prevent us wasting time by going down the wrong track.
Sharing our work
Once we started production we shared our work as soon as possible. We have done this by releasing an alpha site that people can look at and also explaining what we have done on a Web Transformation blog.
Asking for feedback
Once the alpha site was up we didn’t wait for comments. Instead we actively approached key people soliciting feedback. We wanted to make sure we had all the facts possible before proceeding any further.
The feedback was almost entirely positive. Yes some changes to content were suggested, but overall people were happy with the direction. Were we just lucky? Absolutely not! The comments were good because we had been gathering and listening to feedback since the very beginning. We knew what was required and even when our response didn’t meet people’s expectations they understood that our response was considered. They felt consulted.
That brings us nicely on to the second response to feedback – rejection.
The “rejection” response
The other common response to feedback is to reject it entirely. By dismissing feedback as either irrelevant or ill informed you don’t have to act on it. Of course at the same time you are both insulting the person who provided the feedback and sending the message that you will do whatever you want!
Of course sometimes the feedback you receive is either irrelevant or just down right wrong. However, this isn’t a failing of the person commenting. This is a failure of your abilities to cultivate the right kind of feedback.
There are two aspects of this that need addressing – irrelevant comments and ill informed feedback.
Preventing irrelevant comments
There is no reason why you should receive irrelevant comments from people. The only time this will happen is when you ask the wrong questions.
Never ask somebody what they think of your work. This is bad for several reasons. First, you are asking for their personal opinion and almost always you need something more objective. Second, it is too vague to encourage useful feedback.
When we sent out an email asking for feedback on the alpha website we asked very specific questions. We asked:
- Is there content missing on this page?
- In what ways does this page fail to meet users needs?
- In what ways does this page fail to meet business needs?
- In what ways does this page fail to communicate Strathclyde’s values?
These questions were aimed to encourage the kind of feedback that would be useful to us. We didn’t want comments like “I don’t like the blue” because the design was already set by the corporate brand. We needed to know whether content was incorrect, whether we were failing to serve a specific user group and whether we were failing to meet a business need. Yes, we were interested if the design was entirely failing to communicate Strathclyde’s identity, but we didn’t want comments on specific typography, colour or layout.
The results were outstanding. Every piece of feedback we received was incredibly useful, and by focusing people on the right issues a lot of people suddenly realised why we took the approach we did. We both filtered out the irrelevant and educated through our choice of questions.
Reducing ill informed feedback
Not that our choice of question was the only way we avoided ill informed comments. We also had an ongoing campaign of stakeholder education.
I have already mentioned the blog and the conference we ran, but that was just the start. We also educated people when we met with them one to one, we worked collaboratively with key stakeholders so improving their knowledge and gave various internal presentations to explain our approach.
However, most effective of all was the video below. Before anybody could view a page on the alpha site, they first had to watch the following video. This made it very clear what they were looking at and set expectations.
The video helped avoid comments about the site not looking finished or being broken in a certain browser.
The issue of browser support is another area we chose to educate rather than avoid. We found out that the website looked terrible on Internet Explorer 9 from within the institution. This was because the browser was set to behave like IE7 for various internal reasons. As this is the main browser used within the University we could have held off publishing until the issue was resolved. Instead we chose to push forward and use this as an opportunity to educate stakeholders about the problem in a post tackling the issue.
The lesson to learn
All of this is a very long winded way of saying that we need to conquer our fears of feedback. Feedback is a vital part of the web design process and not one we need to shy away from. Instead it is something that needs careful management and consideration. We need to put as much work into our feedback mechanisms as we do into the sites we are building. It is a crucial part of the puzzle.
“young woman covers her ears” image courtesy of Bigstock.com