Tumble Along With Brad

IA Summit 2009: Personas and Politics

Personas are one of my favorite tools in the user experience tackle box. They can be used to drive the design of a project from start to finish, and also answer many pesky design problems. Adrienne Massanari (blog) pointed out another use for them at this years IA Summit in Memphis, political leverage. The following are my tweets from the session:

As she was working on a work flow diagram it occurred to her that she didn’t have a clue who the users were.

We are going to look at using Personas to tackle political issues inside an organization.

Discourse is the space in which carious objects emerge and are continuously transformed.

Discourse is powerful stuff, just as powerful as a language.

“Users are not monolithic or straight forward, but are complex and fragmented in nature..”

Theme 1: the ‘stupid user’ is a concept that is going away. Anyone who has done a usability test has felt this way though.

Not everyone wants to be a power user, and it makes sense to hide some advanced features to support the common user.

Theme 2: Users as victims of bad design. Nelson is seen as encouraging the view that users are simply victims.

If the user is a victim, then the designers can be viewed as teh heroes that swoop in to safe them.

Theme 3: Users as the co-designers. This is seen a lot in participatory design and users are seen as part of the overall system.

Personas and politics: Users are not good partners for coming up with design, better to have pretend users and design for them.

Good ole Eagle-Eye Edward from Cisco. He was a good desk topper for over a year at my old company.

Dan Saffer (@odannyboy) states that half of the personas that are out there are made up, and mostly just imaginary friends.

Personas are boundary objects, they encompass complex IA concept into a story.

PM’s and analysts can use personas as political leverage inside of their own organization.

IA/UCD uses users are resources to be mined, we flatten the difference between different people.

IA/UCD can also undervalue the users hands on knowledge and considers themselves the expert rather than the user.

IA/UCD already use users in the form of personas as political tools in their organization.

With personas we need to make sure we don’t mistake the map for the territory.

It is difficult for designers to be heroes because there is no tyrant to overthrow, no dragon to slay…

We can’t simply “understand users and then ignore them” — Robert Hoekman

The information Adrienne gave us did an excellent job of pointing out something that has always been there, but no one ever noticed. By showing us the variety of ways an organization can use a persona, it gives more strength to the agrument on why projects should take them time to develop them. It also adds another line of seperation between personas and market segments, though some can argue that market segments are used in the same manner.

Personas and politics: The discursive construction of the “user” in Information Architecture - IA Summit 2009

View more presentations from tankgrrl.

Twitter-Sourcing Blog Posts

One of the biggest challenges I have had getting started with blogging is coming up with topics that haven’t rehashed over and over again. I have tons of ideas that pop up in my head, and thanks to Google Tasks I have been able to keep up a decent number of posts in the hopper. Every now and then, I still struggle to come up with meaningful content to post out there for the world.

A solution I have been trying, and have had some success with, is see what my twitter network wants to hear about. Here are the tweets I got last week when I opened myself up to all my twitter friends:

@barrykirk - Barry Kirk

@nathanverrill - Nathan Verrill

Obviously, this post has been inspired by Barry’s tweet. It does raise the question though, does crowd-sourcing my blog posts out to twitter make me lazy?

Personally, I don’t think so. If there is one thing I am good at, it is having a conversation with someone no matter what the topic is. I don’t want my blog to be just another brain dumb of my views and ideas, I want it to be an on going conversation with my readers. By crowd-sourcing the topics on my blog, this just a way for me to starting a conversation with the community. I have devoted this blog to posts about Interaction Design, Web 2.0 Stuff, and Fatherhood (going to be a dad in about 4 months.) All of these topics have deep and extensive communities, with tons of content already in existence.

My method of interjecting myself into the overall conversations is to see what my peers want to hear about, or maybe what my response would be to something they have written. If successful, I see this as a great way to keep myself involved both in my blog and the community of Interaction Designers, Web Guru’s, and other dads out there.

Length of Design Reviews

Design reviews can be a brutal process, and take up a large amount of time for the whole project team. During the review, a designer can often feel as if they are standing in front of the firing squad, hoping to dodge the majority of the ‘bullets’. Many steps can be taken in order to make this process go smoothly and painlessly, such as presenting the design early and often during the conceptual stages of a design.

I try to include as many people as possible during the early stages of developing a design, mostly for the brainstorming sessions. Developers, Product Managers, and Business Analysts all look at a project differently, and can provide powerful insights. Involving them in the design process also transfers the ownership of the design to the team, rather than belonging to a single person. Design brainstorming sessions take time, and when you are talking about the time of developers and product managers your talking about cold hard cash. Getting them wholed up in a room for two to three hours while a design concept is hammered out just isn’t realistic.

The amount of time it takes to perform a proper brainstorming sessions depends greatly on the problem being solved. Initial concepts and sketches should be created during the first half of a session, including any necessary process flows. The design team can then bring in a small group of developers and product managers to review the initial flows and designs to provide immediate feedback. Ideas are bounced around and added to the concepts, eventually a realistic review is done. For a variety of reasons a design or flow may need to be modified due to a project’s schedule or technical constraints. Doing these modifications early allows the design review team to already have an idea on how a design solves a problem, and familiar with the high level concepts that went into its creation.

With the overall team becoming involved in the begging, design reviews become an activity to ensure that nothing got lost in translation. Now, an hour long design review could in theory be reduced to a half hour, letting everyone get back to work and not be stuck in a stuffy conference room.

Handheld Designed for Restaurant Servers

Last night my wife and I went to a local BBQ restaurant, Bandana’s, for dinner. When the waitress came to our table it was quite easy to notice that she was planning on taking our order using a mini Tablet PC. Being an interaction designer and user experience practitioner I was intrigued and started asking her about the device. how it help her taking orders, and how well it performed. Her two complaints were that when she tabs the screen, with a stylus mind you not her finger, it doesn’t register it all the time and it crashes all the time.

An example of what the device looked like, minus all the extra ‘rugged’ features:

My curiosity sated, we started to give her our dinner order. Luck be hold, as she is typing in my lunch rib platter the system crashes and starts to shut down. As she slings it back around her shoulder to reach for her trusty pen and paper, I notice the classic Windows XP shut down screen. Way to go Microsoft!

The real problem with the interaction design and the actual product design isn’t the fact that the device was HUGE and bulky or that it required a stylus to directly tab in our order. The problem is that the server is being forced to use something that does not support their standard method of taking guest’s orders. Many servers will use a mnemonic system when recording what their guests want to eat. Great servers can perfect this art to the point where they don’t even need to write anything down. How many times have you had a server take a table of 10’s order without writing something down, and everything coming out right?

These mnemonic systems are normally passed down from trainer to trainee when someone geta hired on at a restaurant. This means that the system is normally a standard for the servers at a particular location. My proposed interaction design for a handheld device that is used in a restaurant environment is one that can be setup by the restaurant managers to support the mnemonic system that they already have in place, and allow the servers to quickly input and submit orders when serving guests. Based on the details that were set up in the system, it can translate the mnemonic short hand into full order descriptions so the cooking staff knows exactly what to make.

The device to handle this type of interaction can therefore be small and easily fit in the palm of a server’s hand. It would still require a stylus for input, but the stylus would be used just as a pen would, making it feel more natural. Servers would write the shorthand ‘codes’ into the handheld and the only button pushing that needs to occur is when they submit the order or are initiating a new one.

If a system like this were in place, it would support the way servers have been taking food orders for decades and align directly with their mental model and goals.