So, we learned a great deal about the design process in addition to the participants taking
away some design experience. The workshop organizers did not expect to turn the
workshop into a "laboratory" on design, it just turned out our observations were
As with estimating staffing plans for building software, we feel the design groups
lacked a realistic prototype to allow them to make estimates of how long it would take a user to
complete the task if the system was implemented. Using the paper prototype approach,
it was unrealistic of the workshop organizers to expect the groups to estimate task
completion time effectively.
If a tool existed to estimate time to complete a task using a large repository
of known task times, then by prototyping the design, flow, and revision points in
this software program we could accurately assess task completion times.
From previous experience with time estimations for military applications and
modeling/simulation programs, it is realistic to build this
for applications but only if task
completion time is vital (i.e.,. military, transport, real-time production environments). This
would be a complicated tool to build and would likely require a company serious about
building statistical models of user interaction on the web. Of course, by the time
someone does this, the web will have migrated to mostly Java applications, which
would be easier to model with some existing time measurement databases.
Nevertheless one should be considerate of how server time, download time, and type of
browser, etc. will affect usability.
An example of a simple quick interfaces Edmunds car web site (i.e, http://www.edmunds.com). It does not contain fancy graphics and high-bandwidth applets, but gets the job done by having a wealth of information, organized in a logical manner. The information is well represented in a heirarchical arangement organized by types of vehicles and years. We will see one the designs later that looks at a different model for arranging this type of information.