We work with some incredibly talented development teams around Web sites, Web applications, and software projects. Unfortunately, teams missing a user experience specialist often find that they cannot come to consensus on what the user interface should look like, or what it should do. This leads to a sub-optimal user experience, with the common result being that powerful software functions are invisible to the user. That wastes money - and obscures the excellent work of your team.
The cost to business of skipping the critical planning stages - which include user profiles, usability testing, information architecture, user interface design and task sequence design - is incalculable. Skipping these steps means endless hours of expensive meetings where everyone has an opinion, but few have real data.
Stop for a moment and consider the areas of expertise your employees own today. Is there someone on staff with formal training in user interface design? Information architecture? Task sequence design? If the answer is "no" or "sort of," it's time to start adding up the cost of all the hours spent in meetings with no consensus, so you can reallocate those funds to usability training or professional services that will bridge the gap.
Subscribe to:
Post Comments (Atom)
As a developer I can readily attest to the horror that we can create in terms of usable (and pleasant to use) interfaces. One thing that I've seen recently was using Agile development techniques integrated with User Experience (UX) design and I'd love to hear your thoughts on this.
ReplyDeleteEmerging Best Agile UX Practice.
As long as Agile does not mean disorderly... Seriously, this is probably the most pragmatic approach, as long as there is, to quote Sean Fitzpatrick, "freedom within structure."
ReplyDeleteHave you seen the meeting cost calculator?
ReplyDeleteAdd up the hours of opinionated meetings and see how much you're spending on conjecture.
No, Agile definitely doesn't mean disorderly. In fact it's a way to bring some sense of order out of the chaos that is development. But it relies on some key principles:
ReplyDelete1) Don't develop things before you need them
2) Don't specify what they are until you know that you will need to develop them
3) A feature is only DONE when the business says that this feature meets their requirements. Then you can move on to other features.
This flies in the face of Big Design Up Front, where management wants to know that every single feature is accounted for, documented, specified and put into a project plan. Real projects don't work that way - I should know I've been on enough of these BDUF projects. Features get pulled, UIs get rewritten and more work goes into the maintaining of the "Project Plan" than in actually delivering a product.
Here's the biggest take-away from Agile development that I love:
Agile is about delivering a working product to the customer that satisfies their needs. Period.