Category: user experience     Posted by: cornelius     Discuss: view comments     Views: 421

The more I work on large projects, the more I realize that there is a point in each of them where a rift is created between the priorities of the senior management team and those of the UX team. Let's think about the typical timeline of how this plays out: Initially, we present our past work, our methodology (process) and the advantages of having a UX team on board. We show them user research, IA and design documentation, previous prototypes, finished designs and we hope that something will resonate with them that will persuade them to hire us. We'd like it to be something we've done in the past or the methodology we're employing, but as the project goes on, we realize that it was something else.

Typically (and I say typically because of my own experiences, I am sure things are slowly shifting), senior management is intrigued by the idea of having a UX team on their project mainly because one thing only: risk management considerations. I know, this sounds cold, but it's at least a large component of the truth. I've had this discussion as part of lessons learned / post-mortems of many projects that I've been involved with, and without exception, that was the main reason why a UX team was initially considered for the project. To expand a little further, the senior management team sees having a UX team on large projects as an insurance policy that states that by employing UCD methodologies the client will be part of the design proces. As a result, when UAT comes around, it will be very difficult for the client to reject a design that they were at least partially responsible for. All very valid points.

However, at some point in the process (in my experience this occurred anywhere between right after the end-user research stage, to the end of the high-fidelity prototyping stage), senior management starts to get impatient... Even though we are on track as far as the project plan is concerned, and even though the clients love the idea that we are constantly picking their brains in regards to how to redesign their product, senior management teams tend to get unhappy about the things that we uncover. So in this series of posts about why the senior management team hates UX, this is the first item i want to talk about...

For some reason, the senior management team will always assume that most of the things we will uncover are related to layout, design and maybe in some cases workflow. It turns out that on top of creating a better layout and a better workflow, we also tend to uncover other things like new features that are very important to the client and no one in the functional requirements team bothered to explain to them and/or major process improvements that positively affect the user experience.

These of course, are double edged swords. On one hand, senior management should be very happy because making these changes/additions guarantees that the client will be happy with the final product. But on the other hand, spending the time to define, analyze, prototype, develop and these new features/changes does require additional human and financial resources. Sadly, this typically results in a heated argument between myself as UX Manager/Lead and my project director regarding how this came up and why I didn't immediately shut down those discussions with client. Of course, long explanations and justifications ensue.

Don't get me wrong, I'm not asking my clients or my UX teams to go out there and ask what else they want in their applications, most of the time these features happen to be things that are making the client's life much easier and no one bothered to present to them as options. They are also critical elements, not simple cosmetic additions. But in the eyes of senior management, these are new things that were not planned for and more importantly budgeted for... As much as I'd like to question how the budgeting was made not allowing any kind of on-the-fly changes, I know I would be out of line to do so. But nonetheless, the argument still stands. Call it 'padding', call it whatever you want, when dealing with large projects, the requirements that were initially defined will have to be refined during the work that the UX team is doing. Also, the work of the UX team will minimize the requests coming out of UAT so any resources available for post UAT should be easily shifted to assist in making these on-the-fly changes.
I am trying to make all this very clear during my interview and the initial meetings with my project director, but most of the time, this seems to be just polite talk.

These days, I am shifting the way I approach this conundrum. I tell those who are hiring me that they should treat me as working for the client, not for the hiring company. This way, all of the objections that are being raised have to be considered as if a client made them, and not someone who is hierarchically lower than the senior management team and whose objections can be easily refuted. I also happen to be the kind of UX practitioner that will not put my name down on a deliverable if I don't think the work has been executed ethically and up to the standards that all parties expect.

What are your thoughts on this? Anyone else out there encounter similar situations?

Tags: user experience, design, project management, research

steven (03.03.2010 14:48:07) wrote:
Completely agree. I also find that senior management is prepared to use a UX resource but more often than not they are not prepared to act on the recommendations that come out of the UX stream, even though the client is fully supporting those recommendations.

Leslie V. (03.03.2010 15:02:57) wrote:
Cornelius, you should also make a note of the flipside. Sometimes UX teams do come up with things that are completely pointless in relation to the main business goals. If the clients really want those, they should issue change requests and the contractor should be paid for the additional development effort. Just because the UX teams identified new requirements, it doesn't mean that the inclusion of the requirements should be free.

robert (04.03.2010 07:51:21) wrote:
Failing to plan is planning to fail (Benjamin Franklin). The issues you’re bringing up in your blog post are, unfortunately, not at all uncommon. Curiously enough, this is actually a project management problem and it stems from not allocating sufficient time for a proper business analysis and, as you point it out, for unexpected changes during the life of the project. In my experience, numerous software development projects failed to create a real partnership between the client and the development team. Hence, the requirement specifications where not comprehensive enough before the actual development work started, the risks with the project, including incomplete requirements, were not accounted for in their totality, and the client signoff wasn’t required to “seal the deal”. Not to mention that the execution phase of the project brought its own problems with it, among which quality of work was one of the key ones. Finally, the software failed to meet the client’s specifications, and was either scraped and the work started from scratch with a different development team, or the former adapted to the software by “implementing” a large number of workarounds. All in all, not a “happy” ending.

Mike Cashman (04.03.2010 12:15:19) wrote:
Requirements are usually continually unearthed through the life of any project including software development and indeed through subsequent use of the developed system. At some point in the project serious efforts may be made to close the door to further changes at least in the initial version of the system. But what should you do if you want the plan to be a good predictor? (NB sometimes this may not be the objective, e.g. the plan may be produced with a particular commercial objective). If you want the plan to be a good predictor, then you might choose to propose a change budget that takes account of typical volume/percentage of changes as seen in previous projects in similar environments. I'm using 'environment' as a short-hand for everything that might affect volume of change, including commercial relationships, company culture, technology, business area etc. As Programme Manager I've sought to ensure that a rigorous regime is used for change assessment that considers the incremental cost and benefit of the change; where this gets difficult is is you disover that the business case would fail because some flaw in design means that some critical business transaction cannot be completed in the time that the productivity gains in the business case require, and therefore you're faced with spending the extra money on the change just to get the business beefits you were expecting anyway. But at least if you have the change budget in place then you have allowed for these costs in the original business case.

cornelius (04.03.2010 13:21:50) wrote:
I agree with all of the above. As far as requirements gathering, there has been little discussion about whether functional requirements analysis is enough. I may even write a future blog post about potentially combining functional requirements gathering with end-user research (visual, user-interface related, non-functional-yet-still-functional-in-my-opinion requirements :O). It is unfortunate that a UX team is brought on board only when senior management is already scared of volume/complexity of the functional requirements and the formal UX workstream has not even been originally included in the budget.

Note: Your email address will be protected and will not be shared with anyone.

Name:*

Website:

E-mail:

Comments:*