Skip to main content
Posted on January 18th, 2010 by
One of the main attributes of the design work we at ADGi do (and when I say design I mean interaction design and information architecture, not so much visual design) is that all of it is evidence-based. That is, all of it, and I really mean all of it, every interaction, every node in the site map, is driven out of user research and expert analysis. I also insist that the designers who work here can articulate what the evidence or expert analysis is that led them to making the design decision they did.
The approach is somewhat nerdy and for design hot shots, boring. But it works. It works from both a usability perspective as well as from a user experience perspective. It also results in designs that are far from pedestrian. Here’s why:
The criticism I’ve heard from some is that this approach is either not agile enough or too constraining. I can appreciate both responses. A true Agile process is meant to get away from all that documentation, test small bits in process, and does not expect to have all the requirements and evidence up front. In my professional experience I’ve never encountered a successful redesign of any GUI or application (web-based or not) that maintained a pure agile process. That’s not to say it’s not out there, I’m just saying that the people who hire us do not have the large multidisciplinary teams in-house to run a successful pure Agile process. On the other hand I’ve encountered a great many projects and firms that use a semi-agile process: they do the requirements and planning up front and develop in a more agile-like way, working in iterations. This kind of process is well suited to our approach and we’ve successfully worked on projects like this.
The other criticism, that our process is too constraining, usually comes from designers (both visual and interaction) who design by feel. Again, I can appreciate the comment. It is quite difficult to design well by evidence, you must ‘own’ every last decision, you can never slough a decision off on the developers or visual designers. That is not to say that there aren’t some amazing designs and designers who work mainly by feel. It is also not to say that there is no place for that gut feeling in our process. For instance, when I’m reviewing a wireframe deck and my eye is drawn to something that doesn’t ‘feel‘ right, 99 times out or 100, it isn’t. My thing is this: when you work mainly by feel you are asking your client (be it internal or external) to put all of their faith in your gut. A designer’s gut is a fine thing but how can you defend, explain, describe, and maintain it?
For those of you who are working with designers be they user experience designers like us or visual designers, if your eye is drawn to something and your gut says there’s something not quite right there, it’s probably not quite right. Listen for that slightly discordant note in your head, or maybe that pause as you’re looking at something that make you stop. That’s a great time to channel your inner child and start asking why...