Summary
Good user interface design is one of the most poorly taught disciplines in software education. Such poor foundations follow programmers all the way to their positions of leadership in the industry, and the Agile Manifesto authors are no exception. Here, I post my thoughts on a recent posting in Håkan Reis' 'blog, whose views struck a chord with me.
Advertisement
A recent 'blog by Håkan Reis picked up on some things I said in my keynote at Øredev 2006 about common pitfalls of Agile practitioners, and in particular those that contribute to bad user interfaces. My points were that: 1. Test-driven development without architecture emphasizes a procedural architecture rather than the kind of good object-oriented architecture than supports the direct manipulation metaphor, which in turn is one foundation of a good user interface; and 2. That the Agile Manifesto leaves usability at the side of the road.
Here are the comments I added to that 'blog.
The Manifesto is by and large brilliant, but in retrospect one does find it blind, so to speak, to our users' perspective. Most of it is about solving our problems as programmers. Even customer engagement ends being a problem for us, because we get relatively quick feedback if there is a requirements mismatch, and that stings. So the manifesto has a heavy user-story focus because that's what its authors knew. It's a baby-and-bathwater problem, one more time with feeling.
Usability and maintainability are long-term issues. I think that most Agile organizations adopt short-term postures. Long-term underpinnings are necessary to short-term agility: You must be fit to be Agile. Getting into shape, developing the right architectural posture, takes time and effort. (That was the first point I emphasized in my keynote, referenced in one of the links above). Too many Agile practitioners ignore this foundational discipline because they confuse Agile with instant (programmer) gratification, under the excuse of rapid customer delivery (which is a good thing) and quick feedback from the customer (which can also be a good thing). So I've seen a lot of Agile projects crash and burn after about their third external iteration for lack of good architectural foundations. It doesn't take much architecture to shape the whole -- just enough to keep Conway's Law happy and to lay a foundation for the interface -- but it takes much more than Ron Jeffrie's fabled "ten minutes of design." Maybe a sprint's worth is enough to get started.
If an interface is unproductive or inhumane, users notice it only after a long enough time has elapsed for habit formation to be a factor. You don't notice such things when you test drive the program; the clumsiness is hidden behind the familiar Redmond look-and-feel or behind some graphic artist's sugar coating. Some users never get beyond their awe of such sugar coating to understand that they system is costing them dearly in time. (I think it's Beyer and Holtzblatt who make the point that it takes much longer using Word to type a letter and envelope than it does using a typewriter.) Those users who do ultimately become conscious of the inefficiency of their interface, do so long after leaving the store where they bought it.
Unlike bugs -- which are more black and white -- usability concerns are difficult to convey to the vendor. They often must be substantiated by data, studies, analyses, measures, and comparisons. Most users don't have the tools or even vocabulary to develop such critiques of the interfaces they use. Curiously enough, neither do most vendors, and most Agile projects are changing the software too rapidly to undertake such studies. The most that a user is likely to say is that an interface is "clumsy" or "awkward," and it's hard for a typical vendor to do anything with that. An insightful vendor will of course do some dutiful usability work. I just worked with a client a month ago who quickly (agile-ly!!) responded to static from their users about usability problems. The users were right, and we made a lot of progress. Things seldom go so well.
There is a close relationship between the structure of one's domain, the structure of one's interface, and the architecture of one's software. The most superficial understanding of OOD and MVC together bear this out. Those structures evolve more slowly than user stories do, and must be nurtured with care. Agile has a poor history of being patient or of dealing with long-term stable structures, or recognizing the feedback loops that reflect problems in those structures. There is no user story for usability nor for maintainability. So, in fact, I think the problem goes much deeper and is much more serious than you point out here.
As you said in your previous 'blog, it's only when developers start taking this to heart that things will change. That goes back to how universities educate their students, and how corporations value investment in the user interface. In the mean time, we follow a blind manifesto. A blind manifesto can type code quick and in an Agile way, but it has difficulty working its way across the busy street of the market place.
But, agility and usability are not competing goals.
In http://www.artima.com/weblogs/viewpost.jsp?thread=174969 (which failed to get any comments ;-) ) I put up what I think is a fairly succinct statement of usability goals: There are two kinds of software experience you want for your end users,
1. Invisibility - the software they use in their daily life enables them, doesn't get in their way and certainly doesn't make them want to hurl the computer out the window.
2. Smile on My Face - something about the way the software empowers them, what it lets them create, makes them feel like they want to go show Mum what they just did.
You need the team to buy into that kind of overall philosophy first, then challenge them as to how to integrate it into agility.
Usability is just another awareness.
Consider performance. Most of the professionals I know don't obsess about performance or indulge in premature optimisation without profiling. They also have a background concern that has been built up with reading and thinking about their profession, that monitors design decisions and (mostly) jumps in to stop really stupid performance-affecting decisions.
> Programmers should never ever design user interfaces.
I have a lot of trouble with that statement because it sounds a lot like (for example) programmers shouldn't write requirements which sounds great in theory but breaks down in practice because it doesn't tell them what to do when they do find themselves writing requirements.
or, as some other specialists might say, programmers shouldn't design data models...
I think your blanket statement is wrong and programmer education should include the basics of UI design because inevitably they will find themselves doing it somewhere, sometime.
More importantly:
Programmers should care about usability is not the same as saying they are responsible for designing the UI.
I would say the key response/practice that applies here is to introduce iterative user testing. I know that this is uncommon on Agile projects but it seems to me to fit quite nicely into the whole testing/concrete feedback mentality.
The effectiveness of iterative user testing (from prototypes to an evolving system) is well supported by evidence (http://www.usability.gov/pdfs/chapter18.pdf) so I'd say that the "The Interface is the Program and the best interfaces are Agile".
(I'm not a great fan of dodgy analogies but here goes...)
In motor racing circles, it is an idiom that car mechanics generally make poor racing drivers. At first glance, this would appear to be counter-intuative. You might assume that a mechanic - who knows all about how the car is put together and what its limits are - would be the best person to drive it to its limits, however it turns out that mechanics care about their cars and - knowing the car's limits - are reluctant to exceed them, knowing what damage will result. Racing drivers, on the other hand, just see the car as a means to win the race and are quite happy to blow up the car to get there first.
UI development is similar in that software developers see it in terms of the mechanics required to generate it. A large part of their emphasis is on those mechanics and getting them working. Users (often also UI designers) are largely unaware of the mechanics and their limitations. All their awareness is focused on usage and getting the job done. It is this emphasis that make the difference between the design of a working interface and a "winning" interface.
This isn't to say that programmers can't do good UI design, just that the odds are stacked against them even before they start.
> Programmers should never ever design user interfaces.
Fortunately no one does. Instead programmers copy user interface pattern ( or embed custom controls ) they have seen elsewhere and did like. They re-engineer an existing GUI design instead of inventing one by themselves. Hence their applications look all alike or like small variations of a common theme. Next year another Redmond fashion. Programmers are aesthetically unsophisticated and many are proud of approaching standards just like most of their consumers. Tools shall look and feel like MS Outlook or Visual Studio and sometimes even like bash. That's usually enough. However if it really has to deal with a sophisticated UI a company better engages a real designer. But which one does not?
Form follows Function. Mah GrandPappy told me that, waaay before computers had UIs. He was way before computers at all.
Some vendors/orgs are finding the wisdom of using the (relational) database as the basis (the Form) and letting some code generator make the UI (the Function). We will get there, eventually. The winners will get there sooner, since it is Wiser. The data is King; the View is the servent. The User may see the View in any way s/he likes. The User may not specify the structure of the Data.
Most really bad systems I've had to live with, came from non-developers. Users (often called Business Analysts, et al) would define a "screen" from which a file (later, a DB table) would be defined. You can see where this ends up, right?
The Whole Point of MVC (or its smarter successor, PAC) is to be able to swap out the V at will. The logical correllary: use some automated process to read the M, and generate any V you want. In particular, the Data can be shown as whatever widget makes the most sense. The structure of the data is a reflection of the model (some consider them congruent, I sure do); either way, neither is a reflection of the View. That way lies ruin.
Using a generator view of the View/UI leads to a very agile Interface; just push a button when the data model changes, and kaboom, and new UI. We don't need no stinkin Web Artistes.
The fact of the matter is, design is hard, and in software development, it is all design. If you design an API, you should be thinking about the user, and if you are designing a UI you should be thinking about the user as well.
> Programmers should never ever design user interfaces.
Arguable. But leaving that debate for later...
Certainly a programmer, with good familiarity with the program structure, should review the UI. Cause they are likely to see some button or checkbox and say "what the h**l happens when they click that?" Which reveals that either the requirements are wrong, the UI designer got something wrong, or the software design is wrong.
> The fact of the matter is, design is hard, and in software > development, it is all design. If you design an > API, you should be thinking about the user, and if you are > designing a UI you should be thinking about the user as > well.
I agree - and to elaborate further - it is important for the designer to *become* a user for awhile.
So when designing an API, it is a good idea to also build a non-trivial application that uses the api at the same time.
When designing UI, you should really either get enough training to do your target user's job, or spend some time looking over their shoulder to see what they really do during the day. The results are often surprising. Everytime I've done this, I've spotted some major bit of clumsiness that could be removed with just a little extra work.
I agree, there's more to the function and form of application development than saying computation and processing is the function, while the skin is the form.
the ui has it's own requirements and process, and like any system deserves a fair amount of objective optimization.
> Certainly a programmer, with good familiarity with the > program structure, should review the UI. ... Which > reveals that either the requirements are wrong, the UI > designer got something wrong, or the software design is > wrong.
A good start, but, if we have a programmer and a UI designer working independently from an external set of requirements, we are not talking about anything resembling an Agile process ;-)
Flat View: This topic has 45 replies
on 4 pages
[
1234
|
»
]
Previous Topic
