Attacking UX/IA for Large Organizations

I don't know what the purpose of diagrmas like this are, except that this is a big pile of confusing crap and I feel compelled to document that fact.

Trying to clean-up sprawling, industrial-sized websites is always a challenge but it gets more difficult in direct proportion to the size of the company that owns the site.

The most predictable issues revolve around distributed ownership, inconsistent naming conventions and lack of a holistic understanding of the end users. Perhaps the biggest challenge isn’t related to UX/IA at all but instead has to do with getting access to the stakeholders who are empowered to authorize change. Too often in engagements like these, good ideas get nixed because someone more senior isn’t engaged in the process.

Some key elements in the UX / IA toolkit include taxonomies and controlled vocabularies, comprehensive navigation analysis and content audits. But perhaps the most powerful thing to do is a straightforward end-user analysis, complete with profiles and scenarios. A lot of designers have moved away from this approach int eh last couple of years influenced by agile methods and the demands of rapid functional prototyping. But when working on a larger project I still feel that they’re critical. And this in never more true than when working ona corporate project. This is because, despite all the doctrine to the contrary, most organizations are still reproducing their internal organizational structure in their website navigation.

This is understandable given the way that many of the larger corporate CMS systems are designed and implemented. They are built around a traditional model of corporate hierarchy and organization. Further, they are most often rolled-out and managed on a functional basis.

Using PhoneGap to Deliver Mobile

Phone gap looks promising and today its free as a bird. What happens int he next year or two is still open. Perhaps it will be a new hybrid combination of marketing and technology platform. This is truly innovative.

J, one of our lead developers sprung on me that he’d used some downtime to prototype a “Build Once / Run Anywhere” mobile version using PhoneGap. After developing an iPhone app using an offshore development group (at no small expense) it’s nice to know we can leverage the investment across platforms (including blackberry) and tablets without having to fuss with multiple style sheets.

What’s odd is that if you use HTML to generate the UI you can end up with Android users looking at interfaces that look totally iPhone. (The opposite is just as possible, it only depends on where you start.)

But the real advantage is that updates are automatic and passive. this means that users don’t need to manually update their apps. All the while the app cam be tethered to a real remote SQL database in real time.

What’s really very innovate here is that Phone Gap aims to provide both a technology and marketing platform in one package thereby combining two domains of knowledge and organizational interests that have traditionally been worlds apart.

The Importance of Concept Anchoring in App Design

THe concept of the Haida Rattle is non-verbal and assumed by tribal ritual participants. In traditional societies religion, spirituality and ritual are assumed and not chosen, unlike the function of religion in contemporary Western societies. Concept anchoring is required in our modern technological societies to help users overcome the challenges of mastering new conventions.

Designing software for smart phones and tablets requires a different approach than web application design. Unlike applications delivered via web, app users must understand how to use the application immediately or they will likely remove it from their device.

Consider the process that a typical user goes through in purchasing and buying an app. The purchase cycle may begin when the prospective buyer reads a review, gets  a personal recommendation or conducts a search in the app store on their phone. If the product looks appealing and the price is justifiable, the user will typically download and launch the application immediately.

I cannot think of many environments that are more distracting than a phone: For one thing, there’s a load of other applications, text, email and voice ready to interrupt the user flow; secondly, there’s a good chance the user is multitasking–the user may in fact just be waiting for a taxi, a plane or for friends to arrive for dinner. So first impressions are more then important; they are live or die episodes for your app. If you lose them on the initial crank, you may never get them back.

You may not be able to control the environment that your first-time user is going to be in when they experience your app for the first time, but you can take steps to make the experience positive.

Concept Anchor

A concept anchor is some aspect of your software that functions as key conceptual access for users to hold onto while they explore the functionality of your app. Without the anchor, the user can easily and quickly get lost and frustrated. When you’re app does something most people are already familiar with establishing a concept anchor is a no-brainer, but it gets much more tricky once you go into uncharted or ambiguous territory.

You establish a concept anchor in the design phase by identifying the key object, activity or task that is the prime rationale for developing your software. It should ideally be something that is already familiar to your users. For example, Instagram’s anchor is photographs–not the filters that makes the application unique. Similarly, Evernote uses the list as its concept anchor, even though there’s a million other ways to create lists, because it is the list, not the interesting things that evernote allows you to do with your list, that  people will initially and intuitively understand.

Surprise and Delight

Establish your concept anchor on the initial screen. This will have the dual benefit of making users feel comfortable while providing them with a secure anchor for them to hold on to while they explore the new and unique features your app has to offer. With the security of a concept anchor, new features can surprise and delight your new user. WIthout an anchor they may feel untethered, confused and frustrated.

Ushahidi and Capitalist Materialism

This presentation outlines the dynamics of Ushahidi crowdsouring and open source model for collective disaster response. It is a powerful platform that is generating critical reporting and distributed reporting on a truly global level. Have no doubt that Ushahidi will be as well-known as wikipedia in a few years and for all the right reasons.

That being said, this video is pretty disturbing in its philosophical assumptions and reductivist logic. All human actions and relations can never be reduced to commodities. And we should not be trying to justify crowdsourcing and disaster relief by assigning it a commercial value. There’s just no need for that.

User Experience at 15

Since the mid-nineties we’ve been working intimately with what we used to call information architects, but now call user interaction designers and there’s still no consensus on what their role is. This, despite the fact that colleges are teaching it, organizations are funding it and software has been created to support it.

The situation is significantly worse in marketing organizations as compared with engineering groups.

Why?

My theory on this is that it is structural: Marketing (like R&D) budgets are the most fragile and subject to last minute changes. After all, unlike costs for salary, facilities, production, etc., marketing budgets can be radically altered at the drop of a hat (or a drop of the stock market) without endangering the core business.

The result is that the entire practice of marketing has become accustomed to last minute changes, short-term decision-making, and a general poverty of planning and long-term organization. This isn’t necessarily a bad thing in today’s media environment, but it does lead to a cultural mindset that places a low relative value on skills that are methodical and process-oriented.

And so, 15 years later, while we don’t need to justify the practice, we do still need to educate and drill teams on the proper time and place to integrate this role into the team, how to integrate their efforts with the designers, and even, ironically, in some cases, to educate the user experience designers on why it is important to make interaction sexy.


Sign Language for Non-touch Screens

2011 is shaping up to be the year touch screens become ubiquitous. As adoption grows across a wider demographic and people become accustomed to interfacing with computers with their fingers we’ll likely see an acceleration of technologies that extend this modality of human computer interaction.

The problems with touch screens are obvious to anyone that uses them: difficult to manipulate items with precision, lack of physical feedback makes keyboard input error prone, and variances in finger size is not accommodated in current interfaces.

But what really stands out is the disparity between the simplistic inputs recognized by touch screens and the actual expressive potential of the human hand. Consider, as only one example, the expressive potential of hand gestures. Consider also what sign language has done with the human hand.

In order to truly engage the potential of the human hand’s expressive ability, touch screens will need to detect movement in space–not just the flat plane of the screen. Once they can detect motion and direction in space, a world of interpretive possibilities will come to life. Parallels to this are already happening in voice recognition.

Today Engadget reports on an Apple patent that embeds acoustic transducers in the chassis of a laptop to function not to detect sounds but as motion detectors. See http://engt.co/ibyKPj.

Once user input moves away from a keyboard it opens up a world where a more extensive vocabulary expressive gestures could be detected and interpreted. These could be based on whole words, phoneme or letters. These could be modeled after the sign language used by the deaf.