for example, the ability of the application to return and reevaluate facets and
visualizations with each click. Having
Davor there to help evaluate those proposed design changes right away from
a performance perspective through
rapid iterations of a lightweight Java-based prototype helped to create a nice
set of synergies right from the get-go.
Jean-Luc aGathos: Even though I
didn’t get involved in the project until
later, it seemed as though Davor had
produced a solid proof-of-concept. He
also figured out some very important
processing steps along the way, in addition to assessing the feasibility of some
key algorithms we developed a bit later
in the process. I think this was critical
for the project, since even though people tend to think about user experience
as being just about the way things are
displayed, it’s also important to figure
out how that stuff needs to be manipulated so it can be processed efficiently.
GosPeR: That’s absolutely correct.
For this product to succeed, performance was critical—both in terms of
processing a large index of data and
being able to evaluate which facets to
return to a user to support the experience of clicking through a new data
analysis at the speed of thought. The
capabilities for assessing the relevance
of metadata relative to any particular
new query was actually Davor’s real
focus all along, so he ended up driving that investigation in parallel to the
work I was doing to refine the usability
of the interface.
I do recall having discussions with
Davor where he said, “Well, you know,
if you approach ‘X’ in the way you’re
suggesting, there is going to be a significant performance hit; but if we
approach it this other way, we might
be able to get a much better response
time.” So we went back and forth like
that a lot, which I think ultimately
made for a much better user experience design than would have been possible had we taken the typical waterfall
approach.
coatta: Are product engineers typically excited about being involved in a
project when the user experience stuff
is still in its earliest stages of getting
sorted out?
aGathos: Yes, I think developers
need to be acquainted with the user
stories as early in the process as pos-
JuLian GosPeR
for this product
to succeed,
performance was
critical—both in
terms of processing
a large index of
data and being able
to evaluate which
facets to return
to a user to support
the experience
of clicking through
a new data analysis
at the speed of
thought.
sible. To me, user experience and development are essentially one and the
same. I see it as our job as a group to
turn the user stories into deliverables.
Of course, in development we are
generally working from architectural diagrams or some other kind of
product description that comes out
of product management. We’re also
looking to the user experience people
to figure out what the interaction model is supposed to look like.
The interesting thing about the first
version of Polestar is that Julian essentially ended up taking on both roles. He
acted as a program manager because
he knew what the user stories were
and how he wanted each of them to be
handled in terms of product functionality. He also had a clear idea of how he
wanted all of that to be exposed in the
UI and how he wanted end users ultimately to be able to interact with the
system. That greatly simplified things
from my perspective because I had
only one source I had to turn to for direction.
coatta: You used Agile for this
project. At what point in the process
can the software developers and UX
designers begin to work in parallel?
GosPeR: If you have a good set of user
stories that have been agreed upon by
the executive members of the project
and include clear definitions of the associated workflows and use cases, then
the Agile iterative process can begin.
At that point you are able to concretely
understand the functionality and experience the product needs to offer. On
the basis of that, both UX interaction
designers and the development team
should have enough to get going in parallel. That is, the developers can start
working on what the product needs
to do while the UX guys can work on
use-case diagramming, wireframing
and scenarios, as well as begin to coordinate the time of end users to supply
whatever validation is required.
The important thing is that you have
lots of different people involved to help
pull those user stories together. Clearly, the UX team needs to be part of that,
but the development team should participate as well—along with the business analysts and anybody else who
might have some insights regarding
what the product requirements ought
to be. That’s what I think of when we