Boxes and Arrows: Comments by Andrew Hinton

Andrew Hinton — Fri, 20 Apr 2007 17:45:11 GMT

I think looking at design evolution is a great idea, but I’d like to see a discussion of what the aesthetic choices actually mean in terms of usefulness. For example, rounded corners are all the rage—but what do they accomplish in a UI that a square corner may not? (It could be something very utilitarian like “makes a panel feel more a part of the surrounding page, so users don’t mistakenly overlook it as separate” or something like “users tend to respond more favorably to a softer visual feel in some contexts based on research from X…”) Also, I think ‘minimalism’ is a somewhat subjective concept: Google Maps may look minimalistic to the aesthete, but to a UI designer it’s an incredibly rich, densely textured design.
To some degree, this speaks to the rift between “Comm Arts design” and “UX design”—interactive experiences are things to be used, where every color, every line has potential interactive meaning for the user. There’s no such thing as a purely aesthetic choice in an interactive design… Anyway, didn’t mean to overcomment here, I just think those issues would be of the most interest to a B&A audience. (at least, I can hope? :-) )

Andrew Hinton — Fri, 20 Apr 2007 17:50:47 GMT

I like this idea. Let me make a couple of suggestions? It would be great to 1) find some case studies on this and include them (I know they’re out there, I just can’t find my links right now) and 2) discuss the ROI—how much money can be *saved* by improving an intranet, especially its IA issues. It’s enormous… but often overlooked when budgeting for employee tools.

Andrew Hinton — Wed, 16 Apr 2008 22:14:44 GMT

Livia & James: Thanks so much for the feedback. I’ll admit, I did think of these points, and tried to pre-empt them in the piece, but maybe didn’t do it well enough.

In short: I wanted to emphasize that personas are first and foremost the act of empathetic imagination for design; and I wanted to emphasize that all design documentation is first and foremost an artifact/tool for collaborative reflection, shared understanding and iteration. As long as we remember these things, we can then go on to make all the persona descriptions and slick stakeholder deliverables we want and need to get the rest of the job done :-)

My article is meant as a corrective statement, to a degree. This is why I focus so strongly on what I see as the *first* priority of methods and documentation in design work—shared artifacts for the design process. Because I think this has gotten lost in the conventional wisdom of “documents for stakeholders,” I amped up my point in the other direction, trying to drag the pendulum more toward the center.

I was careful to point out that stakeholder communication is also, of course, a very important goal. But it is a SEPARATE goal. It may even require creating separate deliverables to achieve! We too often get caught up in using documentation as a tool for convincing other people, rather than tools for collaborative design among the practitioners. I may have overstated my case, though, and, alas, obscured these caveats I scattered throughout.

Probably I could’ve been this clear in the actual article? *sigh* ...

At any rate, these conversations are the real reason I wrote this … so please keep the feedback coming!

Andrew Hinton — Thu, 28 Feb 2008 01:51:53 GMT

Jamie: I agree totally. The article is already super-long, so I didn’t get into that aspect, but I’m a BIG fan of “Contextual Design”- like process, where there is HIGH collaboration through as much of the design process as possible. In CD all analysis & development of models happens in collab. with stakeholders involved as well. (I’m not doctrinaire on the Holzblatt-specific CD method, but the essential elements are incredibly important—and undergird a lot of my assumptions in this piece). Thanks for making this point :-)