Joshua Porter

Joshua PorterJosh is a leading member of UIE's research team and has written extensively on such topics as Web 2.0, Ajax, web standards, and on-site search systems. Josh shares many of his design thoughts and commentaries on his personal blog: Bokardo.com.

Josh oversees the development of User Interface Engineering's web sites.

Josh's posts:

Social Design Research

May 4th, 2007 by Joshua Porter

This is part of a series on the topic of social design, a follow-up to the virtual seminar we held on April 11, 2007 called Social Design: Designing for the Social Lives of Users. To follow along, grab the Brain Sparks feed or subscribe to our free email newsletter, UIEtips.

Virtual Seminar attendee Paul Baker asks:

“What sort of contextual research might you do when designing a social site?”

We have found that research methods won’t change much when designing a social site, but the line of inquiry will. So we tend to use tried-and-true research tools: interviews, user tests, and field studies.

The big difference when moving to social design research is the focus of observation: in addition to wondering what activities people are doing and what is necessary for their completion, we increase focus on the social interactions that influence why they’re doing so.

A major insight of social design is that when people make decisions they rarely act alone. Their social groups, friends, and family have a huge influence on their behavior. As software becomes more a part of our lifestyle, social influence will play a larger part in how we use it.

This shouldn’t be surprising as it is easy to think of the last recommendation, suggestion, or pointer we received. Thus, these simple items are the object of our inquiry.

Here’s an example of how we might focus an interview on social aspects:

Imagine you’re interviewing someone about looking for an apartment on the Web. You ask them the usual questions, where they go, what sites they visit, what information is important to them, what they like and don’t like. Most of the discussion will deal with what is important to them as they fulfill this activity.

At some point, unless the person is truly anti-social, someone else will enter into the conversation. Maybe it’s their brother who recommended they search in a certain neighborhood in the Back Bay of Boston. Or their boyfriend who says to make sure everything that in the apartment is fixed before moving in. This is where the social part comes in.

Most of the time these people are treated as outsiders to research. They are flat characters, so to speak, who show up only for a minute. But when thinking about this from a more social perspective, these people are primary actors because they’re influencing the person as much as any software is. They are helping to define why the person is doing what they’re doing.

So the line of questioning turns toward them. We ask more about their influence. Did you take your brother’s suggestion? Do you often take his suggestion, or just in cases involving this subject? What makes him such a good person to listen to concerning this subject? Whose suggestion did you end up going with, and why?

In addition, we want to get a sense of how they communicated. Was it over the phone? Email? IM? During a face-to-face conversation? Did they get a recommendation from a blog? How are they getting their information?

Using questions like this help us figure out how this person assigns trust to those around them. It also helps us tease out important factors in their decision making process that involve other people.

Once we have a clear picture of how a person makes decisions in a certain area, we can compare them with others. We’ve found that there are usually trends in how this works. These trends feed into our design.

So if we were creating a site to support this activity, we might create a “apartment hunters” model in our software that allows people to connect with landlords based on criteria their social network suggested was important. We also know that apartment hunting doesn’t happen frequently, so we might lean away from a “friends” feature for the time being. But we might also focus more on archiving information over a longer term so that folks coming to the site don’t have to tap into their social network as much, instead relying on the accumulated wisdom of others.

This is just an example of how this might work. Your research will probably take you in some other, more interesting, direction. The key to doing social design research is to figure out the relationships between users and their social group, and how that affects their behavior and decision-making.

Why Invest in Social Features for Your Web Site?

May 1st, 2007 by Joshua Porter

This is the first in a multi-part series on the topic of social design, a follow-up to the virtual seminar we held on April 11, 2007 called Social Design: Designing for the Social Lives of Users. To follow along, grab the Brain Sparks feed or subscribe to our free email newsletter, UIEtips.

The runaway successes of YouTube, MySpace, and Flickr have completely changed the landscape of design. One huge change is the rise in socially-enabled web applications, applications that connect users in new and more explicit ways. Witness the trend of “going social” on news sites, where they give their community the ability to comment on and even participate in the news. The design team behind the USAToday.com web site, for example, recently enhanced their site with new social features including comments, reviews, discussion forums, and the ability to make recommendations. Just this past week ABCNews did the same.

So what are the core benefits of making this change? Why invest in social features? Although the benefits will vary depending on the business and the audience, here are some core benefits of investing in social features that apply broadly across many areas:

Amplify Customer Opinion

Humans are social animals. Therefore, it is likely that there is social activity happening around your content or service whether you want it to or not. People are sharing their stories, complimenting about what’s good, complaining about what’s bad even if you aren’t listening. By adding social features to your web site, you’re enabling them to do it in a way that you can listen to.

Companies with strong products users love will help them share those experiences with others. For example, something as simple as a “share this” feature on a news site will allow people to let someone else know about what they find interesting…amplifying their enthusiasm about it.

Similarly, companies with products users hate will have that amplified as well. If someone posts a horror story like Jeff Jarvis did in his famous “Dell Hell” blog posts, lots of people will get wind of it.

This is a crucial situation brought to bear by social features…when users complain you are given a clear choice: either ignore that feedback or act on it in a positive way. Companies that treat it as an opportunity for improvement will probably improve. Companies that treat it as a public airing of dirty laundry will probably suffer…

Data, Data, and more Data

Perhaps the least talked about benefit of social features is that they are wonderful precursors to a data-driven design strategy. Every time someone saves, shares, or comments on something, you have more data to go on regarding what they find valuable.

We’ve been doing this at UIE for some time. When someone shares an article at UIE we count it. The 10 most-shared articles on UIE.com, therefore, tell us what our readers find “share-worthy”. This is an important metric for us, as we use it to plan future pieces.

The benefits of data-driven design are huge for teams having trouble separating personal opinion from project decision-making. (we find very few teams where this isn’t the case). When decisions are based on actual data, they become much easier to make. Politics fall by the wayside and good design practices often emerge as a result.

Reduce Support Costs

Social features help reduce support costs by recording help issues publicly and letting customers help themselves. Talk to any support call specialist and you’ll find that their lives can be very repetitive, answering the same questions over and over again. This doesn’t have to be the case. When you add social features like support bulletin boards, for example, most of the conversations are recorded for all to see. Users can then search for the topic that they’re interested in, and if someone has had a similar experience previously they can start reading there. Bulletin boards, of course, have been around even longer than the Web itself. But making them public and searchable makes them valuable resources for everyone.

Additionally, systems like this allow users to help themselves by giving them the power to answer other people’s questions. Sometimes the users of the products are as knowledgeable about a product as the support people are. Social features allow them to help out and make the community stronger as a result.

Some sites like Apple.com’s Support Site have more advanced features whereby people can rate the responses they are given to their questions. That way, if one response by the community really helped the person who asked the question, it will be flagged and easily found by future readers. This helps users filter out bad responses, further reducing support costs.

Engendering Trust

Opening up communication channels with customers engenders trust, and that can be priceless. Sites that might otherwise be seen as closed-up and insular can open up communication channels where none existed before.

When you implement social features, it is a signal that you care what people have to say. It declares “we are here and we’re listening” attitude. Putting comments on a news article, like USAToday.com did, suggests that they are interested in letting people voice their opinion about the news.

Sometimes just telling someone their opinion counts is enough to engender trust. They’re much more likely to give you the benefit of the doubt when the sky turns dark. Of course, backing up your features by actually listening is necessary for the long-term health of your site, so the activity doesn’t end with implementation.

Going Social is a Long-term Experience Design Strategy

In addition to the explicit benefits for the site owner, implementing social features means building a community around shared experiences. The notion of “shared experiences” difficult to define, but the benefits of increased participation and caring are clear. People respond best to communities where they believe they’ll find like-minded people and where they feel their ideas and opinions matter. This trust is the real benefit of social software.

Therefore, adding social features isn’t so much a leap of faith as it is an investment in a long-term experience design strategy. Of course, the costs of building social features aren’t negligible and the return on investment might not be immediate. It may take months before a social support site starts to take over support activities from a call center. Therefore, it is critical to plan out the maintenance and support of social features over time.

When all the benefits are combined together and your customers now see your site as being run by human beings instead of nameless droids, and they feel invested in the site, you’ll realize that social features are only surfacing what exists already, and it’s really just a human-centered way forward.

Why MySpace is Good for Design

April 13th, 2007 by Joshua Porter

You’ve got to hand it to MySpace. The designers there have done the impossible: they’ve created a site that tramples on the aesthetic sensibilities of nearly everyone while continuing to grow and be successful.

Today’s homepage, a page cluttered with ads for the new movie Red Line, is just another in a long line of disorienting, disquieting, overly-saturated designs that makes you wonder: “Why? Why on earth would MySpace create a billboard for Satan?”

MySpace homepage

(click for full-size screenshot)

It’s no wonder that every time we get talking about MySpace some very passionate conversation ensues. It is almost impossible to see through the visual clutter of the site to reveal the value that people are actually getting out of it.

Bad Design, Great Conversation

That’s why I think MySpace a great thing for design. Not because the homepage makes one’s head hurt, but because it so obscures the value that its members are getting that it always leads to passionate conversations. It gets graphic designers riled up, interaction designers in a tizzy, and product leads simply shaking their head.

Just yesterday, Jared and I were in a meeting with a design team and the subject of MySpace came up. Boy did the conversation begin to move then! Everyone went from a caffeine low to a can’t-get-a-word-in edgewise high. It was fabulous. Everyone had an opinion, and everyone was involved. That in itself is valuable.

What often happens at this point is that the notion of value has to come to the forefront for MySpace to make sense. We can’t imagine value coming from something so ugly, so we have to rely on asking actual MySpace users to find out why they’re so connected to the site. If you have done this or ever have the chance to, do it! You’ll find it incredibly interesting. The conversations that I’ve had with MySpace users has really changed the way I think about design…as well as the entire value proposition of social software.

To that end, ethnographers and usability folks, who study the actual behavior of people, are fascinated by MySpace. It’s like studying an alien civilization. The site breaks all the rules. Our common notions of design just don’t apply. It’s truly another world.

This is a good thing! The frustration we feel when looking at MySpace is a catalyst for evaluating our own design practices. Are we making too many assumptions based on how we personally feel? Are we in tune enough with the people we design for? Are we focused too much on visuals and not enough on other ways of providing value? Are we not targeting the right population? The questions that MySpace forces on us are valuable, enlightening, and always controversial.

So what do you think? Do you agree that MySpace is good for design? Or do you see it as a blot on the face of the Web?

Amazon.com’s Social Design

March 5th, 2007 by Joshua Porter

Every day now it seems that another web site “Goes Social”, which means they add social features like those found on social networking sites MySpace, Facebook, and Digg. The latest example is the national news site USAToday, which recently redesigned and added several social features including the ability to comment on stories, rate stories, and recommend stories to others. Here is a full list of the new features as described by the design team.

At UIE we’ve been watching social sites for a while now, and we’ve seen many social features, including the ones added by USAToday, become commonplace over the last few years. It comes as no surprise that large organizations are seeing the value of connecting their users in ever-beneficial ways like they’re trying to do at USAToday.

But even though big sites adding many social features at a time draws lots of attention, there is one site that is way ahead of everyone else, offering a myriad of social features that eclipses the field, hands down. That site is Amazon.com. Now, we’re not feature counters by any means, but we have seen the features on Amazon provide a tremendous amount of value to users during testing of the site. The product reviews, for example, are a huge advantage Amazon holds over other e-commerce sites…people really trust the reviews there compared to everywhere else. I wrote about this phenomenon in The Amazon Effect.

But just how social is Amazon, you ask? Well, pretty darn social. In a slide from the presentation I gave at the UIE Web App Summit, I outlined 11 social features on the iPod product page at Amazon. The slide wasn’t very effective, however, as it only contained small screen-shots of the features laid on top of one another. It didn’t show the scope of what Amazon was doing with social features.

I’ve now found a better way to visualize what Amazon is doing. The following is a screen-shot of the entire iPod product page at Amazon, with 16! social features highlighted throughout the page:

social features on amazon.com

This is a clear indication that Amazon is making a huge investment in social features…and suggests that maybe it’s Amazon who should be getting the big press. Part of the reason why they don’t receive lots of press, of course, is that Amazon releases features one-at-a-time…slow enough that it creeps up on us.

Top 10 Most Shared Articles on UIE.com

January 10th, 2007 by Joshua Porter

It’s been a while since I reported on the most-shared articles here at UIE. Here they are:

  1. 5-Second Tests: Measuring Your Site’s Content Pages
  2. The Quiet Death of the Major Re-Launch
  3. What Makes a Design Seem ‘Intuitive’?
  4. The KJ-Technique: A Group Process for Establishing Priorities
  5. Branding and Usability
  6. The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site
  7. Using Ajax for Creating Web Applications
  8. Testing Web Sites with Eye-Tracking
  9. The Truth About Download Time
  10. Testing the Three-Click Rule

We have about 100 more articles in our article archive!

Back of Product Packages like Web App Tours

December 15th, 2006 by Joshua Porter

Luke Wroblewski, who is speaking at our Web App Summit this January in Monterey, makes an interesting connection between packaging of physical products and product tours of web applications.

Writing on Digital Web, Luke points out that the two have a lot in common:

“In a self-service retail world (present in most physical stores and just about everywhere online), the back-of-pack information plays the role of surrogate sales associate. It outlines the advantages of a product and often includes explanations of how to best utilize them. In other words, it tries to finalize the sale with peripheral messaging that supports the front’s central message.

In many web applications, this role is filled by product tours. The most common product tour is an illustrated page or set of pages that explains what can be done with an application, and shows features in action through representative screen shots.”

Lots more in the article itself: Packaging Design for Web-based Products

Having your Web App Cake and Eating it Too

November 30th, 2006 by Joshua Porter

For many of us being offline is becoming a thing of the past. We’re connected to the Network at home and at work, and everywhere in between with cellphones, blackberries, and car navigation systems. The Web is so pervasive that some of today’s teenagers don’t even know what it’s like to be without it, let alone offline for long periods of time.

Still, when we use today’s web apps, there is a clear distinction between online and off. If we aren’t online, we simply can’t use them. Our data resides on a web server (not our own machine) and the only way to access it is to actually communicate with the server in real time. To do that, we must be online.

Things are changing, however, albeit slowly. David Malouf, who is co-presenting a full-day seminar: Designing Powerful Web Applications using AJAX and RIAs at our upcoming Web App Summit, pointed me to a recent demonstration of a web app that promises to let us do just that: have our cake and eat it, too.

The application is a web-based office product called Zimbra. It includes a web-based email client, just like we’re used to with Yahoo Mail, Gmail, or Hotmail, but it also gives you the ability to work offline. From a recent blog post demonstrating that ability:

“The design goal is to have the same user experience with Zimbra both online and offline. Technically the Zimbra Offline client is the same AJAX client UI but now connecting to a local sync’d cache of the data and more importantly the ability to search, tag, organize, etc without network access. The two way sync of mail, calendar, contacts, and documents will allow Zimbra user’s to take their collaboration data together with the Zimbra AJAX experience with them on the road or in places without a network connection and when they come back online – all of the changes made while offline (like composing, deleting, moving, creating messages, contacts, events or folders) are sync’d back to the cloud. Just like traditional offline mail clients – messages pending to be sent are stored in an Outbox where you can edit and view them until re-connected.”

That’s quite a design goal, to make the online/offline distinction disappear! But it’s a vision of the future, (and I’m going out on a limb on this one 🙂 ) this will certainly be a feature built into many more web apps in months to come.

Bill Scott on Design Patterns

November 29th, 2006 by Joshua Porter

If your design team has been considering using patterns or wondering how they might be useful in your projects, check out this article with Bill Scott of Yahoo in .NET magazine:

Designing with Patterns

We’re lucky to have Bill speaking at our upcoming Web App Summit this January in Monterey, CA. He knows a tremendous amount about both creating and disseminating patterns, and his full-day tutorial with David Malouf contains an in-depth discussion about them.

Here’s a snippet from the article about how patterns play a dual role for teams:

“Patterns really act both as a design vocabulary and as a way to capture emergent best practices within the context of a specific design problem. With the recent advent of AJAX and the resurgence of Flash within the page, there are a number of new (and old) idioms that are now appearing on the web. As these idioms emerge, it’s handy to have a common terminology across Yahoo! for referring to them.”

Single-Screen Interfaces for Travel Web Apps

November 22nd, 2006 by Joshua Porter

Over at UXMatters, Joost Willemsen has written an insightful article about single-screen interfaces.

Joost points out that single-screen interfaces have a big advantage over page-based approaches because they allow users to work in their own, non-linear way. He says:

“In a multi-page environment, there are likely to be separate pages for almost every task in the purchasing process, including a search page, a page listing search results, pages displaying detailed information about individual search results, some options pages, pages showing pricing and availability, and booking pages. It’s difficult to make sense out of such dispersed information. When customers are looking at a page showing details about a particular search result, they can’t see the list of search results, making it difficult to compare and rank different results. When they are looking at a list of results they can’t see the search criteria that produced them, making it difficult to adapt their search criteria and come to grips with all the different offerings.

Customers who need to assess a great many search results must visit and revisit a lot of pages. In doing so, they often lose track of the big picture and waste a lot of time clicking back and forth and waiting for the server to deliver pages. They may become disenchanted with an online travel site that seems to punish them for not knowing exactly what they want.”

Although Joost doesn’t mention them specifically, an excellent example of a single-screen travel interface that realizes much of what he’s talking about is Kayak.com, who have continually iterated their interface over time with incredible results. They combine a single-screen with various filter mechanisms to make finding the right flight really easy. Here’s a screenshot:

Kayak.com's single-screen interface

To get the real experience of using Kayak’s single-screen interface, simply perform a search from their homepage. The results are a great use of what Joost calls “spatial adjacency”, meaning that multiple items (that used to be on separate pages) are now in adjacent positions on the screen.

Web App Trends: Users as Developers

November 17th, 2006 by Joshua Porter

(Part of a series on Web App Trends. See also: Fast Iterations)

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”

Other People Have the Itch, Too

What happens next is the same: after you scratch your own itch someone realizes that others have the itch, too. It might be the developer who notices, or another user. Mike McDerment, who co-founded Freshbooks, a web-based accounting application, describes this:

“(We) founded the company in January 2003. We were doing web design and development projects for various clients. We built FreshBooks for ourselves and very quickly realized that other businesses needed a painless billing solution. We put our heads down and got to work.”

Eating Your Own Dogfood

After you realize that others have the same problem, the next step isn’t to start building for all of those other people and assume you know everything. No, it’s to continue to design for yourself, and then use the product for an extended period of time. Play with it, push it, pull it, make sure that the features there are the right ones, not the nice-to-haves.

Christina Wodtke (who spoke at our User Interface 9 Conference), is working on a new web app: Public Square. She’s testing it out in a small way before releasing it as a service, using it to run one of our favorite sites, the online magazine Boxes and Arrows. She’s effectively killing two birds with one stone…using it herself as well as testing it with others to get real feedback.

Increased Passion for the Work

This users-as-developers cycle may be more virtuous than others. Dan Cederholm, who co-built a wine-sharing site called Corkd, describes how much more passionate he is when working on his own project.

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people. Cork’d has been the complete opposite situation, where we’ve been able to launch a product that would be considered “done” under most circumstances and then react to member feedback using the same attention to detail that went into the initial construction.”

A New Model

At first, it can be quaint to say that building for yourself is a nice perk of your situation. Increasingly, however, starting with eBay and now with firms like these four (and countless others as well), this new model is becoming the de facto way to develop, a critical part of success. If you compare a piece of software created by its users vs. one that’s not, it’s pretty easy to tell the difference. The designers understand the problem better, they’ve worked through most of the issues, and they’re more passionate about it after all is said and done.