I have really gotten hip to this live blogging thing at UX Week. At first I was intimidated by the idea, but once I attempted it, I found I enjoyed it quite a bit. I’ve heard from others that are following along that it’s beneficial to read the posts.

Today we are dragging a bit, after a week of conference talks and a few too many delicious mojitos last night. So I’m sitting back and listening today. But I wanted to share a few insights about live blogging.

The first day of the conference, I took copious written notes and then created my blog posts in my room after the day ended. The second day I decided to take the plunge and blog during the session. I had a couple of concerns:

1. What if I missed the meat of the topic because I was so busy typing?
2. What if I distracted the people around me who were trying to listen?
3. What was I really trying to do? Take notes? Provide a perfect written record of what went on? Or was it a more personal approach with my own thoughts and anecdotes?
4. Did I have to blog every session I attended? The folks at OpenTheWindow are doing an excellent job of that, but sometimes I like to sit back and listen so I decided to allow myself that luxury if I wanted it.

The posts kind of evolved as I did them. It isn’t necessary to take exact notes because the slides are published. Instead, I tried to provide a narrative that incorporated the slide bullets with what was spoken by the presenter to augment the slides.

I think there are several benefits to live blogging:

1. I have a written record of the conference that I can refer back to at any time. I can look up and download the slides, or I can just skim my post to get the information I’m looking for.
2. Others can get a sense of the presentation that goes beyond the slides provided by the presenter
3. I can hit “Publish” the moment the presentation ends, and then edit later. You don’t get more real-time than that!

I did have some questions about what I’m doing, and I’m not sure I have the answers but I wanted to throw them out:

1. What about accuracy? How do presenters feel about my account of their presentation and what if I got something wrong?
2. What about privacy? This was a paid conference….how do the organizers feel about the information being disseminated? I have a good feeling they love it, because it encourages more people to attend.

I don’t have a good sense of how many people were live blogging from the conference but I think the number was small.

I’ll leave you with a live blogging anecdote. The first day, I wrote a post about Scott Berkun’s books. (They’re on their way to me via Amazon, as we speak). I closed the browser and went to dinner with my friend Rebecca. While she was in the restroom I decided to check my Blackberry to see if I had any new messages. I had a comment from Scott! (He doesn’t know me from Adam’s housecat, as my grandmother would say). Wow, cool. I love that.

Rachel Hinman speaks about mobile phone design: 

Mobile Phone + Internet Access = Bad User Experience

Mobile phones are not PCs, they don’t display the Internet like PCs (even iPhones, what I’ve seen of them), and we have to be able to change our thinking and perspective about the Mobile Web.

My personal experience using the Web on my Blackberry is exactly as Rachel describes. A few sites look good. One is the PGA. We were at my in-laws’ house, and they have dial-up. My father-in-law wanted to know who was leading the Master’s, but didn’t want to get on the Internet. I told him we could check on my phone. He was amazed. But, I knew that a lot of businessmen have Blackberrys, and a lot of businessmen like golf, so I had a hunch it would be a good mobile web site. And I was right. But that’s not the norm.

There are fundamental differences between the desktop/laptop environment and a mobile phone. People who use desktops/laptops are usually seated, using a large screen, with lots of input options (keyboard, mouse). They have the metaphors of windows and icons that provide a sense of engagment.

In contrast, the mobile phone can be used anywhere: in bed, on the train, and the context is outside of the user’s control in many ways. As far as input, most phones offer little options. Applications take up the entire screen and you can usually only see one thing at a time.

PC = deep dives

Mobile = skimming the surface

Design for partial attention and interruption. Consider passive forms of content consumption and create experiences that are meant for skimming the surface.

Mix tapes - they were difficult to make because they were an organizing exercise that went against the traditional organizing schema of grouping music by albums. Likewise, the current structure of the Web isn’t the same structure we want on a mobile phone.

People don’t want web sites, they want information. How do we enable people to find information in system that’s made up of pages? One was is to privilege XML over HTML.

What do people want on the Internet? Regardless of culture they almost always say “news, weather, and stock quotes.” This information is available from other sources (sometimes in easier formats). Why do people want to access the Internet to get this?

Rachel mentioned a user she interviewed, who was in the US and away from his home country. He read the news because he wanted to feel closer to home.

Keep an eye out for cobbling. Add this to the list of other unanticipated uses for the camera phone: people go into stores and try on outfits, take photos, and send them to their friends for opinions. Another way people cobble technology together to meet their needs.

Personalization is also an important aspect of mobile phones. People use many different ways to customize their phone, from their home screen, ring tone, and exterior decoration.

Behavior is a function of the person and his or her environment. This is the basis for Joshua Porter’s talk on The Psychology of Social Networking.

He brings up some previous social psychology research, of which there is a great deal already. Not everyone has a research budget so it helps to look at what others have done. Research also helps to minimize politics and help a team focus on design and the issues/questions at hand. Research can provide insight into the Opaque Value Problem: the fact that something isn’t valuable to people who don’t use it (and these are generally the people who report on it).

Are social features economically viable? They allow you to have direct contact with people who make you successful, which is relatively easy for smaller companies but not so easy for larger companies with layera and layers of people between the C-suite and the customers. They also amplifies customer opinion. Allowing customers to voice their opinions is something companies may be reluctant to do, but those are the voices they need to be listening to. These kinds of features also provide rich data that can help steer design features. Support costs may also be reduced if problems and solutions are made public. But what Porter says may be the most important is that social features engender trust to form lasting relationships.

Amazon.com is good example of a site with a rich set of social features, such as recommendations, help, tags, ratings, shared images, “people who buy X also buy Y”, sales rank, add to wish list, tell a friend, offsite reviews, discussions, listmania, and more.

Remember Maslow’s Hierarchy of Needs? People start by solving needs like food, clothing, and shelter, and move up the pyramid to solving safety needs, then love, esteem, and finally at the top, self-actualization. Porter says that most people, while not selfish, are self interested (”what’s in it for me?”). To illustrate this point, he describes how at first, people were first interested in del.ici.ous for the social value of tagging, but in the end, the true value was in saving bookmarks for yourself. People use it for self-intereted reasons, and it’s important to understand that as a designer so you can focus on the right issues.

How do you encourage participation in social features? As mentioned above, first focus on personal value, then social value. If the service is valuable for people, they will tell their friends. Ask youself the question, “is this system valuable to someone even if no one else uses it?” Once you’ve provided value at a personal level, then ask “How can we use the collective action of our users to provide more value?”

Another psychologist who has already done a good deal of online research that’s still relevant today is Peter Kollock. Kollock’s 4 Motivations for Contributing asks “Why do people do what they do online?” First, there’s reciprocity. If you do something for someone, they might do something for you. Second, there’s reputation. Third, an increased sense of efficacy. If you feel like you’re adding value, you are more inclined to contribute. Last, there’s attachment to the need of a group.

Digg used to have a “Top Diggers” list, and people competed to appear on this list to gain a reputation as someone who submits valued content. Over time, this expanded to tangible results such as job offers for some of the top diggers. Reciprocity/efficacy and reputation at work.

Axelrod’s 3 Necessary Conditions to Cooperate: Why do people behave at all? First, they are more likely to cooperate if there is a likelihood of meeting in the future, and/or the ability to identify each other. The final condition is a record of past behavior. An example of past behavior is seller feedback on eBay.

In a study where people were presented with an interface WITH social features or WITHOUT social features (number of downloads of a particular song), the social influence information always affected people’s behavior, even if the most popular song changed every time. What’s interesting here is that this makes it harder to predict outcomes, not easier. Uh oh. Social influences changes people’s preferences, what they value, and what they do.

3 Life Stages

1. Identity formation: creation of social identity including finding oneself, defining preferences, choosing friend and social groups, what values and ideals are important, how to rebel against and deal with authority (ex. MySpace)
2. Professional Life: participation as a member in society and formation of a professional life. Ex. Linked In.
3. Reflection and storytelling: Transition to reflecting on previous stages, retiring and getting out of professional life. ACtive roles in family and society to preserve way of life, remember important historical issues to learn from. Ex. Geni

Todd Wilkens from Adaptive Path presents on Making Research Effective: 

Why does good research fail? Nobody understands it’s value, relevance, or how to make use of it. We may not have thought about what it means to our organizations, and we aren’t effective at communicating the importance and important findings of our research.

Who creates successful products? It’s the combination of all the components of an organization, such as researchers, designers, product managers, business analysts, etc.

Researchers are there to help everyone in the organization understand users. This is contrary to our usual understanding (there are researchers, and then there are everone else. Researchers do research, and then throw the findings over the wall to everyone else). Researchers need to be as good at educating and facilitating as they are at researching, otherwise much of what they do is lost, because others in the organization don’t understand it.

RESEARCH drive OBSERVATIONS drive INSIGHTS drive DESIGN

Research needs to be actionable (have ramifications for design, and artifacts that people who design things can act on, whether these people are actual designers, or marketers, product planners, etc.). Research also needs to be durable, with longevity that lasts longer than the timeframe of the research.

There are two approaches to tearing down the wall between researchers and everyone else. First is integrating research and design, and second is improving communication.

1. Integrating research and design:
Because it’s so important to “be there” (versus hear about research in a report or see a sample video clip) it’s valuable to take clients or stakeholders along for field research. They start to develop empathy for users and help to make the research more durable and actionable. They help the research team find interesting information, helping themselves and the project at the same time. There are degrees of involvement, from listening to a usability interview on mute, to actually going out to the field to talk to users. It depends on your organization as to what works.

2. Improving Communication:
“The effectiveness of research is inversely proportional to the thickness of its binding.” Good research artifacts and deliverables are clear and straightforward, engage the audience, and tell stories. Telling stories is important because the meatiness and interesting facets of people’s lives don’t come across in bullet points, but rather in narratives.

An example of an effective research deliverable is user personas. Insights and empathy meet in a one-page packet. Things that help make personas effective are: a name for the person, a photo, a story about what is going on with this person, and identification of behaviors and motivations of this user, and a situation that describes obstacles and triggers for interaction. Be wary of typing or stereotyping the user. The persona should instead be an archetype. Personas have to be concrete and real, so that they don’t create a barrier to empathy. Todd recommends The User is Always Right by Steve Mulder and Ziv Yaar to shed more light on personas.

Prototypes are another good example of a research artifact. Prototypes are engaging because they’re tangible. They don’t have to be high fidelity to be effective. Sharing prototypes with users as part of research can help you refine ideas and make changes. Prototypes don’t have to just be of interfaces but can also be of strategies.

Here are my notes from the panel today. I didn’t get all of the speakers’ names so I’ll leave them out for now.  

Besides RIAs, what other pressures have forced you to change your documentation style?

• Do less. Trying to outline a design by talking through it with a developer can be challenging.
• Waterfall – writing everything down in a fancy book didn’t work very well. Now we’re more interative and collaborative, more focused on creating quick and easy things and advance the conversation.
• Doing a lot more redesign work than fresh, clean design work. Don’t create brand new documents because artifacts are already there.  Using things like databases as documentation.

How do we figure out the tool we need for a particular audience?

• Do you think the biggest challenge we face is entrenched standards, which are preventing us from developing new techniques?
• Moving towards communities of practice, we can ask if we’re still solving the same problems, and then we can determine if we’re using the right tools

How does context impact your documentation?

• Consulting company, brought in to solve a particular problem. People do want things like sitemaps, which isn’t something we usually do. With every project there are new documentation challenges. We can tweak the process to accommodate that.
• In terms of methodologies, agile is better for refining than defining. Agile lacks the component of coming up with a vision for a project. You can lose sight of where you’re going in the long run.
• When we spend a lot of time on documentation, we get attached to it, and that can be problematic too. The good thing about agile, is that you can learn things halfway through and then go back and change things or change direction.

What kind of specific changes have your documents gone through since you entered the UX world?

• Documentation is usually seen as overhead. Doing live collaborative things can make that overhead less and less. Also, looking for tools and techniques to reduce documentation is one of the biggest ways it’s changed. We think more about how the documents will be used, disassembled, and metabolized into the organization. More flexible now.
• Not producing so many formal artifacts as much as we’re trying to get people into the same room to collaborate, work with sticky notes, etc. People see the collaborative work and they want to be a part of it
• Used to use the same kinds of documentation for every project. Now I try to find new ways for each project, so that we can get to a prototype environment more quickly. That matters a lot more now, and you don’t want to waste a lot of time with paper.

What about clients and documentation?

• Work with clients now in a completely new way. Before it was one or two meetings, and then I come back with a solution. Now I want the clients to be a part of the wireframing process because it helps to get feedback from all of the different parts of the business.
• We are becoming more facilitators that we are experts at coming up with specific deliverables. It’s more important to get everyone around the table.
• When people are dispersed around the world, there aren’t good tools to get everyone to collaborate. We need a virtual sticky note application.
• Facilitator is the role we’re now playing in a lot of organizations, because what seems like a design issue is really a business or organizational issue. The way the business talks within itself. The deliverables advance, step by step, the conversation between business units.

Are any deliverable types extinct?

• It’s been a long time since I did a full site map.
• We do have a full site map but it doesn’t look the same as older site maps, because not everything connects together
• There’s so much content that it doesn’t make sense to map it all out
• I stopped using wireframes because I can create high fidelity visual prototype quickly in Photoshop. Likewise there are people on our team who can create functional prototypes quickly. We iterate through a functional prototype and we then hand it off to the development team and the UI shouldn’t change – that’s the ideal.
• Wireframing tends to be an artifact of a different process. “This kind of stuff belongs here” is the question you’re trying to answer. Focusing on structure and trying to get buyoff. In an agile world, the buyoff isn’t really there anymore.
• There’s a trend in doing hi-fi prototypes right off the bat and that worries me from a usability testing perspective. I’m a big fan of low-fi prototypes. A lot of things get hidden if you go to high fidelity first.
• One of the flaws in agile is that it doesn’t leave room for testing in the design process.
• We adjust the fidelity of the prototype based on the intent. We use them to explore ideas, provide clarification, communication, persuasion, and inspiration. We adjust the fidelity depending on the purpose. Sometimes if you do a test with a black and white prototype, you may not see the same behavior as if you did the test with the bright green, bold button.
• Sometimes the client makes a difference. We did a project with orthopedic surgeons, and they didn’t react well to a sketchy styled wireframe.

UX Net Event in DC called Resume Roundup. We talked about the hiring process and then looked at people’s resumes. We realized it was more about the portfolio. What do you look for in a portfolio?

• Empathy – ability to present their work in a human sense. Besides good design, the ability to understand design as a story and its utility in human terms.
• It depends. Looking for someone clever and evidence of how they’ve solved things creatively. How they understand their stuff.
• I wouldn’t hire someone based on their portfolio because it’s hypocritical – my recent work is sketchy and random. I would be looking for the ability of people to explain the problem, use documentation to get through the process and communicate ideas. It’s about whether or not it works.
• Passion, empathy, curiosity. Interested in the process – what was the problem, what happened along the way. Visual design skills because these are visual communication tools.
• It can be pictures and stories – photos of sticky notes.

What about longer projects in corporate or government where the project cycles are longer?

• Patterns. Ultimately if you can establish ways in which you do things or particular interactions work, you can create variations through parameters.
• Beyond reusable elements, the research that went into the project and personas that were generated, which are separate from the interface – keeping them separate is helpful in keeping to tell the story.
• Stories are part of the process as projects go on. They get lost – people forget why decision were made. Need to come up with ways to maintain stories to keep them alive so we maintain context.
• We don’t do a good job of documenting design decisions, and we need to do that. Need to develop documents about reason and rationale.

What is the best tool or approach used in early design sessions with stakeholders? What successes or failures have you had?

• Whiteboard for requirements gathering. Then we come back with a photo of that whiteboard and move on from there.
• If you remember that you have to look at users, competition, and yourself and can bring that understanding to a group, you can facilitate the discussion in a meaningful way.
• Pen and paper can get you a long way in facilitating discussions early on. Can be in the hands of clients and stakeholders.
• Sticky notes and prototypes (paper or HTML).

Just like our speaker, Derek Featherstone, accessiblity of Rich Internet Applications (RIAs) is something near and dear to my heart. We have been studying and learning about this as we build RIAs for healthcare, because it’s really important to support not only those users with assistive technology but older users with visual and auditory impairments.

He warns against “checklist syndrome” - being driven by 508 compliance or industry standards. Some of those rules don’t make sense today, and not all of them need to be followed. Involving users in the testing is one way to get away from this midset. User behavior can’t be captured in something as impersonal as a checklist. As in usability testing, users will always surprise you, so treating accessibility testing like user testing will result in the discovery of issues that otherwise wouldn’t be known.

RIAs involve custom widgets: controls created to fill the gaps that HTML lacks. For example, Googel Maps has a zoom control that looks like a graduated slider. Unfortunately, this widget isn’t keyboard accessible. For his IronMan, Featherstone created a new version of Google Maps called IronFeathers, with accessible map controls. The lesson here is, if you create custom widgets, the controls need to be available to keyboards and voice recognition users.

It’s actually quite shocking that applications like Google Maps, BaseCamp, and Flickr aren’t accessible.

Likewise, graphical updates such as yellow highlighting for confirmation, or a cycling image to show progress…these things aren’t available to screen readers. How can we tell users that information has been added or updated? Focus can be changed programatically using javascript. There are also ways to force a screenreader to update its buffer.

As I watch the presentation I realize that we are guilty of almost everything he’s pointing out as problematic in an application we’re building: custom widgets, div overlays, yellow highlighting. The app may pass almost all of the checklist items but it isn’t truly accessible by the user experience standard.

And then he points out the graphical password strength indicator. Doh! We have that. This visual information isn’t being communicated to the screen reader user on Google.

In forms, it’s imperative that each field have a label, and that tab order makes sense. Errors and advisory information needs to be located near the control to which it relates. Login buttons that not actually buttons, but graphics, can be problematic, because they may seem to be images when read by a screen reader.

When emulating a desktop application, such as an instant messenger client, users will expect something that LOOKS like a window to BEHAVE like a window. For example, they will expect the same shortcuts to work on a virtual window that work on a real window.

What are some solutions to all of these issues:

• Think about linearlization not from screen to screen but also within a screen
• Indicate function of non-native dialogs in prototypes (someone need a research project? Create an IA vocabulary for noting accessibility points in interface diagrams)
• Provide suggested alternatives at critical points
• Consider using “boring buttons” in design documents so that buttons will be coded as such, and can be styled later.
• Make sure buttons are last in the flow (and other choices can be accessed via the keyboard before the interaction is completed).
• Change order around, if necessary, to clue the user in to changes on the page. Also provide links to these new or changed sections.

This is my first shot at blogging DURING the presenation, so let’s see how it goes!

I am a big evangelist of prototypes. In my experience, a lot of good has come from creating prototypes. Back in the day when my team was launching the first generation of the Scion configurator, we used a prototype to show the client team that what they envisioned could be built, and it made all the difference in the world by instilling confidence from them in us.

David Verba from Adaptive Path cites this as an advantage of prototyping, along with the fact that the practice helps teams see problems more clearly (and see some problems at all), fosters collaboration, and helps everyone see what is possible.

We have been recently working on an app built using ajax interactions, and it was difficult as a designer to prototype this application because it took reams and reams of paper to print all my Visio screens. Besides the fact that flat screens can’t convey interaction very well. Also, it was arduous to make changes, which runs counter to the purpose of prototypes in the first place.

There is merit in starting out with lightweight approaches, like sketching and Visio. When it comes time to create a working prototype, however, it can be done with HTML and Javascript. It can feel like a real application just using these two tools. I was pleased to note that David uses the Prototype javascript library, one of the libraries we use in our application.

He describes some pitfalls of this approach, but they really aren’t pitfalls, because they’re things you have to address anyway at some point, such as what kind of data will you be using, and how to get access to a front-end developer. May as well go ahead and tackle these issues at the time of prototyping than leave them until later!

He also talked about using Flash or Flex for prototyping. I have not really explored these yet because I thought the learning curve was too steep but perhaps they deserve a second look. It would be really nice to have the ability to create the ajax interactions using, well, ajax!

Another great benefit of prototyping is that the development team can re-use a lot of the code. This is more true with Flash and Flex than some of the other prototyping tools, and defintely more true than Visio screens.

I’m eager to try one of these for my next prototype.

This morning’s keynote speaker for UX Week 2007 was Lisa Strausfeld of One Laptop per Child (http://laptop.org/).

This non-profit was started by Nicholas Negroponte, founder of MIT’s Media Lab and a first investor in Wired Magazine.

One Laptop per Child (OLPC) has a vision for providing “children around the world with new opportunities to explore, experiment and express themselves.” This morning’s demonstration of the XO laptop was inspiring to see.

Laptops are distributed to children in classrooms. The laptops are on a network called a “mesh” that allows one laptop to see all other laptops. There are 4 spheres involved in the “mesh”- person, friends, neighborhood and activity. A child can move between the spheres, working on their homework or joining activities that other children have launched and shared. Activities include taking pictures, writing stories, create drawing, making music and browse the web. The obvious emphasis is on collaboration and interaction. All activities are automatically saved to a journal and time-stamped.

The laptop itself uses Flash memory instead of a hard drive, requires little power, and employs a new display technology that works in direct sunlight. The OS is Red Hat Linux – “Sugar” open source software.

To be even more inspired, check out the Progress page at
http://laptop.org/en/vision/progress/index.shtml.

And consider getting a child a laptop this approaching holiday season!

I am a sucker for books, and I picked up two good titles today at the conference, both from Scott Berkun:

The Art of Project Management (recommended by Andrew Crow)

The Myths of Innovation (recommeded by Indi Young)

Another talk I heard today was from Kevin Brooks, principal staff researcher from Motorola Labs. His talk involved techniques for listening and for telling stories, to encourage collaboration in design.

This really hit home because we recently had a design meeting where the mind of our very brilliant, former NASA-engineering developer had to meet my mind, which is so non-NASA-esque. We were trying to communicate ideas to each other and were just striking out. I couldn’t understand the functional-speak, and I wasn’t doing too good of a job explaining the plight of the user.

So, back to Kevin. (This is the “bracketed story” method of telling you what I want to tell you, just in case you were wondering.) He noted that we live in a society that is far too focused on speaking and not nearly focused enough on listening. And even when we do listen, we do it with the mindset of “when are they going to stop for a breath so I can butt in” or with the idea that we’ll trump their story with one better.

However, when we truly listen to someone, we give them freedom to express their ideas. We empower them and deepen our relationship with them. Who doesn’t like to be around someone who listens to them?! It’s important to really listen and deeply understand what the other person is saying. Listening can in fact be addictive.

One important lesson I learned from Kevin’s talk is that it’s not my job as the listener to “fix” the speaker. That halts their creative process. In fact, I’m bad about doing this. My mind races ahead of them with a bunch of questions, which I usually butt in and ask, because I am curious but also I’m thinking this will show them how interested I am. But, sounds like (scuse the pun) that it’s better to just sit back and listen.

So, back to our meeting, where we weren’t communicating and weren’t making much progress on our interface design. Neal used a great tool, the analogy. By showing us the interface of Picassa he got us thinking more along the same lines. We were both able to translate our own perspectives into something the other could understand and collaborate to make something better than each of our own contributions.