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