Are UI Requirements Software Requirements?
User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on "heuristics" and, frankly, the uneven quality of those who profess expertise in the subject.
I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.
I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.
The next revolution in requirements will be traceability or -- as I prefer to say -- connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between
- Business Objectives
- Marketing Objectives
- Functional Requirements
- Development
- Testing
- Usage
Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable "slow drift" away from the original business objectives.Imagine that you wanted to capture a certain "feel" as a marketing objective...
Why? Well, let's say that you believe "slippery" is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.
Even the softest requirements should be "connected" to business goals. If creating such connections seems like too much trouble for the requirement, chances are you're not dealing with a requirement in the first place.
Labels: product management, software requirements, traceability, UI, user interface design, Ux
posted by Justin at 6/16/2008 01:30:00 PM
1 Comments:
Interestingly, I just had a meeting with the software development team for a project I'm working on with this very same topic.
Our goal was to come up with a plan to define what our Usability requirements are going to be, how to specify them so that they're testable/measurable, and then how do we test them.
In general, we're going to stick to broad usability goals (learnability, efficiency, error rate, satisfaction, etc.) that have been prioritized by users in conjunction with some high-level task analysis. We'll identify user profiles, which usability aspects are most important to users, and what tasks are most important to users through surveys and talking with field personnel. The resulting matrix should give us a set of usability requirements for which we'll have to establish some metrics.
We may establish some quantitative criteria for these requirements, but I suspect we'll be largely qualitative in how we capture data from users. Real quantitative testing is simply too expensive for what we're doing.
As for testing, we'll be doing some budget usability tests in conjunction with formal Usability Studies to test our UI Design and determine how well it meets requirements.
So, on one hand we'll have requirements and on the other, we'll have a UI specification - a document that specifies exactly what we're building for the UI, and a trace between the two.
What's important here is that we're not calling the UI specification "requirements" - it's design. The requirements articulate either functional requirements or non-functional requirements, such as usability.
Usability requirements should be expressed like, for task A, the 90% of users should have an error rate of less than 5%. Or, for task A, 90% of users with a minimum of 5 hours of training should be able to successfully complete the task.
Post a Comment
<< Home