Category: gadgets     Posted by: cornelius     Discuss: 2 comments

There is a lot of love out there for the symbiosis between Agile and UX these days. More often than not, companies that are using the likes of Scrum or XP (eXtreme Programming) as their software development methodologies are including user experience professionals as part of their delivery teams. So why am I writing yet another blog post about this very topic? Well, from my experience, this marriage doesn't work quite as smoothly as advertised...

The acceptance of user experience in agile organizations is a relatively new concept. Being able to quickly research, perform IA work (typically task flows, wireframes and sitemaps), create high-fidelity prototypes, perform UT (usability testing) for a story and then be able to serve it up to software developers is enticing to every development manager out there. And while this concept may work from a theoretical perspective, when it comes to execution and deadlines, it quickly becomes very clear that if the team falls behind, there are typically two areas that suffer: user experience and scope (and ultimately quality). Development managers are delivery driven (rather than quality driven), and for them delivery means one thing: code. As a user experience professional working in an agile environment, how many times did you hear a development manager telling you that you no longer have time to spend with the end users for user research, and that those deliverables (be it wireframes or high-fidelity prototypes that are required by developers for a particular story) are now due in less than 24 hrs or even worse, not needed altogether because the functionality is fairly simple and the developers will be able to go straight to code without them?

In my career, navigating the extent of my involvement within agile teams has sometimes been rocky. Yet at this point, looking back at projects ranging from the success stories to those that were quite simply narrowly avoided disasters, two distinct themes have emerged, and are going to be the focus of this article.

» Share article on:

Category: user experience     Posted by: cornelius     Discuss: 5 comments

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...

» Share article on:

Category: user experience     Posted by: cornelius     Discuss: add comment

I'm currently staffed on a huge multi-year project (millions of dollars, a project team of over 100, a UI team in double digits etc.) and I just realized one sad truth. Whenever I'm involved with a large modernization project (or upgrade if you prefer), usability and common sense seem to be thrown out the window.

The fact that we are ultimately talking 1000+ screens (of which not even 10% are already implemented) scares everyone whenever usability flaws are being brought into discussion. I'm not sure if it's a matter of scale, or simply the fear to take risks. Rearchitecting the entire presentation layer would have been the ideal thing to do here, and would've made a huge difference in the quality of the application. My guesstimate is that this would have cost close to $1 million, but either way, that's insignificant compared to the entire cost of the project. So why do technology and functional teams run away from better design ?

» Share article on: