Monthly Archives: January 2009

Taking the UX Book Club to the edge

This last Thursday, we had the first NYC edition of the UX Book Club.  I attend a lot of UX-related events, but this one had a palpable energy and excitement that I haven’t seen in some time.  At the beginning of the event, some of us offered mini-reviews of our book choice, Bill Buxton’s Sketching the User Experience.  Peter March gave such an impassioned review, I kept expecting him to whip out a bible and start waving it.

And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.

Now, with a couple days hindsight, I have both great hopes for the potential for where this budding movement might take us, but also a creeping fear, concern, trepidation, whatever, that we will only read the books we’re already talking about, only the books written by people in our midst, only the books matching a search for “User Experience.”  Our reading choice for the event, Sketching UX, is a great book, dare I say an important book in the UX canon. We should of course keep reading books like this, book club or no book club.

But if we only read Books Written By People Like Us, I fear the UX Book Clubs will become navel-gazing, inward-looking, gatherings, where we mostly are drawing on ideas coming from within our practice. One way to prevent that from happening is to mix up our book choices a bit, and also include voices at the edge (or outside) of our practice, which I think would enrich our practice by looking at it from the outside in.

These are two books I think exemplify that edge, that are written by authors at the edges or outside our practice, and books I would strongly recommend as a reading choice for the UX Book Club.

Drawing on the Right Side of the Brain, by Betty Edwards

Drawing on the Right Side of the Brain, by Betty Edwards Though it will teach you how to draw, this is less a book about drawing, and more a book about seeing and thinking about drawing and illustration.  Too often, the focus when talking about sketching and wireframes is on the what (nomenclature, hierarchy, flow, etc.), which of course is important.

But just as important is the how.  A brilliant design concept presented by way of a crappy-looking sketch or wireframe is likely to be far less persuasive than one produced by a skilled illustrator.  And I’m not talking about whether or not an early idea looks sketch-like to invite feedback. Even that, attention to fidelity, is part of the illustrator’s craft.

And that is what Edwards teaches in this fantastic work, not only how to draw, which is important, but how to make drawing something you just do without thinking, like riding a bike. In fact, I think this book should be required reading as part of the core curriculum in an Interaction Design program.

Crystal Clear, by Alistair Cockburn

Crystal Clear: A Human-Powered Methodology for Small Teams Moving to the opposite edge of our practice, this is a book by one of the leading progressive thinkers in agile software development, and one of the original signatories of the Agile Manifesto.   In my opinion, it is one of the best books on the agile and iterative development methodology.

But more importantly, from the vantage point of a UX Book Club choice, it takes the developer’s vantage point: a crisp, unvarnished, and unforgiving take on what it means to design something that ultimately will need to take the form of ones and zeroes.  (Getting back on my what-should-be-in-a-ixd-curriculum-bandwagon, this is also a book that I think should be part of such a curriculum, but as part of an advanced course.)

Let’s not forget who are the ultimate users of our work.  After business stakeholders have hemmed and hawed about (often irrelevant) details on our wireframes and prototypes, after visual designers have enhanced and enriched our designs with elements both beautiful and beautifully useful (well, ideally anyway), the buck will ultimately stop with the technologists.   And Cockburn is one of the technologists and thinkers who is part of forging the path many many of the developers you likely work with or will work with are following.

These are just two books at the edge of UX.  For me, I would really enjoy attending a UX Book Club event discussing books like this, which I think will broaden and enrich our practice by helping us see our practice from the outside.

The User Experience of Resumes and Work Samples

As someone who has done a lot of interviewing over the years, and as a participant in the IA Institute Mentoring Program, I’ve looked at countless resumes and work samples.  I am currently reviewing another such set of documents, and was about to start writing them an email with my comments, but realized that I’d basically be providing very similar feedback that I’ve provided to many other mentees. (I just can’t get over that word – sounds a bit strange, no?)

So, I thought I’d instead just post my thoughts here so that others may also benefit.  Here, then, is the most common feedback I provide when reviewing someone’s resume and work samples:

The user experience of your documents can be a make-or-break factor

If I were looking at the resume of someone I’d be considering for, say, a carpentry or welding job, I’d be less concerned about a less than stellar resume design.  (No offense to carpenters or welders, btw.)  But when I am considering someone for a position whose very role will be about creating the most seamless connection between user and system, the design and presentation of these documents at the meta-level becomes a key focus.  Why?  Because the care that they took in, say, naming of their resume file is a direct reflection of the attention to detail they will be providing to the design of user experiences in general.

These are some of the most common mistakes I come across and what I would recommend doing instead:

Mistake: Submitting files, especially large files, as attachments

Even in the world of Gmail with limitless  storage, lots of people are still using archaic systems such as Lotus Notes, with limited storage.  By sending a huge file (i.e. maybe containing a prototype), you are essentially clogging their inbox as well as the inbox of the people they forward it to.

Additionally, once you’ve sent a file, you are married to that version of the file. In other words, if you notice a problem with the file (i.e. a typo) after having sent it, there is no way you can fix it.

Recommendation: Send links, not attachments

This is not only a much more elegant way of submitting content, it also allows you to make fixes after the fact.  Just as importantly, it ensures that everyone you send it to is looking at the same version.

To be clear, I’m not talking just about resumes.  Everything you submit should be done with a link, preferably a compressed link (I recommend using the is.gd link compressor), to ensure that the recipients client doesn’t clip the URL.

This, of course, means that you need to have a web space where you can post your files.  In my opinion, a personal website for anyone working in UX is an absolute must, so if this is an issue for you, you should be setting up your own web space forthwith.

Additionally, you should be applying the same UX best practices to this URL as you would in the normal course of your work.  Here is the nomenclature I recommend for resumes:

http://www.yourdomain.com/resume/first_last_resume.pdf

Having “resume” twice may look redundant,  but it’s critical that the name of the resume file itself is user-friendly, which leads me to the next mistake I often come across.

Mistake: Generic, Meaningless, Confusing file names

I don’t know how many times I’ve recieved resume files titled “resume.pdf”  That may seem self-explanatory to the person sending the resume, since they likely only have one of them. But the person on the receiving end usually has piles of these, which renders such a file name virtually meaningless and forces me to rename it.  Not good.

Recommendation: Make your file name portable and autonomous

You should assume that your file may move through many different hands and across many different email applications.  For that reason, you should first name your file conservatively from a portability perspective, meaning that you should always replace spaces with underscores (remember, when sending your file as a link, it will be part of the web address.)

More importantly, your file name needs to autonomous.  In other words, it should be named such that your employer, or some 3rd party that has never met you, should be able to recognize what it is when it’s sitting on their desktop or whatever.  So, if I were submitting a collection of work samples in a PDF file, the nomenclature would be something like this:

anders_ramsay_work_samples.pdf

Mistake: Assuming that people actually will be reading your resume

When you’re working on your resume, it can be easy to forget that, while you’re paying attention to every syllable in the document, which you should definitely keep doing, most people who are looking at your document are likely very busy and likely looking at lots and lots of documents just like yours.

Recommendation: Design for scannability

When Steve Krug talks about users scanning rather than reading web pages, the same holds true for resumes.  When I read resumes, I usually only give it maybe 30 seconds of my time during the first round, scanning for phrases that pop out, looking not only at the specific content but also at how content is organized. In line with that, these are some of my recommendations when it comes to designing (not just writing) resumes that pop.

  • Put a summary at the top: This is particularly critical if you’ve got a multi-page resume.  What would you tell your reader if you instead met them in an elevator and had less than a minute to summarize your skills?  This is what needs to go right at the top.
  • Make headings meaningful and easy to scan: Try just reading the headings in your resume.  Do they include your job title?  Do they crisply communicate what you’ve been up to for the last several years?
  • Keep job description summaries short: Assume that the reader will only look at the first two bullets, maybe only the first bullet.  Never have more than four.
  • Make sure your resume breathes: Don’t use type that is too small and don’t be afraid to make good use of white space.

Finally: Think about the story of the documents you are submitting

I don’t know how many times I’ve received a folder containing a bunch of files, such as wireframes or specification samples or whatever, without any kind of instructions or supporting descriptions of what I am looking at and how I should be looking at them. Imagine how an end user would react to being presented with web content in this way.  At the very least, you should always include a document that introduces the artifacts you are submitting.  My recommendation, however, is to go one step further and to actually produce a single document in which you collect the various artifacts you are presenting, and include an overall introduction to the documents (perhaps describing when and how they were created), and then introduce each artifact, preferably with callouts highlighting key elements of interest in the artifact.

There are of course many more recommendations I could make about the UX of resumes and work samples, but hopefully these will be useful to someone who currently is in the process of applying for a job.

The Problem with Todo lists (the digital ones)

Let’s imagine for a moment that you’re some seniorish UX design person and I’m your client and I ask you to design for me a truly durable and useful todo list.

I can imagine a variety of reactions to this request. One might be “Why in the world do you need me to design a todo list when there are like a gazillion todo lists already out there?” Another might be a shrugging of the shoulders, thinking I’m giving you a chance to make some easy money to design yet another todo list. But if you’ve really been around the design block a few times, you’d know better than to assume that a seemingly simple request coming from a client really is that simple. (In my experience, that is rarely, if ever, the case.)

So, you dutifully inquire further as to what my specific needs are relating to a todo list, i.e. when and where I’d be using it, what type of todo items I’d be entering, how I’m currently managing my todo items and so forth. Here is one of my responses:

I’ve used all kinds of todo list software, from the new Gmail Tasks, to 37 Signal’s Tada Lists, to just typing stuff into notepad or Google docs. Many of these pieces of software are very simple and elegant and user-friendly, but, even so, what always happens is that I use it for a while, eagerly typing in everything I need to do, but then I stop using it after maybe a week or two, sometimes less, usually because it’s just too much of a hassle to have to type stuff into these lists. So I end up with todo items scattered all over the place.

Whoa, wait a second here. Maybe this todo list thing isn’t that simple after all. Taking an Alan Cooperish what-if-software-was-magical approach, you ask me what my ideal dream todo list might look like, setting aside any technical or logistical constraints.

For me, the issue is primarily with the hassle of having to enter items, of having to get in front of a keyboard and fire up some application when I think of something important, especially when I simply can’t or don’t have the time, maybe I’m riding my bike, in the shower, in the midst of a conversation with someone, don’t have internet access, whatever. So I end up not entering it, which of course negates the whole point of a todo list. So, in terms of my dream todo list, and this will sound a bit weird, I think it would have to be one which it basically reads my mind or something and when I think of something I need to do, it would add it to my todo list in the cloud, as in some kind of universally accessible list of stuff to do.

The other big issue is having to deal with categorizing and prioritizing todo items. While I’d like for them to be organized nicely, I don’t want to deal with having to come up with categories not to speak of having to do the categorizing. So it would need to be able to somehow figure out how to group my todo items in a sensible way, such as work-related and personal todo items. And as far as priorities go, I’d obviously want higher priority items to be more prominent, but the problem is that the priority of a todo list item changes for me depending on context and other factors. For example, if I am at the office, even though I absolutely have to remember to pick up a bottle of wine on my way to the dinner party this evening, I don’t want that todo item cluttering my list of office todo items. But if I maybe head out for lunch, then I’d want to see it, since my priorities and my context then has changed. Yeah, that would pretty much be the ideal dream todo list.

Ok, so on one hand this is a dream todo list app, but let’s look at what this imaginary software tells us about current todo lists and design in general.

The more contexts your design needs to support, the more complex it will be to design
A todo list is reflective of how the software we design is increasingly intertwined with people’s lives. As such, a todo list that a real person really can use in their day-to-day activity needs to work in all kinds of contexts. Compare this to a todo list that strictly is for work-related items: in that case, I can maybe assume that the user will always be in front of computer and as such as traditional todo list might work. But even that falls apart, since I may also be on the road, in a meeting with a client at a coffee shop, in front of a whiteboard.

Categorization is a Catch-22 Conundrum
On the one hand, users like for stuff to be organized in a way that makes sense to them. At the same time, they are unlikely to want to have to deal with coming up with categories or with the hassle of categorizing. While creating some generic todo list categories (e.g. work, personal, buy, etc.) is probably doable, user would still have to actually place stuff in those categories, which adds yet another obstacle, another micro-activity that will make the act of entering a todo list item less palatable.

Priorities are contextual
There are lots of things we think of as important, but only some of things are important in a given context. This means that we can either have multiple todo lists for different contexts, which means a lot of busy work, which means we are likely to stop using the todo list. Alternately, we could use category-specific indicators, such as high priority work, or high priority personal, but again, we are then back to the problem of too much hassle to deal with when enter a todo list item.

Sometimes there really is no great solution within the digital domain
With today’s mainstream technology, it is not possible to design a durable and truly useful todo list. Please prove me wrong on this.

Instead, this is the todo list solution that I always find myself returning to:

Using an old envelope as a todo list

Yup, the back of an old envelope. Why is this tattered looking thing better than any of the todo list software out there?

It’s highly portable
For the very reason that it’s just an old used envelope, I can crumple it up and stick it in my pocket. If I spill coffee on it or it gets a little torn or whatever, who cares?

It’s always immediately accessible
No booting up an iphone app or, yikes, a laptop, just to enter a lousy todo item. No battery life or connectivity issues to think about.

It constrains me to a reasonable amount of todo items
One of the biggest problems with most current todo lists is that they, in a knee-jerk nod to the idea that infinite scalability is a good thing, don’t impose a limit on how many todo items I have on my plate at any one time. But a list of hundreds of todo items, I think, is pretty useless, as I am only going to be able to do a few of the items within the near term. So, the size of the envelope constrains me to a reasonable amount that usually matches what I can complete in a day.

It allows for ad-hoc prioritization and categorization
Since I can write anywhere on the envelope, I can add little stars or underlines or write in all caps or whatever to show that something is important.

But, of course, using the back of an envelope for a todo list has all kinds of drawbacks, which leads to another UX lesson:

Design is not about finding the ideal solution; it’s about finding the ideal compromise
Obviously, using the back of an envelope or a piece of paper has all kinds of drawbacks, from that you have to manually transfer todo items that weren’t completed to a new piece of paper, or that you could easily misplace it, or that all your scribblings could quickly turn into a big jumbled mess. But weighing all those drawbacks against the strengths of the solution, I still kep find myself returning to this method after temporarily trying some new software-based todo list.

Is it just me or are others having similar experiences, finding digital todo lists just not workable in the long term?