In my last post, I described the somewhat painful experience I had
doing QA on a system I had designed, but where the designs were “thrown
over the wall” to the development team. I’m still mulling over what
lesson I can draw from this. The basic problem was that I found all
sorts of conditions which we hadn’t factored in to the initial design of
this lookup system. If the system automatically detects the query type
from the input string, what are all the possible responses? What if a
particular option isn’t available for all users? If a “not found”
message appears, how should the user be able to re-do their search?
I’m tempted to say that I need to be more rigorous about the flow
maps for highly interactive systems like this. I drew one early on in
the process, but it wasn’t updated to reflect the numerous hacks and
requirements changes. Those flows got as far as “display the ‘not found’
message”, but they didn’t cover the full user scenario: What will the
user do then? Will they re-try the search? Will they change their
parameters? Will they give up and go elsewhere?
One answer, certainly, would be to create more thorough plans. But
the time pressure was intense on this project, and there wouldn’t have
been time to re-think that after each round of changes. Another answer
would be to coordinate more closely with the developers, so that the
product could be refined in a somewhat agile manner. But of course the
developers are under their own pressure, and we weren’t operating within
an Agile framework. Perhaps this was the best that could be managed
under the circumstances; but I can’t help but wonder whether there was
something else we could have done to create a better end result.
More generally, I think this says something about product management.
First, this experience highlights the need for the UX designer to be
involved in the development phase, not just the initial design. Even
the most detailed plans will run into unexpected technical constraints
or unforeseen use cases. If the UX designer isn’t in close contact with
the development team, the developers generally won’t think of reaching
out when unexpected things come up. They’ll implement whatever solution
seems easiest to them, often at the expense of good usability.
This experience also illustrates the need for iterative design.
Systems won’t always come out the way you intend; corners will be cut,
exceptions will emerge that you didn’t think of. Consulting projects are
often planned as if there will be no version 2 (or even 1.1), and a
smart product owner needs to understand that the thing you launch now
will need more work in the next release - even though it passed QA.