Dan Benjamin has a really neat interview with Swiss designer Tina Roth Eisenberg in which she briefly touches upon how Swiss people are virtually engulfed in minimalist design, and how our money is really beautiful.

A few months back, I wrote about H.264. Back then, I said:

Chances are that I will have to remove all of my H.264 files in 2015. Given these terms, for my own websites, I don’t feel that H.264 is still a feasible option for embedding video content.

This problem has now been resolved. BusinessWire has just published a press release from MPEG LA:

MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users during the entire life of this License.

This is great news.

User Testing for Games

When I talk to developers and designers about user testing, they sometimes tell me that it’s okay to make applications hard to use, because games are hard to use. The logic goes something like this: Games are hard, but people like games. We can make people like our apps by making them more like games. Hence, it’s okay to make apps hard to use, because that makes them more like games.

In reality, modern games are typically not hard. They’re designed to feel hard, to give the player the impression of having overcome incredible odds, of being powerful, of being able to face mighty enemies and dangerous situations. But at the same time, a lot of user testing goes into making sure that the player never really gets stuck or dies too often, but is always able to make steady progress through the game. The impression that games are hard is (for most games) an intentionally crafted illusion.

Here’s what Bruce Oberg, co-owner of inFamous developer Sucker Punch, has to say about it:¹

We want people to make progress at a steady pace, we don’t want them to die all the time. If we have a recording of where everyone died, and we see that everyone’s dying in one spot, maybe we need to change that spot, maybe there’s a bad guy who can shoot at you unfairly.

(…)

Basically, we want everyone to be able to have a good time playing the game, whether you’re high-skilled or low-skilled. We want everyone to be able to make progress and have fun.

Jump to around 2:50 to hear him talk about user testing:

The idea that it’s okay to make apps hard to use because games are hard is a fallacy. Most modern games are not hard, and game developers use the same usability tools as developers of regular applications to ensure that they are not.

Opinions vs. Data

Gmail’s recent update brought us a strange new UI element:¹

Clicking on the checkbox selects all emails. The arrow, on the other hand, allows you to make more specific selections:

This is a pretty unusual UI element. Gmail may be the only application using anything like it. This has caused a lot of people to question its usability. Gmail lead UI designer Michael Leggett eventually chimed in, writing:

[The new widget] is odd. And yet, both the checkbox and the menu part tested very well in the lab. The people who hated the widget outside the lab also understood how to use it but promised others wouldn’t because it was so «weird.» There were some optimizations I wanted that didn’t make it in (highlight the current selection state in the menu, show keyboard shortcuts, etc). But it tested fine without those things.

What Leggett described is exactly how I felt about the widget when I first saw it. I immediately figured out how to use it, but my gut reaction was «most people are not going to get how this works.» It seems I was wrong. This is one of the reasons why I don’t put too much trust into opinion-based usability reviews: There’s a lot of guesswork involved, and guessing how humans behave is an endeavor fraught with peril.² Expert reviews can be helpful, but they are no substitute for actual testing.

Jakob Nielsen has written about this:

In my two examples, the probability of making the right design decision was vastly improved when given the tiniest amount of empirical data.

If there’s one thing we should all take to heart, it’s that humans are strange: They rarely behave the way we expect (or want) them to. Testing often reveals issues we would never have found out by merely thinking about a design. Conversely, something that looks wrong might actually work perfectly well.

Matt Gemmell has come up with a funny multitouch-based replacement for tool palettes:

Hard to tell how well this would work for actual users. It’s not immediately obvious how to initiate or use this system, but it might be quite easy to learn and remember. At any rate, it’s food for thought.

Haptic feedback based on electrical charges applied to a thin film inside a touch panel:

I’ve generally been unimpressed by haptic feedback that uses vibration. This, on the other hand, might actually succeed in making devices more usable.

(Found via Madhava Enros)

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.