Street Slide

Clever way of navigating through street pictures from Microsoft Research:

Via Tested.

Tab management is probably something that should be handled by the OS, but as long as no OS takes care of it, this is an awesome implementation of the concept.

Chris Clark writes:

I just wish Aza Raskin were doing this work for an OS vendor instead.

Jon Bell

As part of an ongoing series of interviews with designers, I’ve talked to Jon Bell about his design process. Jon Bell worked as a developer for ten years before shifting his focus towards design. He currently works as an interaction designer for frog design. He writes a blog about design called design dare. You can find out more about him at lot23.com.

Lukas: Tell me about your design process. Where do you start, and what kinds of techniques do you use at which stage of the process?

Jon: I’ve wanted to be a professional interaction designer since attending art school in the 90’s, but I kept getting hired as a developer. I did a lot of freelance design on the side, and was always the front-end specialist on my dev teams, but it’s taken until recently to have the word «designer» on my business card. (At frog, no less! Hurray!)

Picture (CC) Randy Stewart

As a result, I’m not sure what my process is yet. I’m absorbing all the great ideas around me, watching my co-workers carefully, trying to stay healthy and positive, and letting my designs organically develop through whatever approach intuitively feels right at the moment. It’s messy but I’m having a lot of fun.

When you start on a new project, what exactly do you do? I imagine that you often have a pretty good idea of who the intended audience is when you’re working for frog, so do you start with user research?

Frog has a great three-part approach: Discover, Design, and Deliver. In the discovery phase, we do heavy design research. Lately I’ve been doing a lot of contextual inquiry, which means going to a customer’s office (or home, or whatever you’re designing for) and getting a sense of what they do every day. I find it’s an exercise in studied ignorance as I try really hard not to bias the data with my own opinions.

Once we get our data, synthesis is a lot of fun. I like to post pictures of everyone we talked to on the walls (my team has interviewed 67 people in 2010 alone!), with sticky notes that highlight significant themes. Then it’s all about tons of discussion and sketching, with a blend of alone time and group brainstorms, all under the gaze of our client’s customer photos to keep us focused.

We make near-comical use of sticky notes. They’re everywhere, grouped into topics, stuck to our co-worker while he’s practicing a presentation, stuck to the image of a customer who had a particularly resonant quote, and so on.

The backdrop for all this customer-specific data and resulting discussion is the rich domain expertise that frog has. We often see emails go by that say things like «Does anyone have experience with living in Africa?» or «Does anyone have a Palm pre I can try out?» Combine our research skills with the combined experience of all frogs and it’s hard to go wrong.

So that’s the discovery phase. I guess once this starts to settle down, you move towards sketching, storyboards, and maybe prototyping? How do you do that, and how do you use your research to inform your designs?

At the end of discovery, we present our findings and our recommendations to the client, and that leads into my favorite part of the process.

We have a bunch of activities designed to rank ideas, suss out details frog might not know about, be as collaborative as possible. It’s not just about the official sessions, either. It’s about lunch, dinner, going to the bar afterwards, trading war stories, adding each other on Facebook, debating the end of Up In the Air, and so on.

It’s an intense time of collaboration, and by the end of it, everyone usually respects and understands everyone else’s point of view. This part is crucial, because we’re never going to agree on everything, but if there’s a framework of respect, we can get through any issue.

(In freelance, I approach things the same, but at a much smaller scale :)

Then we return home and try threading the necklace: we have a handful of recommendations that everyone is in agreement on, so we just need to thread them into a viable product and story using flows, storyboards, and wireframes.

There’s some debate about what’s best at this point - do you go for the «rabbit out of the hat» moment, by not showing the client anything until the next presentation, or do you show incremental progress which reduces risk but also takes some of the emotional punch out of the final presentation and opens you up to last minute changes?

Picture (CC) Ronald Woan

I like to stay in close contact with the client. I like thinking that we’ve all heard the same things in the contextual inquiries, we all coalesced around the important features together in during the deep collaboration, and as the fidelity goes from napkin sketches to grow into whatever their final form will take, the client always feels involved and appreciated throughout the process.

Once the fidelity of your design starts to go up, do you test with actual users?

Not enough. When a client is nearing the end of the process, I think they’re just itchy to get the work out the door. (my current client is interested, though, so kudos to them!) I still try to scrape together as much data as I can, but its never as systematic or solid as the early user information gathering.

I’ve used Silverback to great effect, but their motto, «guerrilla usability testing» really sums it up. It’s been surprisingly hard for me to justify user testing later in the process, despite how important I think it is. This applies to frog work, freelance jobs, and even my own projects, where I get to play the role of «guy who thinks late-stage testing is too much of a hassle». That guy sucks.

It sounds like you’re trying out a lot of different techniques and approaches in your design process. Are there things you’ve tried that didn’t work out, or didn’t produce the results you expected?

For a lot of things, especially since I haven’t done this professionally for long, it feels more like steering a car. As I go off track, (and it happens a lot) I just adjust slightly for the next time. But two things jump out as obvious mistakes. They’re less tactical and more strategy blunders.

First, I need to stay motivated, which means setting small goals that I can achieve, which inspires me to tackle the next thing. I’m involved with a few projects right now (two are a personal projects, the other is part of a group) that feel stalled because they don’t have a modest enough goal for version 1. So it’s hard to keep them going, and I hate feeling like a great project is dying for no other reason than over-reach. Making everything your opus is a stupid but common mistake.

Second, being grumpy, unhealthy, and stubborn worked pretty well for me as a developer, but I can’t do it with creative design work. This means I have to eat better, exercise, go to bed really early, constantly remind myself how great things are, and expose myself to designs, people, and points of view I might not have bothered with before.

When I don’t, it shows much faster with much worse results than when I used to stay up all night banging out code and/or yelling at jerks on the internet. It took me a whole career change to fully appreciate it, but a positive attitude is vital for creating great work.

Words we should all live by. Well, thanks for talking to me, Jon!

To find out more about Jon Bell, go to lot23.com or designdare.com, or feel free to email him about anything you’d like more details about.

Max Steenbergen

As part of an ongoing series of interviews with designers, I’ve talked to Max Steenbergen about his design process. Max Steenbergen is a graphic and UI designer working for a company that makes, of all things, automation and monitoring equipment for yachts. He writes a blog on user interface design at rock85.tumblr.com. After stumbling into the field, teaching himself as he went along, he fell in love with the trade, and is about to start a four year training in Communication and Multimedia Design. His Twitter handle is @maxsteenbergen.

Lukas: Tell me about your design process. Where do you start, and what kinds of techniques do you use at which stage of the process?

Max: When I get a request to design a new front-end for a client, the first thing I do is try and get as much info as possible. Requirements, expectations, which information is all-important and what is complementary? Using that intel, I try to find out just exactly what the front-end is really meant to show.

Once I know the real goal, I usually grab paper and pencil and start sketching. By finding out what information is more important in the first stage, I know which elements of the front-end I have to give more prominence. The front-ends consist of a load of buttons, text fields, dials and other controls—all of varying sizes and aspect ratios—so fitting it all together is a bit of a puzzle. By sketching on paper first I can identify problems (like too little space to fit all elements) beforehand.

I should clarify that, while we do have one application in which we show everything, this application is really more a sort of framework. This framework defines and renders the graphics on screen. However, every yacht has different systems and needs, so each install features unique front-ends.

Depending on the nature of the front-end, which can wildly vary, I have to figure out what kind of grouping would work best. Let’s say there are ten elements on the front-end, each with their own on/off button. Do I place all ten buttons in one group, or do I place each button next to its element? For example, do I sacrifice aligning to the grid for showing relationships better?

Most of the time I choose to group elements by type, as this makes it easier to remember the location of specific elements.

Tell me more about how you gather requirements. How do you interview your clients for that?

Most communication is by e-mail. Our clients are all over the world, and it would just be too damn expensive to have me grab a plane every time. I’d prefer to go on-site, but often the entire project is still «virtual»; not a single screw or bolt of the final yacht actually exists yet.

During the preliminary phases I ask some specific questions to find out just exactly what the client wants to achieve with the front-end. This is different from asking what they want to see, as the answer to that question is always either «everything» or «as much as possible».

Those answers, when placed in context with the multiple varying front-ends, allow me to work out the goal for that specific screen. Often the result of my sketches based on those answers differs quite a bit from how the client had imagined it, but usually in a positive way.

Yeah, given your domain knowledge, I guess you typically have a better idea of what your clients actually want than they do. If your design differs from what your clients expect, do you find it easy to convince them of your solution? Do you involve them in the design process, for example by getting feedback on sketches?

Well, given the amounts of money our clients spend on building yachts, they usually require (and give) constant feedback.

And they have every right to. So yes, after every milestone in my design-process, I mail some screenshots to the client for approval and comments.

Sometimes they make comments like «But in reality that element makes a turn to the right, instead of going straight on like you’ve drawn». In such cases I explain to them that simplifying such things makes the entire screen friendlier to the eye, while still being correct: i.e. Element A is still connected to Element B. I just eliminate the twists and curves that are unnecessary in a schematic.

Same goes for values that I omit altogether. Sometimes the brief states they want wildly different values (that are usually already present in a different screen) in a screen that has nothing to do with those values.

I think it kind of comes down to a fear of white-space. The general opinion seems to be that, roughly speaking, every single pixel needs to show information. Any free space needs to be filled. I try to explain that whitespace is equally important as filled space.

A few months back one of my colleagues sketched and agreed with the client on a screen design without my knowledge. Suffice it to say, not a single pixel was left unused. The amount of data I usually use three screens for was crammed into one. But, the client agreed on the sketch and had signed (read: paid) for it, so there was nothing I could do. I just had to make the sketch reality. Luckily, the client was equally disgusted by the final result as I was, and I got to re-do it.

It sounds like since you’re using a framework to define and render the user interface, you can move from sketching to actual implementation pretty quickly, and it’s easy to go back and fundamentally change things, even late in the process? This kind of system probably changes the economics of redesigning things quite a bit.

Implementing the sketches into the framework is not that big of a deal, correct. Using our own framework, creating new front-ends is as easy as dragging elements to the canvas and aligning and resizing them. Editing a front-end is equally easy, as it’s again the same drag-and-resize routine. I don’t have to code every single element with their dimensions and all that jazz in some fancy programming language. Our WYSIWYG-based framework is all I need to create and edit the front-ends. All I have to do is translate the elements I sketched to their digital counterparts with roughly the same dimensions and be done with it.

So yes, changing things in the front-end, no matter where in the process, is not hard at all (though it’s not to be taken lightly either). But that’s just for my part of the project. Some of my colleagues charged with the technical side of things are somewhat less happy with last-minute changes.

Once you’re happy with a design, how do you present it to your customers?

When I’m done with designing and implementing the front-ends, I give all files to one of my colleagues. He then makes the back-end of our system connect to the front-end.

This is the same guy who visits the client when all stuff (including the PCs with my front-end) is delivered. The UI is only a small part of our scope, the largest part of our work is making all hardware stuff work together. So it would make little sense to send a designer to deliver high-end technical systems. I do always ask my colleague how the front-end was received by the client.

Would I like to see it different? Sure, I’d love to spend a week or so on board a yacht to see how its crew would work with the system and perform some true usability tests. All I can do now is hypothesize from behind my desk and hope I got it right.

Let’s change gears a bit and talk about stuff that doesn’t work. Are there things you’ve tried to incorporate into your design process that didn’t work out the way you expected, or didn’t help the process?

When I just started designing user interfaces, I simply went straight to the final medium without so much as sketching or thinking things through. That went fine with the smaller projects we were doing at the time, but as the projects grew bigger, this approach eventually started to backfire. That’s when I started sketching and all that comes with it. Now I always make a sketch, no matter how big or small the project.

Unfortunately the bigger the project, the more people there are who think they have a say in the UI design.

That’s a situation that probably sounds familiar to a lot of designers. Well, thank you very much for talking to me, Max! I appreciate you taking the time to answer my questions.

To find out more about Max Steenbergen, follow him on Twitter.

The e-book version of Josh Clark’s new book «Tapworthy» is available for $9.99 on O’Reilly today (if you’re reading this only now, you missed it). The book is ostensibly about designing iPhone apps, but honestly, judging by the apps on my iPhone and Android devices, I think the people who should really read it are mostly Android developers. The book is full of all the tiny things you really need to pay attention to when designing apps for mobile devices with small screens, so if that describes what you do, go pick it up.

Disclaimer: I received a free copy of the book, which may have influenced my opinion of it. But I’m pretty sure I would have loved it either way.

Kindle DX Graphite

Amazon has announced a brand new Kindle DX. It sports a graphite colored case:

Some people have wondered why Amazon has changed the Kindle’s color. While I do not know their true reasons, I do suspect that the new color improves the device’s readability. I tend to mainly use my Kindle when I’m reading in bright sunlight. The Kindle’s current white case reflects much more light than its somewhat darker screen. At times, the contrast between the case and the screen is almost painful, and makes it harder to read on the Kindle:

The graphite case should fix this problem.

It’s all about the user kicking ass. (…) People are not into your tool, they are into what the tool enables.

Kathy Sierra at Business of Software 2009. You should set aside an hour and watch the whole talk.

Don Norman on Emotions and Complexity

Here’s an interesting video of Don Norman speaking at the Business of Software conference in 2009:

Sometimes, I wonder whether Don Norman is playing a huge practical joke on the usability community, with his more recent ideas on things like complexity, and usability. He makes some great points in this talk, but he also makes a number of rather peculiar arguments.

For example, at the very beginning of the video, he claims that usability won’t affect the sales of a product, because people profit from usability only after they have already bought a device. But this completely ignores the fact that people recommend products they like to other people. Devices like the Wii, the iPad, or the iPhone are viral; people become interested in buying them after playing with a friend’s device, and after seeing how much their friends enjoy using their devices.

Creating a Mess

Later in his speech, he talks about advantages of complex products. He makes the point that complexity is sometimes a necessary attribute of a product. I agree with this point, but I think he’s overstating the case; some of the examples he uses are a bit odd. One of these examples is Al Gore’s office:

However, Al Gore’s office does not illustrate Norman’s point. Al Gore’s office does not look like this because he uses a complex product. Instead, he uses simple things (like pieces of paper) to create a complex structure (otherwise known as a mess). Letting your users create complex structures and arrangements is an entirely different idea from creating products that are complex on their own.

In other words, your users’ messes make perfect sense to your users. Your mess, on the other hand, makes absolutely no sense to them. Complexity is easily understood by the person who created the complexity, but often not by anyone else. I understand the mess on my desk, but not the mess on yours. The fact that people create complex structures does not mean that they will be happy with complex products, because it’s not their mess; it’s somebody else’s mess.

Art

Norman also uses a weirdly complex coffee machine as an example of how complexity can make a product more fun. It’s true that this is a complex product, and it’s also true that this looks like a fun product, but is it really something we should emulate?

Such devices may be «fun» in a slightly abstract sense,¹ but does anyone actually use these things to make coffee?² I certainly don’t know anyone who uses such Rube Goldberg-esque devices. They’re fun objects in the same way that a sculptural machine by Jean Tinguely is a fun object, but they are not fun to use on a regular basis.

They are works of art, and not intended as functional devices.

We like to look at them, and maybe play with them once in a while, but we don’t want to use them regularly.³ We don’t use them when we need to get stuff done. To me, this example actually reinforces the idea that «fun» should not be the primary goal when we are trying to create functional products; functional should be the primary goal. People experience fun naturally when they use a product that makes them feel in control—in other words, a usable product.

Do we really want to create the equivalent of a device that nobody truly uses, a device that is essentially a piece of art, rather than a product that people will use when they need to get things done?

Norman’s main point is that emotions are the most important factor influencing how people behave. I agree. But emotions don’t exist in a vacuum. Emotions are a product of something else. Very often, positive emotions are a result of a great user experience. And a great experience, in turn, is (not exclusively, but in large parts) the result of a product that is easy to use.

Why Tabs Are on Top in Firefox 4

Alex Faaborg explains why tabs are moving to the top of the window in Firefox 4:

I’ve written about similar ideas in my article on hierarchies.

On Canonical’s design blog, Matthew Paul Thomas writes:

Ubuntu is phasing out the notification area (a.k.a. “system tray”), because of its ineffectiveness at notifying people of things, and its inconsistent behavior.

It’s probably a good call. I think the source of the problem is that, as it gets used by more and more applications, any notification system will eventually become overwhelmed with unimportant notifications. This causes people to become blind to the whole system.