Ghost in the Pixel

I was browsing around my old Adobe files/folders this morning and found this PDF that I had created for the team, as an evangelism artifact, based upon an industry report trumping UX over feature creep.

BeyondFeatures.pdf

In a nutshell:

• More features isn’t better, it’s worse.
• You can’t make things easier by adding to them
• Confusion is the ultimate deal breaker
• Style matters
• Only features that provide a good experience will be used
• Any feature that requires learning will only be adopted by a small fraction of users
• Unused features can slow you down and hurt ease of use
• Users don’t want to think about technology
• Forget about killer features; focus on killer experience (how it all comes together)
• Less is difficult to achieve, that’s why less is more valuable

Hope others find this to be valuable as well…

(Don’t you just love alliterative titles?) I noticed this interview by Adaptive Path of our User Experience boss at Cisco, Cordell Ratzlaff:
http://www.adaptivepath.com/ideas/essays/archives/000926.php

UPDATE: Here’s the video clip of the talk he gave at the MX Conference recently.

Found this part particularly valuable, about the challenges of inciting and sustaining cultural change around user experience/design:

CR: Ninety percent of the effort is about affecting culture change. The design work is actually the easy part. Transformation tactics that have worked well include:

• Inspiring people with a clear vision. A shared vision that people are excited about will take on its own momentum

• Setting high standards and sticking to them. We’ve sought out opportunities to point out that the old way of doing things is not acceptable

• Persistence. Change is hard and corporate inertia can be difficult to overcome. It’s much easier to manage the status quo than to enforce change. Senior leadership communicates and reinforces the benefits of making this transformation every chance we getDelivering and celebrating successes along the way has helped everyone see that all the hard work associated with the change is worth it.

That’s at the high level, which I totally agree with. Being one of the soldiers in the trenches, I’ve been doing the following to enable what Cordell describes:

• Create high quality deliverables: make those wireframes, mockups, flow diagrams look extra sharp and communicative! show that you design your own deliverables too and not something just spit out at the end…people notice that.

• Provide clear, efficient readable specs and supplemental materials: demonstrate that design functions at the mundane level as well as the “cool features”

• Take a stand on feature-creep and forcing questions at reviews: purpose, value, motivations…forces everyone to realize that UX is valuable and plays at every level of the “product development” game, not just personas at the beginning, and specs at the end, but a fully involved player

These aren’t big things like training sessions and giant posters (which we hope to get to do someday), but I think if you want to spread awareness, understanding, and appreciation, you gotta start with being the model yourself and then hopefully people will see it and respect you for it, and just maybe join in the fun. These are some simple, small actions that cumulatively can help spread design goodness!

I recently created this short poster as a personal means of illustrating in a compelling manner the core phases and tools and types for prototyping a UI design (focused exclusively, from the broader user-centered design process).

Basically I suggest that prototyping is an activity that enables the designer’s journey from abstraction (a novel but fuzzy idea) towards reality (the engineered product), in concert with a multi-disciplinary team.

That journey involves, as I see it, three major phases:

1. Exploratory PLAY: prelim exploration and play, trying out options, feeling out boundaries and limits, gathering early user inputs, making sense of toolkits, etc. This takes the form of whiteboard sketches, paper prototypes, sandboxed code tests, throwaway exercises, etc.

2. Communicative PROPOSAL: well-formed proposal for discussion, iteration, and formal usability evaluation. This takes the form of a concept car, sales demo, vision video, proof of concept, etc.

3. Declarative SPECIFICATION: specified solution with granular decisions for the content, behavior, and visuals, whereby the prototype is a functional demonstration of the real product’s features/styles. The prototype is robust enough to serve as the design spec itself (with minimal supporting documentation).

The end goal is achieving a prototype that effectively serves as the spec, or “prototype-as-spec” (proto-spec, as some have called it). It is a behavioral representation of the real product, at a highly resolved degree of fidelity for effective communication of the intended vision to the programmers, and QA testers. This would help get designers out of the documentation maintenance quagmire, and foster stronger ties between design and engineering, also provide efficient, clearer communication of what the design should do! 200 page Word documents with endless tables and labeled figures can only do so much…and can actually be counter-productive! Having a robust behavioral prototype of the real thing is much preferable for designers and programmers alike.