Yuda asks, "is there a general process for solving a UX problem?" I talk about broad frameworks to use when approaching any UX design problem and how you can tweak them to suit the problems you work on.
Viewing entries in
You're a graphic designer, or an lllustrator, or a web front-end developer. But you love games, and you love UX design. How do you move from the former to the latter? I talk about practical ways to do that.
What do you do when you're a complete newb at UX design and you find yourself completely in charge of the user experience for the game your company is making? Fake it 'til you make it, right? Well...not really. Let's talk about practical ways you can bootstrap your way up out of the dark.
I get UX questions. A lot of UX questions. So how about a little regular Q&A so that everyone can benefit from the answers?
I've been using Medium as my blogging tool of choice lately. It's pretty, it's slim and streamlined, and I enjoy its UX. Here's a collection of the recent articles I've published there.
Don't be Afraid of a Pencil - Here I discuss the concept of sketching as communication, and that drawing skills aren't required to sketch. And that you should be sketching.
UI: It's Not the Tool - Too many people think that making great UI means digging into Balsamiq Mockups or other wireframing tools. But UI goes beyond tools.
The Right Fidelity for the Job - Wireframes are only one part of the UX design process. Don't work at high fidelity when you're just trying to sort out early problems.
What Are Your Project's Design Pillars? - Every project has their foundational design principles, and every bit of design should always speak to those principles.
I've worked in all kinds of team configurations in my ten years (so far) in the game industry, so I thought I'd talk a little bit about what I've experienced as a game UI/UX designer from two different perspectives: that of the embedded designer, and that of the "client services" designer. Both styles of working have their pros and cons.
I believe that there are two sentences that sum up adulthood: "I can have a cupcake whenever I want" and "I should not have a cupcake whenever I want." These two statements are frequently on my mind now that I work right next door to a Cupcake Royale.
I've been following with interest the discussion among non-game-industry UX designers that "UX is not UI," and finding that the evolution of UX from UI within the game industry has created a unique type of UX designer that really does seem heavily tied into UI design.
A huge portion of my UI/UX design time is spent in the sketching phase. I don't rely completely on stencils, but when I need one I like having it. The other day I realized that, for a long time, I'd been doing something that I wish I had a stencil for. I was sure such a stencil existed, but I did a Google search, asked around on Twitter, and turned up absolutely nothing. Completely surprised by this, I decided that it's not hard to make my own -- after all, I'd done it for quilting way back in the day, when I was into that sort of thing.
I use both Twitter and Facebook, but in very different ways, and I get very different user experiences out of both of them. My Facebook friends list is very highly curated; although I sometimes feel bad about it, I have a fairly strict rule about only having people on my friends list that I actually know, in person, and are friends or close colleagues in some way -- not just people I met at a game dev conference somewhere. The reason for this is that I use Facebook for more personal updates and targeted discussion.
My Twitter feed, on the other hand, is a much looser, less committed stream of stuff. Unlike Facebook, there's no mutual requirement for following, so I'll tend to follow anyone who seems remotely interesting until they prove themselves not to be, at which point I'll remove them -- because, unlike Facebook, I feel less obligation to follow someone on Twitter since it's less personal.
The problem with both of these is that they're at opposite ends of the stream control spectrum. Facebook has always had algorithms that are out of our control as users that dictate which posts from which friends you see, and has implemented even more controversial stream-throttling mechanisms recently with their promoted posts. You're able to set up lists to offset this, but the effort to do so is high enough to be a bothersome user experience.
Twitter, on the other hand, has zero internal stream-throttling mechanisms. Again, like Facebook, you can set up lists to manage this, but it's to achieve the opposite experience from Facebook -- your feed can be so noisy that you need to set up lists so that you don't miss anything.
I do some management of my Twitter feed in order to make it useful rather than too noisy. But even with some pruning and management, there are posters I enjoy following who are just really, really prolific. And while I might enjoy many of their posts, I often wish I could throttle their post stream just a little bit, depending on who the poster is.
The type of throttling that I'm envisioning already exists in Google News. Google News allows you to list your favorite news sources, but then set a slider value according to how much of that source you want to see in your news feed -- "seldom" to "always", with values like "rarely" and "occasionally" in between.
I would love to see this kind of slider implemented on the profile of people I follow, and setting it controls how many posts I see from them in a given time in my stream.
What would the algorithm be for determining how to throttle a user's posts? Would it be time-based or content-based? I'm not immediately sure, but I imagine some basic UX research could be done with Twitter's users to determine what value they get out of the posters they follow or how they "use" their stream to find the answer.
I love prototyping, and I love the Paper app for my iPad. Here's a short presentation on prototyping, done with Paper.
In order to for us to avoid wasting valuable engineering time, it's almost vital that much of my work gets thrown away. It's better to test out ideas and waste only a day of my time than it is to waste several days of several people's time, only to discover the idea didn't work.
Ever since working on my own card game that initially started life as video game, I've been wondering what my favorite video games would look like if they were card games.
Stumptown is a local Seattle coffee brand that I can't get enough of for two reasons: their coffee is just damn good, and their packaging design is wonderful.
We own four alpacas. Not llamas, alpacas. Inevitably someone will come to the house that's never been there, a delivery person or door knocker, and they'll say, "cool llamas!" And then we have to correct them.
UXMatters recently posted a great article called "Quieting the Outcry over Software User Interface Redesigns." It touches on something we've probably all experienced on sites like Facebook: the moment there's any significant redesign of the site, half of our feed is full of outrage over the change and threats to quit that almost always prove to be empty. As a UI designer, it can be hard to figure out where that line is between legitimate user frustration over something that turned out to be a poor design decision on your part, and the knee-jerk reaction to change that's very common when people have become accustomed to doing things a certain way and finding things in certain spots on their favorite web sites (or the game UI they've been using for the past few weeks). This article provides some great information on how to avoid that reaction (or mostly avoid it, since there will always be a vocal minority that hates change even if it's for the better). But there is one small bit that I disagree with.
In addition, evaluate the groups of users who are complaining and the tasks with which they’re having problems. Are they representative of the primary users of your product? Do they match one of your key audience profiles? Are they typical users? Are they upset about something relating to a key task—or a secondary task that users rarely perform? For example, removing a command-line Interface tool might make a tiny group of users very upset, but benefit 99% of your target audience.
I thought this was a poor example of a good point the author was trying to make. The usual goal of UI design, whether it's for games or for applications, is to make interactions simple. But frequently we as designers can take that idea too far and begin watering down gameplay or feature richness for the sake of UI simplicity, losing useful and in-depth features that the user may ultimately benefit from and enjoy once they've crossed the line from beginner to advanced user.
Instead, why not think of something like a command-line interface tool as a deeper, more richly-featured layer of UI that can remain in place as something accessible to the more hardcore users? In fact, a command-line interface is a great example that's directly applicable to games. Many online multiplayer games require servers to run, and for some games these servers are run by the players themselves, usually by players who are technically adept and know their way around a command line. For years, running a server was almost always only possible via the command line, but it's now pretty standard to include a GUI in the main menu with most of the common options a server administrator would want to set. And in most of these games, the command line interface is still accessible and allows really knowledgeable server admins to set many more advanced options on their servers.
The percentage of server admins compared to players is going to be pretty small for any game, but those server admins are a very important component of your game -- without them you'd have far fewer servers to play on. Instead of cutting the command line interface because it's advanced and only used by a small percentage of players, the ability to run a server is made accessible for both beginner and advanced players by adding an outer layer to the whole game UI.
Not every UI decision can be treated like this, of course. In some cases a game mechanic may be very complex, and the only UI solution that works with it may be equally complex. In cases like this, the questions to be answered are these: is there any way to create a layered UI solution that helps beginning players grasp the basics of the mechanic, but gives advanced players the information they need to play at a higher level? If there isn't, then does the mechanic need to be simplified in order to make it accessible to the highest number of players so it doesn't turn people away? Or would simplifying the mechanic unacceptably water down the gameplay goals?
In the best game UI design scenarios, layered UI can be created so that beginners don't feel alienated by advanced features or mechanics that they don't yet understand, but the more advanced layer of UI still exists so that when players are ready to go from beginners to advanced users, they can level up in their UI skills as well as their game skills. Yep, it's gamification of the UI -- if you're a Photoshop user you're probably familiar with the feeling of mastering the deeper layers of complexity within the app, and it's something that can happen in game UI, too.
So while we may run into situations in which we have to consider cutting that feature so that 99% of our audience is made happier, I like to approach game UI problems as layers of an onion first. Sometimes with more eye-watering, depending on how hard the problem is to solve.
I picked up my iPad the other day and began messing around in iDraw with the new stylus I bought. I was just goofing off when I drew a shape that was reminiscent of a bee and an idea took shape for an image. An image of a speedy bee. A SpeedBee, if you will.
So I kept working out the idea in iDraw and then did a major revision of it in Illustrator. I'm pretty happy with the result so far, although he needs some work -- I'm trying to convey cute, fat, and speedy all at once and the speedy part is suffering. I don't know why but trying to find the right intersection of fat and speedy just seems necessary for this image rather than dropping the speedy concept all together.
I'm still messing around a bit with the Pig Sandwich logo. I've been inspired by browsing dribbble lately and seeing the incredibly logo concepts posted there, so I thought I'd try some variations and see what I could come up with.
I like the texture on this one, but it's still lacking something. I didn't like how clean the lines were in my original vector drawing so I deliberately messed them up a bit, but they're still not quite right. Still, I like the feel of it and the text with the logo.
I ditched the text for this next version and just wanted a nice, clean logo image with a little texture against a blood-red background. I think this one is my favorite.
It's a little odd trying to create a logo for a bare, unformed concept. Normally you would have some entity to work around, something that gives the logo context. But here all I had was a vague idea so I'm not sure if it works. But regardless of that it's been a fun exercise.
Matt and I were on our way home from work one night this week, listening to NPR on the way as we're wont to do. There was a story on that we were really only marginally listening to, at least until we heard the reporter say the phrase, "...the pigs they raise for their sandwiches." We started laughing at the odd choice of phrasing and immediately imagined pigs roaming the plains with slices of bread strapped to their sides.
I imagined a logo could be made of the concept. Pig Sandwich. So I decided to start a little design homework with it. It's a work in progress but here it is so far.
It's unusual to find something whose design you like in your medicine chest. But I've found something in mine: the box of Band-Aids that's been sitting there on the shelf for the past several weeks. Every morning since it appeared there I've looked at it while brushing my teeth, and it recently struck me that I really like that little box's design, something that would normally go fairly unnoticed.