The July 11 mkeUX meetup was amazing. The back room of Sugar Maple was absolutely packed with people evidently interested in mobile UX, the topic du jour. (See photos from the event by Michael Seidel on Flickr.) The two presenters were obviously well-qualified and well-prepared, and the discussion amongst the group was always intriguing. Clearly these people know their stuff, and are passionate about it. Even the backchannel chatter was on topic. (Hint: follow the #mkeUX hashtag for ongoing discussions.)
I remembered to take along a notepad and a writing implement to save some of the discussion for posterity:
Andy Wright on the intimacy of mobile
Connectivity. The availability of tools like Skype for conversations over 3G is replacing the need for traditional phones. You don’t need minutes anymore, you just need a data package. The same goes for Facebook, etc. Potential problems come around when you lose signal… what happens when your device is offline?
Context. It comes down to the right things in the right places. Mobile is intimately personal as a platform – your phone is almost always with you, and your interactions with and through it are bound to be personal. What do users actually do with their phones? (There’s a claim that over 60% of the time, it’s just checking the time!)
You need to investigate what your users/customers are actually doing before you do anything new – it’s not worth your time to create or try to sell them something they have no interest in.
Foursquare may be the ultimate in context-aware applications – it’s intended to tie in with your physical context.
The growth of mobile search is extraordinary, especially when you consider someone’s location relative to their search query. Are they looking for nearby food, entertainment venues…? The next trend in mobile search is likely to be some strain of predictive search – based on where you are, can search predict what you’re trying to find?
Location. Knowing where your users are is a huge advantage, since you can immediately tailor the experience for them. Apps should just know this information automatically; as a user, I shouldn’t have to tell the app (but I should still have the option if needed). This is especially true since you may not always know where you actually are. If I’m in Poughkeepsie, I don’t have the slightest clue what the ZIP code there is – I should be able to let my phone access GPS and fill that information in for me, or have some way of entering a human-readable search.
Continuity. Mobile usage is inherently plagued by partial attention and constant interruptions. I’m out and about, I’m checking my email, then I get a call or a text, or some notification that pulls my attention away from whatever I was doing. This can be overcome by syncing across platforms; the e-book market is becoming a great example. The Kindle can automatically sync, to the word, your progress through a book on every platform – your Kindle, your computer, and your phone.
Accessibility. This concept is completely changing in the mobile space. It’s an entirely new paradigm with entirely new interactions to consider. Touch, accelerometers, voice control, etc. It’s not just pushing buttons anymore.
Speed. This is absolutely essential for any mobile apps or sites. Users need to have an immediately responsive experience. People are focused on this, then that, then this, and they can’t sit and wait through long response times.
Also, don’t over-burden users with options. Simplicity is better – don’t make me think about how to do something, just let me do it.
Scalability. Optimize for more than just one particular situation, platform and user type. Not everyone has an iPhone, not everyone has a Droid. Make sure your solution will work for as many of your users as possible.
Simplicity. It’s hard to make complex things look simple, but it’s absolutely critical to do so. Prototype early and iterate often.
Using is greater than thinking. Don’t worry about the design too early in the process; focus on functionality, and then make it pretty.
Mike Massie on the idea-to-production flow
When trying to produce something that will eventually be consumed by users, you have to become a user yourself. If it pisses you off, it’ll piss others off too. So think!
Be like electricity – follow the path of least resistance. Simplicity is king sometimes. Don’t overload your product with features; you have to consider things like battery life, task complexity, limitations of the hardware and software of the platform, etc. Don’t just assume what users want.
(Somewhere in the middle of all this the room spun into a tangential discussion of who calls themselves a developer versus a programmer, and what the difference between the roles is. I think it ended up with a relative consensus that developers tend to have a broader view of a project and wider responsibilities, while programmers are generally just code-writers. For the record, I consider myself a developer.)
Don’t bother users with tasks they don’t care about, but balance simplicity with utility. Give them options when it makes sense, but make your product just do the rest automatically. (But don’t just assume that because you do something everyone else will. You are not everyone else. Everyone has their own needs and particular use cases.)
Tom Henrich
There were a handful of people taking notes, so I’m curious to see what I may have missed in mine. If you see any, let me know!