Last night I went to the November UX Craft meetup and listened to Dennis Williams from kalahari.com and Vaughn Gunnell from Tag Worldwide talk about all things UX. Below are some brief notes I made.
- Start with the basics: the user goals and usability testing.
- Multi-screen journeys are very important today.
- Look at your customer lifecycle.
Vaughn ‘s talk
- User Experience is applying validated learning.
- Design is iterative and knowledge must flow up the organisation
- Continuous Improvement is your competitive advantage.
This weekend, I tore through the excellent Responsible Responsive Design by the crazy-smart Scott Jehl, the latest from A Book Apart. It’s a great read, and a succint summary of some new (focus on performance) and not so new (do Progressive Enhancement) ideas and themes that are bouncing around Front-end web dev land.
I’ve been having fun trying out sketchnoting things, rather than my previous technique of trying to scribble down every single word of something. I’m particularly interested to see if it helps my memory, which at the moment is terrible. Here are my sketchnotes form the book. Click a pic for a larger version.
“A Front-End Developer’s Ode To Specifications” on Smashing Magazine the other day made me kinda mad. I’m all for having a final Front-end implementation that matches up with the designer’s vision, but I think that this idea of “correctly implemented design” and pixel perfection is a damaging way of thinking about web sites because it implies there is one correct, pixel perfect, version of the design.
Designs, by and large, are still created in applications that create fixed width, fixed fidelity, non-squishy, output. This works well with the idea of a specification: “this one version of the product is the correct version.” It doesn’t work well with web sites, which are by their nature, flexible and changeable. Trying to exert this kind of control and constraints on a web site just isn’t tenable in today’s world wide web, or the future’s.
Even something as simple as a font is very flexible. You can specify a base font and size exactly in a specification. But how do you adjust the font size (and line height) for larger screens? And what is the font stack: if the desired font isn’t available, or doesn’t load, what fonts should be tried next?
If the specs were all in percentages rather than pixels: that would be a good start. But then you still need to consider breakpoints and showing layout changes across them. The drift that the author discusses between the designer’s final version and the implementation feels wrong. The developer might get the site looking pixel perfect in the latest version of Chrome. But what about Firefox? And what about Safari on an iPad? And what about Internet Explorer 10 on a Windows machine? These will already look different from each other, even thought they’re using the exact same implementation of the design. I think that that’s completely fine: but it won’t match the spec.
Front-end style guides, mentioned at the end of the article, are much more promising. They feel like a logical step into code from Style Tiles, the squishy design deliverable.
A few days ago, I watched a short video: Ben Callahan – Small Screen Navigation & Hamburgers. It’s well worth (the 13 minutes of) your time. That, and chatting with Rich on Friday about our upcoming talk at CTFEDS, got me thinking about hamburgers for navigation.
People still don’t get the burger; I had this confirmed during usability testing while I was at Flow. It’s more than just the icon itself, though. Us designers and developers throw it in there to free up screen space by hiding the navigation off the screen, but out of sight is out of mind for most users. It seems like hiding the navigation is the actual problem, not the burger icon itself. The most obvious (and oft-cited) solution is “fix your Information Architecture,” but that’s seldom easy, especially for something like an e-commerce site with a lot of stuff.
Another thing the video reminded me of was the value of regular, short, usability testing. It helps you find glaring problems quickly, and fix them. Then you can follow that up with a long tail of deeper testing if you have the time and money.