Tagged in: design

Review: The Design of Everyday Things by Don Norman

Book: The Design of Everyday Things
Author: Don Norman
Year: 1988. There’s a revised and expanded edition for 2013 that I recommend over the original if you have access to it, but this review is for the original text.

Design of Everyday Things Cover

Summary: A must read for anyone who designs things – whether they are objects or games – for people to use. Very readable and no prior experience necessary.

It almost feels silly to review The Design of Everyday Things considering its reputation. I think most game developers that are somewhat serious about reading about their craft already have a copy. It’s certainly the one book that I find game designers recommend the most when asking about a book to read – despite not being about game design.

The Design of Everyday Things is a foundational text on usability and user centered design. It looks at everyday objects – telephones, doors, watches, radios, cars, teapots, remotes – and presents examples of good and poor design. The author delivers important lessons on how to design with users in mind to make their experience of using that object smooth by contrasting them with pages and pages of anecdotes of objects that frustrate and confuse its users. If you get nothing else from the book, you will at least gain a sense of horror about how poorly the world around us is designed.

If you’ve ever fumbled with a door, pushing when you should have pulled or vice versa, or pushing on the hinge instead of where the door swings, or pushing when you were supposed to slide it… then you will find the anecdotes in the book cathartic to read. And while the anecdotes are the easiest thing to recall, each are paired with concepts from usability: affordance, constraints, memory, feedback (a concept all gamedevs should be familiar with!), and so on.

There’s two sections of the book I want to call out as being particularly informative for me. The first is the stress on human error as an inevitable thing, as all humans will eventually error no matter how well a system is designed or how much experience they have with it. A designer’s role, then, should be to design controls to eliminate error as much as possible (for example, a water tap that you could never turn hot enough to scald yourself). When that’s not possible, you should design it so the error is reversible or limits damage as much as possible (for example, the recycling bin application on your computer, or autosave features). Of course, applying this to games, think about elements where it’s easy for players to make mistakes, like at an RPG vendor, and methods games have implemented to limit user error, such as the ability to buyback items you recently sold in WoW. Norman points out that in these situations just a confirmation prompt alone is not enough to prevent human error: if the error is still possible, you should design safeguards for that event.

The other section I found particularly enlightening focused on human memory. The author splits up memory between memory in the head (our minds), memory in the world (cues, post-its, event calendars, reminders, instructions), and memory associated with cultural standards (how to drive a car doesn’t change much between cars, so you only need to learn it once). There are flaws with relying on any given type of memory for users of your design, so the author advocates whenever possible to design so that those users do not need to use their memory – the design is intuitive as is. Recall switching between different games and trying to remember what controls go with what move. Luckily, there are standards that most games follow – left analog stick controls camera, right stick controls movement. But I’m sure most people remember playing a game where the controls seemed to break the rules and you had a lot of trouble not throwing a grenade at your feet (*cough* Call of Duty *cough*).

A lot of the content in this book crosses over into other books I’ve read regarding design. A whole section on how the brain works, with a focus on patterns, may remind you of Koster’s similar emphasis on patterns in A Theory of Fun for Game Design. I’d say a good portion of the principles in Universal Principles of Design are cribbed from this book – constraints, accessibility, chunking, affordance, and so on. Since this is such an important book, you’re likely familiar with some of its concepts already.

There’s two editions of the book out. I read the copy from 1988 and found it was fine, but if you were born in the 90s or later (and don’t remember what it was like to reprogram a VCR or use call-waiting system or a mechanical projector) I recommend picking up the newer one. It replaces a lot of the examples with more contemporary ones and I hear it’s still worth rereading if you’re only experience is with the original.

In case it’s not clear yet, I highly recommend the book for everyone. Its lessons are timeless, even if it’s examples aren’t. It’s written in an easy, approachable manner that makes it suitable for anyone interested in the topic, whether they are experts or hobbyists or students.

Review: Universal Principles of Design by William Lidwell, Kritina Holden, and Jill Butcher

Book: Universal Principles of Design
Author: William Lidwell, Kritina Holden, and Jill Butler, designers
Year: 2010 for the enhanced version, which I review here, but the original edition is from 2003

Summary: Alphabetical, illustrated overview of many design rules, spanning fields from architecture, product design, web design, user experience, and so on. Highly recommended as an easy reference text for anyone who cares about usability and design of objects.

100PrinciplesOfDesignUniversal Principles of Design has come highly recommended to me from people of various departments, but seems to have a special place among UI and UX designers – and for good reason. This book attempts to survey major principles from every field of design and package them in a neat, inviting, and (dare I say it?) well designed book. Universal Principles of Design is not about games, but the lessons within often intersect and overlap with situations and problems familiar to game designers.

The book is 263 large, glossy pages long. Each principle of design takes up a pair of pages: on the left the principle is identified, defined, and explained in easy English, with references to studies and recommendations for further reading. On the right hand side the authors use a variety of annotated visuals (graphs, diagrams, photos) to illustrate the principle in practice. This means that you can open up the book to any page and immediately get a comprehensive and clear overview of that page’s principle. It’s easy to digest without being too simple or brief.

The topics are arranged alphabetically, which means that as you read one principle may have very little to do with the next, though all fall into the broader category of “design”. Some principles are very relevant to game design – like Performance Load (“the greater the effort to accomplish a task, the less likely the task will be accomplished successfully”) or Five Hat Racks (“there are five ways to organize information: category, time, location, alphabet, and continuum”). Others are interesting as novelties but won’t make me a better designer – like the principle of Most Average Facial Appearance Effect (“a tendency to prefer faces in which the eyes, nose, lips, and other features are close to the average of a population”).

If you’ve read much on usability and user experience design, then a lot of these principles will tread familiar ground. Many of the principles that didn’t get much mileage for me as a designer were related to visual design, advertising, and product design, or repeating axioms like prototyping and iteration that most designers have already internalized. The large number of principles covering architecture and environment design makes the book particularly relevant for level designers.

The only caveat I have is that Universal Principles of Design don’t seem to be all that universal. Several of them actually focus on western culture bias without acknowledging it. For a simple example, the Gutenberg Diagram principle describes how eyes move across a page of information, and describes this as from left to right. But this principle is reversed or otherwise flipped in languages that are read from right to left or other directions. I have similar misgivings about other principles that make claims about how we associate empty space with expensive products, or the color red with attractive women and strong men. Meanwhile, others had to point out to me that the principle of Hunter-Nurturer Fixations regarding gender role behavior is flawed because it relies largely on a debunked study to prove its merit.

Those aside, I do recommend the book. I don’t think people should take a principle from its pages and treat it as the complete truth, but as guidelines they appear really solid. I think the topic is general enough (all design fields) that the book has a lot to offer anyone, regardless of whether they know nothing about game design or have many years of experience. However! This is not a game design book, so your mileage will greatly vary depending on your own interests and needs. If, like me, you’re looking for a game design specific book set up in a similar way, Universal Principles of Game Design by Wendy Despain appears to follow a similar format (but I abstain from saying if it’s good until after I read it).

GDC 2015 Talks on Design in Sunset Overdrive

My blog’s been silent for a little while because I’ve been really busy with preparing for GDC. This was the first year that I’ve spoken at the event and gave not one but two talks on design in Sunset Overdrive.

Since I’ve now given both my talks, I’m going to share my slides and – since there are no notes on the slides – my talking points.  Keep in mind that these notes are rough drafts and since I practice and memorize my talks they eventually fall out of date to the actual presentation. Regardless, my talks should be pretty easy to follow without the video if you consult the slides and notes together, but I expect them both to be on the GDCVault eventually.

Level Design in a Day: The Worlds of Sunset Overdrive

This is a 25 minute talk that covers the first two cities we built before we made our final city, and talks about what happened with those cities that made us decide to throw them out and start over again. I focus on how the changing design of the game – the emphasis on traversal, the open world vs. linear spaces – led to major changes in the geometry.

Transitioning from Linear to Open World Design with Sunset Overdrive

This is an hour long talk that goes into Insomniac’s changes in the design department to adapt to the new needs of an open world game, but also the specific needs of a game like Sunset Overdrive. I talk about the structural differences between a linear and an open world game, how designer roles and responsibilities changed, what our new workflow looked like, and the pros and cons of those changes. Whenever possible, I compare and contrast development on Sunset Overdrive with development on Resistance 3.

Mini Post Mortem

So I mentioned before that this was the first year I had ever given a GDC talk, so maybe some of my experiences might help others thinking about giving their first talk. I made it a goal the year before to pitch a talk, but the day proposals were due I still had no idea what to write about.  So I recruited Lisa Brown (@Wertle) for an emergency lunch session, and somehow dragged Drew Murray (@PlaidKnuckles) into the conversation at one point. By the end I realized that I had a lot to talk about with how things changed at work for designers as we moved into open world development.

(My advice for others who want to give a GDC talk and don’t know what to talk about? Recruit others. It’s hard to know what you know without others pointing it out.)

So I wrote a pitch for my talk on transitioning from linear to open world design, sent it in, and the GDC advisory board approved it. I had some emails back and forth with my advisor, Clint Hocking, who gave me some really excellent feedback and asked if I’d be interested in also participating in the Level Design in a Day summit. If I had to do it over again I might not have agreed to two talks – at least not for my first GDC. It was a bit overwhelming, especially since I went off travelling for a bulk of that preparation time.

There are some things I learned after the fact. Like, did you guys know there’s a “presentation mode” for slideshows that actually displays your current and next slides AND your notes? I didn’t. I never used it. I didn’t have any notes to read off of for my talks – it was entirely a mix of ad-lib and memorization. I also learned to ignore people who say that you’ll talk faster at a podium: as friends pointed out, I am already a fast talker. My practice times and my actual presentation times were the same, so my Level Design in a Day talk ended up cut off short (and I quietly snipped a few bits from my longer talk the next day to get in on time).

Some other things I learned:

  • Most people use something called “Presenter Mode” that shows them their notes and the previews the next slide and… I didn’t know this. I just memorized everything. I did it the hard way, apparently.
  • I was warned the speaker’s party would be terribly lame but instead it was just perfect
  • 25 minutes is too short to go really in depth, and not short enough for a distillation of a single idea. Go 60 minutes or join a 10 minute microtalk.
  • I get more nervous speaking to smaller groups, but the large GDC crowds didn’t intimidate me at all when it came time to speak.
  • There’s a LOT of studios that shall go unnamed that found my presentation on moving from linear to open world incredibly relevant.

That last bit was really important to me – I didn’t want the crowd to feel like I was wasting their time. I’ve been to too many GDC talks that I really didn’t enjoy because I didn’t find them relevant, or they were too basic and didn’t dive deeply enough into a topic.

One side effect of doing a GDC talk is that I learned a ton during the preparation stage. I had to focus deeply on a topic and dredge up everything I knew, research what I didn’t know, and then determine what parts make the ‘cut’ into the presentation and which don’t. I had a lot of doubt about the content of my talks since I was (unfairly) concerned about being wrong and not having the time to get more team members to proofread my talks. But then, Drew Murray, our creative director, may or may not have said, “Look, we’re all just making shit up” and he’s one of the best presenters I know.

Hopefully my evaluations come in positively because I already have a topic in mind that I’d love to speak on next year.