August 15, 2007
Transition from Visual Design to Interaction Design
Over the past month at Planet Argon, I’ve been taking on more interaction design work. Mostly because there’s a gap to be filled with all the design work on our plate, but also because I said I was willing to take it on. Visual design to interaction design doesn’t seem like a huge transition on the surface (it’s all design right?), but it has really been a challenge.
Maybe I’m still hanging out in the web standards design blogosphere too much, but finding IxD & IA blogs to read have been few and far between. The ones I have found get updated once every 8 months or so. In an effort to spread the knowledge, here are some initial thoughts and experiences from an IxD n00b:
Designing for interaction requires a lot more thought - Seems like an obvious assertion. Creating an user experience with interaction and behaviors that users have to interact with on a computer is a daunting task. In visual design, design decisions are based on an emotional response. Visual design for web applications—most of the thinking is already done for you.
The sketchbook is your friend - Until recently, I didn’t do much sketching. I had nothing against it—it was a personal preference. After doing some sketching for a current project, I have found it useful in getting solutions & ideas out of my head quickly and with little effort.
Wireframes versus HTML Wireframes & Prototyping - I am a big proponent of HTML wireframing & prototyping. Web applications encompass a lot of different interactions, some simple, some not so simple. Asking a client to fully understand a paper document made up of interface elements and interactions is asking too much. Paper is an inherently static medium, which is counterintuitive to the point of having wireframes in the first place. On the other hand, HTML wireframes & prototyping can capture interactions exactly same way as the will be in the final product. The design document is actually the final product. This topic is a blog post in itself, so I’ll leave it at that.
OmniGraffle is the worst (wireframing) tool ever - I’ve been taking my OmniGraffle rants out on twitter for the last couple of weeks. I really don’t understand why people love OmniGraffle so much. Maybe Photoshop spoiled me with all the keyboard shortcuts, but I’ll be damned if I have to use the mouse for everything. Having “hot keys” for the tools is ridiculous. Not only that, OmniGraffle seems to have a problem nudging things around when nobody is looking. I’ve went to other pages and come back to see elements nudged over 1px. I’d use OmniGraffle for flowcharts and diagrams, but anything interface related? most definitely not.
Overall, I really enjoy what interaction design & information architecture has to offer. It may not be something I ever master, but putting my brain to work to turn client ideas and business goals into something real that people can use is something I can get passionate about.
There are 4 comments on this post. Post yours Comments
I certainly agree about Omnigraffle, it’s a very poor man’s Visio. Maybe if you’re doing very simple sites or interactions, but I’m constantly in the 100pp+ range and I wouldn’t even attempt such a thing in OG.
I think if push came to shove I’d rather use an HTML protoyping tool at that level (for the small sites). fyi I’ve heard of people using InDesign, but if you’re happier starting out in HTML then it’s moot.
What non-HTML protyping is supposed to give you is the chance to see things before the HTML is written. It’s much easier for me to move a few lines around in Visio than to do the HTML. Again though it depends on skillsets/size of project/complexity.
John,
Wireframes are cheaper than a HTML prototype, there’s no denying that. The problem resides in the level of understanding a client gets from wireframes. Wireframes allow more room for misunderstanding which can cause problems as you get deeper into the project. I don’t see anything wrong with using the same medium to create HTML wireframes/prototype as the final product. We aren’t constructing a building where the walls are permanent. HTML/CSS is agile if you keep it simple, as wireframes should be.
A good way to see things before I dive into HTML is to do a sketch of the interface. It’s even cheaper than a document that could be produced with software.
I know this isn’t for everybody. Writing HTML & CSS is not a daunting task for me, as it might be for others.
Oh it’s not a matter of dauntingness, it’s a matter of process and documentation. On a large project wireframes are seen and used by, the client, the programmers, the designers, the interface developers (HTML/CSS/Flash), Quality Assuarance, Usability.
For example: When 3 months down the project the client asks why something works some way, it’s easier to refer to notes attached to versioned wireframes than a prototype.
Part of the role of the IA/ID/Maker of Wireframes is to make sure all parties involved understand what they mean, and also what they don’t mean. This could mean tayloring the wireframes to look more like a company standard, or adding extra levels of notes, or referencing a prototype.
So, there are cases where HTML prototypes/wireframes work, and there are cases where they don’t.
It becomes a bit problematic with web applications because the idea at the beginning of a project sometimes morphs into something completely different, which is why we (Planet Argon) have an iterative process with web applications. Wireframes aren’t very agile in this case because every time a change is made the IA/Interaction Designer has to update the wireframes. Wireframe maintenance can be expensive.
We also use subversion. We can tag the application at certain points and retrieve the versioned web application, if at any point we need to go back.
Notes can be attached to a prototype. It is possible to convert HTML to PDF and print it. Or take screenshots with Skitch. There are ways around traditional documentation.
I’m not saying we should do away with all documentation, just the wireframes.There’s even some cases where I’d accept wireframes as decent solution (websites with mostly static content or blogs).