Calculating Delight

Last Saturday I attended the first ever Big (D)esign ’09 in Dallas. I was impressed with the caliber and content of the speakers . I’d rather not do one of those quick summaries where I regurgitate the highlights because I feel that the ideas I was exposed to deserve a little more illumination than that- so I’ll try to do a few more posts on the presentations that fascinated me the most.

One of the ideas I enjoyed was presented by Stephen P. Anderson in a lecture entitled “The Art and Science of Seductive Interactions.” I went in thinking he’d just present some basic interaction patterns. Instead, he stayed true to his title and discussed how you can consistently produce interactions that ‘seduce’ your audience through study and ingenuity.

Creating a popular, viral product or application isn’t a lucky accident (well, at least in most cases). It’s an engineered and carefully planned experience. You can have a well designed, very usable product but people may not be sticking around long on your site or your competition is overtaking you. Why is that? It’s because you haven’t tapped into what surprises, delights, and holds people’s attention by understanding how humans work.

Anderson proposed that if you understand your audience and what makes them tick by studying psychology, social sciences, and interactions that you find intriguing you can produce consistent, strong results. In order to take a product from good to great, you must know what interactions are  intriguing to your users and why.

Never forget that you are a user yourself. Do you ever experience something that delights you and makes you want to explore the site or application more? Then ask yourself why. Is it because your friends use it? It’s mentally stimulating? Is it because they incorporated a fun game? The majority of us are on the internet quite often so there’s no reason not to make an effort to study what works for us, what does not, and why. By making this effort, your ability to design fantastic products will grow by leaps and bounds.

If you’re interested in learning more about the happenings at Big (D)esign, check out the twitter feed from that day- there are also some links to recap posts .

Sleek and Shiny vs. Steam

I was reading this article by Rachel Hinman of Adaptive Path and was intrigued by their efforts to make a mobile device that would do well in less tech savvy markets such as rural India. Hinman noted that the sleek, streamlined design of devices such as the iPhone deter exploration and tangible interaction. She goes on to say that her design team turned to the style of Steampunk. “It’s an aesthetic that invites the touch of the human hand and it encourages engagement and fosters curiosity and play.”

I love the aesthetic of steampunk for it’s whimsy and nostalgia, but I realized that there’s another reason. It’s exactly as Hinman describes- it makes me want to explore and tinker with the item. It’s a very visceral aesthetic, which we lack in the digital age. More and more there’s what I would call the Apple Aesthetic, which is one button- if you’re lucky. You have to rely on the gizmo’s internal screen to lead you around by the nose- you can’t just hit a button and have it do what you want (I should note here that I am, at heart, a curmudgeon).

To me it feels flimsy and almost unreal. And if the devices internal computer seizes up, you’re out of luck. With that in mind, Adaptive Path’s idea of adding tangible interactions would, to some degree, be welcome in tech-savvy markets. While the typical American wouldn’t want all the buttons and gauges they’ve included, I would think something with a bit of “real” interaction would be welcome. Though we all oohed and aahed when the iPhone first came out, I mourn the loss of a few buttons to mash when I need something quick. Not to mention the tactile benefit of feeling buttons when you’re trying to call someone and drive at the same time…

My grumbles might fall on deaf ears as I’m taken into the sleek and shiny future, but I don’t think I’m alone in saying I would like the best of both worlds. If technology is capable of anything, then it can certainly give me a few buttons.

Toolbox Series: Scenarios and User Stories

Scenarios

I think a quote that sums up the essence of scenarios can be found within Dan Saffer’s Designing for Interaction:

“Scenarios provide a fast and effective way to imagine the design concepts in use. In a sense, scenarios are prototypes built of words.”

Taking a persona, you can create some different scenarios for your user to walk through to further examine and understand what kind of system they need in order to help them with their day to day tasks. Not only are you uncovering gaps in functionality and justifying current design decisions, but you are experiencing your design with a fresh perspective which allows you to understand what ultimately needs to be in the final product. You also uncover different wants and needs when you use different personas within the same scenario. A scenario saves time that might be spent making storyboards and wireframes that will undergo heavy editing after feedback. As Saffer says, a scenarios simplicity can be equated to “a sketch with words.”

Ah, but there are pitfalls to the seemingly simple scenario. Don’t let yourself write a “scenario” that is long-winded and includes implementation language such as which link the user has to click to get to a certain page. Along with not letting your scenarios get tangled up in code, don’t allow yourself to include extraneous information that is not relevant to what the persona is trying to do. As Indi Young notes in Mental Models, that information might be better off in the actual persona description, rather than bogging down your scenario.

User Stories

Originally I listed scenarios and user stories together in the toolbox series list, and though the names sound the same they really are quite different, so i thought it was worth expanding on. A scenario is a way for the interaction designer to imagine design concepts in use while a user story is a way for an Agile project team to plan out solutions for the product and estimate the amount of time implementing such functionality will take.

According to Mike Cohn’s User Stories Applied for Agile Software Development, a user story prompts people to write the story, discuss the story between themselves and clients, and finally to test the story. Most of all, a user story is a representation of functionality that will be valued by the user and the purchaser. One pitfall of user stories is that technical jargon such as ‘Form will be built using telerik controls’ fall into the story, and that makes for a bad story because that is purely for the developers; the user and the purchaser do not care how it works, but what it does.

Cohn also states that a good story is:

• Independent because if you have stories that intertwine, it can be difficult to prioritize and plan solutions
• Negotiable and able to be discussed amongst the project team as well as the customer.
• Valuable to user or purchasers as a purchaser may be interested in configuration information while a user may not.
• Estimatable so that a team can understand and evaluate how long a solution will take to build
• Small so that they can be used easily while in the planning phase.
• Testable so that developers know when they have finished that particular part of the project.

Pieces of the Puzzle

Both scenarios and user stories work to define solutions for your users and maintain flexibility before any major prototyping is done, but there are fundamental differences. Ultimately the scenario is a sketch of the system to be used in tandem with personas in order to understand the needs of the user. User stories are a tool of the development team to estimate time and discuss methods of desired functionality. Both are key in Agile development and are necessary to make a successful product that will result in happy users.

Toolbox Series: User Interviews

As I was writing this entry, I realized that I had even more to add to the ‘toolbox’…so keep in mind that this is an overview at best of user interviews and there are tons of books out there dedicated to this subject alone. My large influences for this section would have to be Designing for Interaction, Mental Models, and of course, my coworkers. Questions, comments, and additions more than welcome as this series is meant to be a learning experience for me.

Jumping right into it:

Learning the goals and the motivations of the user is key to a successful product. And how do we do this? Read about our subject? Make half-cocked, harebrained assumptions about who they are and what they want? No! We go to them. We put ourselves in their environment and learn their needs.

Maybe it’s my delusions of grandeur, but I like to think of myself as an ethnographer. I am there to observe, to enter with no predispositions or ideas as to how I think they operate. I enter with a blank slate and view this climate with fresh eyes.

Shadowing is a well-known method of user research. Trailing behind your subject, scribbling notes, and muttering quickly yet unintelligibly to yourself is highly recommended. Observe, take pictures, and most of all, take note. What are their surroundings like? What are the lighting conditions? What does their desk look like? What are the tools that they often carry around? Most importantly, as you take this all in, consider how you can support this environment and possibly even improve their work situation.

Another excellent way of getting to know your user is to talk to them. Imagine that. You might call this an interview but really it’s more of a dialogue and an opportunity to get to know for whom you are building. I’ve come to know this as a ‘non-directed interview.’ You are not there to barrage them with questions about things you assume they care about. You ask a question to get them going and follow their lead. Prod areas that need more detail and when things derail, offer a simple, ‘could you go back and tell me about ____.” A related note is that people love to talk about themselves (despite what they would have you believe), so if they can spare the time, be there with a recorder, a notebook, and plenty of writing utensils.

After you interview a good selection of users, transcribe your interviews (or, if you have to go the more time-conscious route, paraphrase) and review their statements on paper to tease out important tidbits. Goals, statements, motivations- it’s all there for you to review and pick up on patterns of behavior and stories. These will serve you later as you delve into the users’ environment for clues as to how you can support them.

Toolbox Series

I’m going to begin a series that will detail aspects and tools of the UX process that I’ve used and some that I’ve come across in my research. This will include (organized according to topic):

• Motivations
  • Interviews
  • Personas
  • Scenarios/user stories
• Modeling
  • Activity model
  • Task flows
• Ideation
  • Paper prototyping
  • Design studios
  • Design strategy sessions
• Creation
  • Wireframes
  • Mockups
  • Styleguide
• Technical Prototypes
  • Flash
  • HTML/CSS
• Evaluation
  • User testing
  • Design principles review
  • Heuristic evaluation

I’m looking forward to it as I’ve been meaning to explore each aspect of the process in depth for some time. I’m hoping others will find it useful, and certainly let me know if you have something to add to the list.

Tufte and the Super Graphic

On monday I was lucky enough to attend Edward Tufte’s seminar “Presenting Data and Information.” Known as the ‘da Vinci of data’, he has a wealth of advice on preparing information to ensure maximum readability as well as how to communicate efficiently in a presentation.

The idea that I really loved was what he called the ‘Super Graphic.’ It’s a large, easy to read visual display that includes many factors in order to drive home your point. One such example can be found in his book ‘Beautiful Evidence.’ In it there is a map created by Charles Joseph Minard which displays the French army’s losses in the Russian Campaign. Minard conveys several factors in a very concise, visual manner: the amount of men over time, the dates in which the campaign took place, the army’s path to moscow, the falling temperatures, and where the greatest losses were incurred.

Tufte said that when you start a presentation by handing someone a super graphic, it allows them to process the information from their own point of view and peak their interest. In order to support your presentation well with a super graphic it should show comparisons, contrasts, and causality. Not only that, but because you’re showing something with many dimensions, you should convey more than two or three variables because a real world problem is multivariant.

Tufte’s books are full of historical documents that convey information in a variety of ways, and I love what it implies: that we need to get back to basics. That we need to set aside the powerpoint, stop worrying about fancy technological ways to convey information, and just sit down with a pencil and draw out what we want to say. Focus needs to be on analyzing the problem, solidifying the explanation, and proposing a solution rather than worrying over how our graphs created in Illustrator look. As always, it’s not about the medium-  it’s about the subject matter.

After discussing this with a friend, she told me that she had once taken the time to print out a report for the big cheese at her company and placed it on his desk. Later, he came back to her and said that he was so impressed that she had taken the extra effort to deliver it in person rather than through email. He had been able to take the repor ton a business trip, analyze it for himself, and come back to her with questions.

I’m all for saving paper, but I really do believe that creating a tactile presentation that someone can hold and take home for later makes a major difference in its ability to impact them, even if it’s only a simple report. Let’s get back to basics, intrigue our audience with our findings, and give them something to hold on to and remember.

Lightbox

I figured out how to implement Lightbox today, which is quite a neat little tool if used properly. As the saying goes, just because you can use it doesn’t mean you should. I think it’s perfect for videos or for showing off a couple of pictures, but it’s no way to showcase a gallery unless you have all the pictures interconnected through a link within the Lightbox. There’s nothing worse than having to click to see something, close the dialog box, and click again. That’s one of the first things that’s going to be gutted out of my portfolio for convenience’s sake.

One thing that didn’t occur to me on this video project was, oh hey, accessibility. I use alt text for the benefit of the impaired as well as search engines for images, but there’s so much more I need to learn in this particular area. I’ll let you know when we have some subtitle system figured out. One of my goals is to read Maximum Accessibility by John Slatin.

I’m trying to think up some clever new uses for it (because I’d love to use something nifty like this on my portfolio). It’s pretty simple to use as the developer lays out the code pretty plainly. A modification that goes beyond images can be found here.

Very cool. Just goes to show you that by fiddling with a some code, you can make some amazing things.