When people try your software for the first time, they’ll be comparing it to every other application they’ve ever used, so it has to deliver a positive user experience (UX). However, when it comes to UX design, developers often drop the ball because they’re unable to recognize and avoid some common pitfalls. The purpose of this white paper is to describe some of those pitfalls so you’ll be able to screen out unqualified firms during the vendor selection process and choose a technology partner that knows how to build high-quality, usable software.
I wished more developers paid attention to the points in paper. In cases where software is to replace manual operation, it is also effective for the software not to diverge too much from already working solution. For example, I have a friend who works at a restaurant taking phone orders. Their usual method is to sort orders based on time and caller’s phone number. So orders go out in sequence and phone numbers are unique among orders and addresses are easy to look up once an order is ready to go. In a recent move to automate the process. The developer’s sort based on address and time. That has created a problem as addresses are long and hard to look up once 40 orders are in. As the paper mentions it, requirement analysis is absolutely important and has to be done at all levels. unfortunately in my friends case the software was developed using waterfall paradigm and had already costed two million dollars and changes were refused.
Reza, you’re describing a scenario that is all too common. It’s no wonder that some smaller, entrepreneurial firms with a culture for innovation, continuous integration/deployment, test driven development, and agility are having such an impact on our expectations of what “great software” can and should be. Yes, development teams should be conscious of what real users need and avoid big bang implementations. Great software requires a passion for proper software engineering, but it also never ends with a first deployment, or even a few. Too many companies define their requirements and budget as one or two “phases”, without consideration for where the real work and commitment towards great software lies – in the continuous process of improving the software through user testing and feedback. Check out http://books.google.ca/books/about/The_Lean_Startup.html?id=tvfyz-4JILwC to see a fantastic explanation of what I’m talking about, including techniques like A/B split testing and cohort analysis.