I'm been following this question about usage and usability design
VERSUS incremental development for quite a while - since Jeff started
up this group, and talking with him, and comparing how he describes
visual designers' work v programmers work, and how I also do and see
I confess that I can't yet see a way out of the conundrum.
Visual designers really do benefit from wide-band ideation, exploring
lots of ideas early and concurrently and leaving ideas on the table for
cross-pollination. The sketchboard and cartooning discussions show this
Software designers/programmers these days tend to get the base idea
pretty quickly and program incrementally, changing the architecture as
I don't know what the resolution can be. Certainly, faster more sketchy
ideation period for the visual designers, learn to adjust to surprises
that show up later and learn to work incrementally ... but until and
unless someone shows up with a way to revise UIs inexpensively half-way
through a project, I can't see advocating "do visual design as you go"
as some companies are forcing their visual designers to work.
I will counter with a particular proposal that may buy visual designers
some time ... it's an idea from the old Smalltalk community back in the
early 90s. Namely - have the software designer/programmers design and
code up the system entirely to an API, not a visual interface.
The API defines the services the system needs to support and the
information structures it needs to be able to produce (and absorb).
This is fairly much independent of the visual design, the sequence of
screens, the placement of visual elements. That design can be going to
in parallel, or even a bit behind, since it will simply call upon the
As I wrote, this is what we recommended and occasionally did in the
early 1990s on Smalltalk projects (using the transcript window for all
I/O to start with), and I have found myself doing this with my current
project to replace my website. We have the entire website working with
absolutely no visual design in place. There is (hopefully) nothing the
visual component will ask for that we haven't already tested that the
system can produce. We are, however, a bit more experienced in talking
about what the meaning of certain requests mean in terms of
computational implication. We've recently started on the visual design
and not found any conflicts.
what this means is that the software designer/programmers can code and
test every part of their work independently of the visual design.
I don't know how this would look on a larger project with multiple
The hard part really is finding programmers who are willing to build a
headless system to an API. Most of them insist on a UI for no
particular good reason (and thereafter couple the system too closely to
the UI and get stuck after that).
If anyone else is / has played with this approach, please comment on
cheers - Alistair