Posts Tagged ‘user experience’

How do you feel?

// June 28th, 2009 // 0 Comments // Analysis, Business, Technology

I was playing with my iPhone earlier today and I remembered a notion we’ve all spoken about. For some reason, though, this time I pondered it a little longer than usual.

It feels wonderful.

The iPhone interface feels authentic, polished, robust and reactive in a way that few other software interfaces do. Many Apple interfaces do in fact.

I started thinking about other examples of this and I’ve come to realize that todays users seem to be rewarding feeling over function in their software. Google, FriendFeed, iPhone OS, MacOS, BaseCamp, Omnifocus, Flickr. These are all applications that feel good.

In many cases, they are far less functional than their counterparts, but that doesn’t seem to matter.

I also recently came across the Facebook Design Team’s Facebook Group.

This is from their group description:

We love clean and simple. We are passionate about enabling the user to connect and share what they want, fast. We design for users of all ages and demographics. We don’t believe in reading a manual to understand how something works. We care about details down to the pixel. We are a small team of 20, and we design the homepage, profile, chat, inbox, platform, and every part of the Facebook experience.

I especially like this sentence:

We care about details down to the pixel.

I don’t think anyone was under any illusion that Facebook did not care about pixels. Their interface is so clean and consistent that they have actually killed category of personal branding – self expression through design.

I was recently lobbying for something to be simpler to use. At the end of my description of how it might work, I was told that I contradicted myself, because the implementation I described was more complex.

The reality is that simple, intuitive and good feeling design is not about a simpler implementation – it’s actually about a more complex implementation. It’s usually an implementation that takes more thought, more time, more pixel pushing and ultimately more business logic for the developers.

Apple didn’t need to make their home screen bounce when you tried to push pass the end. But they did. It makes it feel great. I sit there playing with that little bouncy effect all the time (yes I do have a life). It took more time, more complexity and more work. But that’s not the point – the end result felt and behaved like a real-world object. It feels nicer and is ultimately a more intuitive way to signal the end of the list than ignoring the user input or jarring the user with some brute force notice.

Pixels matter. Animation Matters. Layers of additional business logic that try to consolidate and simplify the user experience matter. More than most engineers and product managers know.

Product managers need to give engineers the time to polish the pixels. They need to consider that getting a product ‘feature complete’ does not mean it is ‘user complete’. Engineers should also lobby for product managers to give them the time needed. When they are writing code and presenting things to the screen they also need to take the initiative to consider the pixels because the pixels matter.

As a product guy I’ve been guilty of pushing for feature complete instead of user complete. And I am going to try to find the patience and the process to change that.

Engineering is not just about building something that works – it’s about building things that belong in people’s lives. Things that people want to use not because they have to, but because it makes them feel good.

Proposal: OpenID Connect

// December 8th, 2008 // 0 Comments // Dataportability, Me, Technology, Work

OpenID needs to be as simple as Facebook Connect if it has any chance of competing. The problem is User Experience. It’s a nightmare.

My proposal:

  1. All Email providers and OpenID Consumers (particularly Gmail, Hotmail and Yahoo Mail) implement: http://eaut.org/
  2. Until we have critical mass with step 1, a 3rd party, community controled “Email to OpenID mapping service” should be provided. Vidoop runs a related service at http://emailtoid.net/. It’s quite good but it should be donated to the OpenID foundation for independent control.
  3. OpenID Connect login prompts ask for your email address on 3rd party sites.
  4. When you hit ‘connect’ it generates a popup much like the FB Connect popup.
  5. The contents of the popup is either:
    • The password screen of the OpenID provider as resolved via EAUT OR
    • The password screen of the OpenID provider as resolved via the community EmailtoID service OR
    • A prompt from the EmailToID service that walks you through creating a new OpenID or mapping an exiting OpenID to this email address.Here’s the important part: In all cases, the screens MUST conform to a strict UX Design Guideline set forth by the OpenID Foundation to ensure the process is as simple as Facebook Connect.Only providers that confirm to this OpenID Connect UX standard (as certified by the OpenID Foundation?) may have their OpenIDs validated in this popup. This is a harsh rule but it ensures a smooth UX for all involved.
  6. This initial Email to OpenID mapping through a 3rd party service is painful since most email providers and OpenID consumers do not use EAUT yet.
  7. This can be overcome if we get a series of OpenID Consumers and OpenID Providers involved as launch partners. A major email provider (Gmail, Hotmail and/or Yahoo) would also be be helpful but not a blocker.

Potential Concerns:

  1. How do we deter phishing? Does this work-flow make phishing worse because of the predictable UX? Does it matter? Is there a way to ensure a distributed karma system is included in the work flow?
  2. This only solves the login problem and does not go into the issue of connecting to, accessing and manipulating data as the full data portability vision describes. This is a conversation for another thread.

Bonus:

  • If you provide OpenID but do not consume it you need to be named and shamed. There should be a 2 month grace period, then The OpenID Foundation, the DataPortability Project and everyone else who is interested should participate.
  • “OpenID Connect” should be a new brand with a fresh batch of announcements with strict implementation guidelines (not just around UX but also around things like consumption).

To summarize, my proposal world:

  1. Allow users to use their email address for OpenID
  2. Standardize the User Experience for OpenID
  3. Provide a stop gap while Email providers catch up with Email to OpenID mapping.

Get involved:

I’d love to do mockups for this – but I’m busy. Anyone interested in learning from the Facebook Connect UX and drafting OpenID Connect Mockups from which we can draw the strict UX guidelines I mentioned?

Could this work?

Using email as OpenID

// August 22nd, 2008 // 0 Comments // Dataportability, Technology

One of the most common comments/questions I get while talking about data portability is ‘The OpenID User Experience sucks – how do we make it more user friendly?’.

The problem is two fold. First, users do not understand why they need to provide a URI to log in. Second, users get confused by bouncing around to a 3rd party site.

I’ve given a lot of thought to this problem.

The only answer I’ve had so far is that while the OpenID user experience is difficult to explain to users who expect an email address and password log in, the data portability value proposition may help justify the added cognitive load for users and vendors.

It’s probably true – but it’s not a good enough answer.

More recently I’ve been thinking about another potential solution.

I believe the 3rd party site bounce is actually becoming common place. Passport, Facebook, Google use it and, as such, users are becoming more comfortable with it.

The question of using a URI as a ‘username’ however, is a more difficult pattern to explain to users at a login screen.

Mapping email addresses to OpenIDs

The purists among us will argue that identity should not be tied to messaging. That is, uniquely identifying people by email address is a bad idea. It encourages spam and other unhealthy activity.

Putting that aside for a moment, however, imagine this.

Rather than asking for a user’s OpenID, ask them for their email address:

chris.saad@gmail.com

Now imagine the application refactoring the address on the fly to something like this:

http://gmail.com/chris.saad

The point here is that we take everything before the @ and place it after a slash. Remove the @ and put HTTP:// at the start and you end up with a well formed URI.

Now imagine that Gmail provided OpenID functionality for each email account in this way.

There are a number of challenges to pulling this off. Not the least of which is getting major email providers to support OpenID, and get existing OpenID consumers to refactor email addresses (if provided) on the fly.

It’s certainly worth thinking about though.