Interface Mason

Pleasure and Pain » Improving the human experience one day at a time

Whitney Hess once again laying it down the way it needs to be laid down. Thanks Whitney for another brilliant post.

This quote really says it all:

"The user is not like me. Some designers don’t hold this truth to be self-evident. They claim that the best user experiences are “for us by us” — created by people who actually are like their users, so they can use their intuitions rather than reason to design products with the greatest impact. But are the proponents of self-design suggesting that all businesses should be in service to their own communities? Or only that the “best” businesses are? Self-design is self-satisfying, but it disregards the needs of the greater population, neglects the greater good."

Whitney's too polite to put it this way: Too much UX is happening in a mercenary business context in which the greater good is used as a punchline and the holy grail is "good enough."

The User Is Not Like Me

Pleasure and Pain » Improving the human experience one day at a time

More gems from Steve Jobs

My favorite quote from Steve Jobs adorns this very blog's header.

On this, what may be the eve of Jobs' direct influence on usability, here are more of his best quotes. And we finish with the best advertisement ever created.

“Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works. The design of the Mac wasn’t what it looked like, although that was part of it. Primarily, it was how it worked. To design something really well, you have to get it. You have to really grok what it’s all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it. Most people don’t take the time to do that." ~ Steve Jobs [Wired, February 1996]

“This is what customers pay us for–to sweat all these details so it’s easy and pleasant for them to use our computers. We’re supposed to be really good at this. That doesn’t mean we don’t listen to customers, but it’s hard for them to tell you what they want when they’ve never seen anything remotely like it. Take desktop video editing. I never got one request from someone who wanted to edit movies on his computer. Yet now that people see it, they say, ‘Oh my God, that’s great!’” ~ Steve Jobs [Fortune, January 24 2000]

“Some people are saying that we ought to put an IBM PC on every desk in America to improve productivity. It won’t work. The special incantations you have to learn this time are the “slash q-zs” and things like that. The manual for WordStar, the most popular word-processing program, is 400 pages thick. To write a novel, you have to read a novel––one that reads like a mystery to most people. They’re not going to learn slash q-z any more than they’re going to learn Morse code. That is what Macintosh is all about.” ~ Steve Jobs [Playboy, Feb. 1, 1985]

“The most compelling reason for most people to buy a computer for the home will be to link it to a nationwide communications network. We’re just in the beginning stages of what will be a truly remarkable breakthrough for most people––as remarkable as the telephone.” ~ Steve Jobs [Playboy, Feb. 1, 1985]

“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It’s not about money. It’s about the people you have, how you’re led, and how much you get it.” ~ Steve Jobs [Fortune, Nov. 9, 1998]

p>

We are the superior beings -- thoughts on the contribution of Mr. Steve Jobs

Steve jobs announced he is stepping down as the CEO of Apple today due to his ongoing battle with a rare form of panchreatic cancer. He will be staying on indefinitely as chairman. A good moment to stop and review the contribution of this titan of the computing industry and father of so much that is right in American culture generally.
 
I was just complimented by a colleague who had stopped by my cubicle to discuss this development. When I said Steve Jobs is the one guy who really gets that the machines need to be there for people, and not the other way around, he, my colleague, said Steve Jobs said that! I don't know this for sure, but it wouldn't surprise me. Jobs knew that while we can let ourselves be impressed by the speed and sleekness of the hard and software we create, ultimately humans are the superior thinking machines. They need to adapt to us, we shouldn't be expected to adapt to them (unless we're programmers or engineers or something).
 
Steve Jobs knows that we are the superior beings.
 
My office is abuzz with the news this morning and an e-mail from our COO just went out with some excellent quotes from Jobs. Here's the link.

 

What if your app was a building? Understanding UI roles by analogy

This analogy goes out to all you recruiters charged with hiring a Visual Designer but who end up talking to a UI Developer. Or maybe you’re looking for an IA, but end up talking to a UI Designer. These roles are all related but distinct and contractors such as myself understand that you don’t always have the time to become an expert before you start making phone-calls. Well, most of us understand.

What all these roles share in common is the goal of creating software. Of building it. Building software in many ways is like building a structure.  It requires a number of specialized skills and proceeds in a sequence of logical steps. There are still parallels for a scrum/agile development environment, but this analogy works best for the waterfall model of software development. And while we’ll have an analogous role for every step of the process, we’ll be focusing on those that relate to the interface ( see this Blog’s title ).

Let’s say you wanted to build a building. What would you need?

A reason, right? Why would you build a building for no good reason? What’s it for? Who’s going to use it? Who needs it and why? How would it make you money? What’s the impetus for its construction? If it’s a dam and the low-lying country up-river is a flood-plain, the reason is clear. If it’s just another gleaming skyscraper, the reasons could be more nuanced: Who’ll rent your space and why? What makes your gleaming skyscraper better than all the others? In software design, this is the business need: "Our call center people aren’t cross-selling our other products when they get customers on the phone." Or "We want our customers to provide the documentation we need from them online and how can we incentivize them to do that?"

Okay, you’ve identified a need. What next? Money. Someone to pay for it all. All those men and materiel aren’t going to pay for themselves, right?  In corporate software design, these are the project’s sponsors. They allocate the funds necessary for your skyscraper of an online spreadsheet app to go up on the information superhighway. Or if you’re building it for someone else, your client is the sponsor.

So now you’ve got a reason and you’ve got the cash. Would you just start building and hope for the best? Unfortunately in software design, many do. But if you’re building a skyscraper, there’s still a lot to do, right? Gathering up all the little reasons that this skyscraper will be better than the rest. Everything it will need to do. You’ve promised your potential tenants that their electric bill will never exceed a certain dollar amount because you’re putting solar panels on the roof. You’ve promised the city a train station in the basement. You’ve promised your investors you’ll be renting at 80% capacity ten weeks after the grand opening. Who handles all this in software design? The Business Analysts (BA) do. They produce what we in the software biz call requirements. What will this app be required to do. What business needs must it address to justify its construction? Let’s settle on a list of these many, many things that we can all agree upon. This final list is the requirements.

And who keeps it all on track? Who keeps things moving according to schedule and ensures the finished product meets the requirements? Two roles come in to play here and coincidentally, they are identically abbreviated.

The Project Manager (PM) oversees construction but moves on after the building is finished. They’re like the foreman of the construction site.

 

 

The Product Manager (PM) is like the building’s manager when it’s complete, overseeing all operations and coordinating all parties involved. They do NOT move on when the building is finished, but stay in charge of it indefinitely. The only difference is that in software design, the Product Manager is typically involved from inception and through construction.

 

Now things get interesting. You’ve got the why and you’ve got the what. Now all you need is the how. How will your skyscraper meet these many requirements? Answering this question takes a plan. A blueprint if you will. You wouldn’t just start building a skyscraper without first knowing what it should look like when it’s finished, would you? Sadly, many software development teams do just this. I have looked on in profound amazement as the construction workers rush in and start pouring concrete for a foundation to a building the size and shape of which hasn’t been decided: developers iterating on code no one’s even sure should or would be used: code that’s written before a blueprint for the application has been settled upon. And who makes blueprints? Architects make blueprints. In software design, these are the Information Architects (IA) and their blueprints are called wireframes. Like blueprints, wireframes are a schematic. They describe components and how they relate to each other. But IA’s don’t operate in a vacuum any more than building architects do. An architect may have a general plan for a building, but may not be an expert in construction material and methods. He or she may not understand the electrician’s job or the plumber’s. An architect may not understand interior architecture, interior space design, lighting, interior design or ergonomics. A stairwell included in the architect’s blueprint might be the most basic kind of stairwell. And others will be consulted as to its specifics or indeed, whether an escalator is more appropriate.

So now you’ve got a building with a number of darkened and empty or generalized interior spaces. Here’s where the User Experience (UX) Designer comes in. Just before construction was about to begin on a new building at Ground Zero in New York just a few years ago, the New York Police Department got a hold of the plans and stopped the whole thing in its tracks. The entranceways, they warned, were way too close to common public areas, making them much too vulnerable to a possible terrorist attack. The entire blueprint was scrapped and it was back to the drawing board for everyone. In its most drastic form, this is the kind of consideration it falls to UX to account for. The human component. Can this software ultimately be used by its target audience? Should this stairwell be a ramp? Should this screen be a dashboard or a wizard? Are these windows so close to the air conditioning units that they’ll produce a sound nuisance if double-paned glass isn’t used? Should these selections be made by radio button or check-box? Etcetera, etcetera. Typically, this just means adjustments to or elaboration upon the wireframe documents already produced by the IA.

What’s the difference between a UX Designer and a User Interface (UI) Designer? In many contexts the distinction is next to meaningless. It all depends on what you’re building. Is it an aircraft hangar or a luxury casino? Airplanes don’t care where they’re parked. People do. The differences between UX and UI designers are subtle, but critical. If you’re building a luxury casino, you’ll need both. The UX designer can tell you what kind and how many slot machines the main floor of your casino was designed to accommodate. How they should be arranged generally to maximize their profitability in relation to foot-traffic patterns. The UI Designer will compare this scheme to the other casinos in town and solve for user expectation in relation to these competitors. The UI Designer will solve for overall polish and curb appeal. How what these screens are trying to accomplish are translating over to what the user actually ends up seeing. This includes especially look-and-feel. In the UX Designer’s mind the gambling floor is a series of simple spatial relationships between types of objects solved for the gambler’s most general reactions to these. To the UI Designer, it looks like rows of fully-realized slot machines each eliciting very specific user reactions. Specific sights, specific sounds. If the UI Designer finds a flaw in the overall design, typically that complaint can be communicated to the UX architect, but not the IA so the wireframes are not impacted. If, on the other hand, the UX Designer finds a flaw in the overall design, that complaint CAN be communicated to the IA and the wireframes MAY BE impacted. You don’t need to redesign a lobby if you’re having trouble arranging the furniture effectively. You do need to redesign it if the exit violates a fire code.

The UI Designer often relies so much upon the Visual Designer to effectively acquit his or her responsibilities, these roles are often combined. Again, it depends on the scope of the software. If your product is competing with Microsoft, you’ll want both disciplines. If it’s competing with the IT Boutique up town, you may not. It’s yet again a very subtle difference that can best be illustrated by staying faithful to our metaphor. An interior space designer can tell you how the tables in your restaurant ought to be arranged for maximum efficiency. A visual designer can tell you what furniture to arrange and whether or not it fits into your restaurant’s overall theme (though they’ll probably have something to say about your arrangement, too). Each could probably do the other’s job to some degree of adequacy, but when your software must be professional on every level, the distinction becomes more important. The visual designer’s focus involves a much higher level of artistic expression. If the UI Designer spends SOME time thinking about look-and-feel, the Visual Designer spends ALL of their time thinking about look-and-feel.

When the UI Designer has decided where the fountain should go in the atrium and the visual designer has decided whether it should be futuristic looking or more baroque, someone has to come in and install that fountain. Someone’s got to hook up the water and the lighting. Someone who may not need to know how to construct a load-bearing wall, but knows where to find the water main and the fuse-box. Someone who might have put a ping-pong table in where the fountain is going, but understands this isn’t their call. This is the User Interface Developer. The UI Developer, in this analogy, is part plumber, part electrician and more. Not only does he or she need to install the fountain so it works, but must coordinate its automated functions with the building’s central computer so it knows not to run on holidays and to shut down in case of a water main break. The UI Developer is responsible for constructing every surface in the building with which a person might interact. They put up the interior walls, wire up the buttons in the elevator and hook up the lights in the drop ceiling. They lay the tile in the lobby and install the touch screens in the executive conference tables. They pick up where the construction workers leave off. In software design, the UI Developer is often handed the wireframe and a series of static images created by either the UI Designer or the Visual Designer that he or she must then “slice up” into HTML. But their job doesn’t end here. Interfaces for online software are frequently dynamic on the client side. This means that the interface is performing actions in response to user activity without calling the server’s database or functions. Analogously, you wouldn’t need the drinking fountains in the main hall to have to check with the building’s central computer whenever they thought someone wanted a drink of water, right? Better to just provide a stream of water when someone hits the button. And the UI Developer knows much better than the IA, the UX Designer, the UI Designer and especially the Visual Designer how to talk to the construction crew in charge of riveting girders and laying brick. The UI Developer knows that there is no way to have 20 more gas grills serving the restaurant on the mezzanine without changing the kind of insulation in the floor and applying for two more licenses from the city. Much as the UX Designer might want them there. Better to sort that out with the construction crew before any concrete has been poured.

And lastly, you have the construction crew. The guys who walk around in hardhats and tool-belts, welding steel beams, pouring concrete and raising exterior walls. These are your Developers (aka programmers or coders). They evince the same no-nonsense approach to their trade as real construction workers. They know building codes as well as they know the laws of physics. While they swing a pre-poured concrete piece of your parking garage into place, developers swing in Visual Basic objects (as in object-oriented programming) and lock them in with all the finesse and certainty construction workers do with spot welds and masonry. They gather in groups to solve problems but also jealously guard their own circle of expertise against pretenders and dilettantes. If the building’s architect came to them in a fluster halfway through its completion  and told them it needed a freight elevator that goes all the way to the penthouse, they’d laugh him out of their trailer, tossing doughnuts at him as he ran for cover. And rightfully so. Why wasn’t it in the blueprints? Why are we hearing about this now? The sub-basement was never designed to hold that much added weight. And on and on. “That’s gonna be an awful lotta overtime, pal.” Many developers I’ve known have objected to this analogy as limiting. Certainly there is as much strata of expertise among developers as there likely is in construction workers. Some know so much about the overall process, they could do the IA’s job for less ambitious projects and build-outs. Others are just nine-to-fivers content to rivet all day till the whistle blows. Certainly building architects are in consultation with construction experts from the project’s inception: Can this be done? Can the bedrock next to the river support this kind of weight? Have you ever built anything like this before and what special considerations are there? I’ve seen developers devise solutions to UX, UI and even visual design problems that designers missed. That said, you probably don’t want your developers telling you where to put the restrooms or whether the facade ought to be Art Deco or Neo-Classical.

Understanding the various roles involved in the successful creation of new software is the very first step in ensuring its success. Some roles can be combined, but only those similar to each other in the process. For any such project of significant scope, you wouldn’t have your Product Manager designing the UX any more than you’d have a developer creating original graphics. That would be like the building manager telling you how to design the buttons in the elevator or a construction crew painting the frescos in the lobby. All of the resources inhabiting these roles have something to give and none of them can do it all. The truest predictors of success in any online software effort, I’ve found, are the levels of both collegiality and accountability. If the lines of communication between each role are always open and none are favored above the others, then your only concern need be the talent of your people.

Ensuring this dynamic is the only way to making sure your “building” is the next Bird’s Nest Stadium and not the next OCAD Building.

Nice to know when you're thinking like the big boys

My last two posts separately covered the pitfalls of imitation and the importance of context. So when I saw that usability giant Jakob Nielsen covered the same two points in largely the same way in his August 23rd 2010 AlertBox it was as if Babe Ruth had come up to me and congratulated me on my swing of the bat.

See below for an excerpt ...

UI design fundamentals: Do you have the right stuff?

User interface design happens as surely as the sun rises in the east. It's inevitable. Whether you let your developers design your UI or your BA or your PM or an experienced user interface designer, someone or some set of circumstances is going to determine your user's experience of that software.

The only question is whether or not that experience will be a constructive one.

UI design is tough because it's highly conceptual and many of the other disciplines involved in software design are far more linear: They have beginnings, middles and ends. The temptation in some of these other disciplines is to decide UI design is sort of a fancy suit you dress your software up in to make it more presentable when it's all done.

True, UI design has its more superficial components: what is the color scheme? what will the buttons look like? what fonts should be employed?

But UI design is not JUST these things any more than a tasty cake is just the frosting. Effective UI design, to really extend the metaphor, is a crucial ingredient that must be mixed in from the beginning and baked into the process.

In the words of Steve Jobs, "Design is how it works."

Which means that if you're coming up with some new product, some new application designed to address a unique business need or client requirement, you have set about to determine how something will work. And if you're doing this, you are facing a number of unknowns.

One way to handle unknowns is imitation. How has another successful product handled a similar problem in the past? Imitation is a powerfully persuasive solution because it is presented alongside direct evidence of its viability: "See, if it's good enough for Microsoft, it's good enough for us -- case closed."

The problem with this strategy, of course, is that Microsoft or whichever other vendor's solution is under consideration may well have been boosted from some other application -- which in turn, may also have been boosted from some earlier application and so on. Bad ideas can persist in this way for years and the more they're copied, the more entrenched they become. If you're building software in a competitive market, you're not in the business of doing whatever everybody else does, you're in the business of getting to the exact right idea and enbracing it fully. When Firefox started eating Microsoft's lunch in the browser market, Microsoft's next version of IE featured tabbed browsing just like Firefox's. Do you want to be the copier or do you want to be the one being copied? As of this writing, Firefox has seized 24% of a browser market once dominated relentlessly by Microsoft. And this diversity has opened the door in the minds of users everywhere to the idea that some other player may be building a better mousetrap after all. As of this writing, Microsoft's browser marketshare is down to 59% and Google's Chrome and Apple's Safari are gaining ground every day.

So if you can't just do what the other guy is doing all the time, what CAN you do to assure the relevance and ultimately, the success of your software?

You have got to focus on what makes life easier for your users. To do this, you must understand their goals. For B2B, your user's goals all fall into one single category -- getting their job done effectively and moving on. They don't want to be impressed, they don't want to read your help files and they definitely don't want to call your help desk.

The single most important factor in determing the efficacy of any user interface, according to Human Factors International is SELF EVIDENCE. Which means the user's workflow has been anticipated by the application's designer, which means that whomever designed it considered the user and that user's goals.

This simple act of stepping outside ourselves and really looking at our product from the user's point of view is the first step toward delivering something they will want and use. Not taking this step in earnest is the best way to deliver a product that garners complaints and costs you references.

In an attempt to drive this fact home for a previous employer, I played the following scene from the 1981 film 'The Right Stuff' to a room full of stakeholders. I analogized the product to the space capsule and the users to the Mercury astronauts. The goal was to make sure no one could analogize our team to the NASA engineers as depicted.

"We want a window." A more poignant analogy for user frustration with a product that has failed to anticipate their needs does not exist. 

The press milling outside I analogized to the product's reputation.

So to all of those stake-holders in corner offices everywhere, and to those among them who think functionality is enough and reputation doesn't count, remember: "No bucks, no Buck Rogers."

Understanding your user's goals, in the end, is the only way to show YOU have the right stuff.

When Tuftean ideas get misinterpreted, "less is more" can run amok

Edward Tufte is clearly one of the most important thinkers in recent history on the matter of representing data visually. Letting data speak for itself means getting to its essence and dispensing with fluff that not only doesn't ADD to the informative value of graphs, charts, or diagrams, but actually SUBTRACTS from it -- leading the eye away from essential meaning.

Dispensing with fluff and getting to the heart of the data aren't always the same thing, however.

Tufte's ideas can often get abbreviated down to a "less is more" strategy. I know because I've made that mistake myself in my own designs on occasion. You think you're letting the data speak for itself and you get the feeling that if Dr. Tufte himself were standing next to you in that conference room as you all stared in amazement at the Powerpoint slide on the scrim in front of you, he'd slap you on the back, give you a hearty "well done, m'boy" and invite you out to the university as a guest lecturer. But your audience is scratching their head instead. Suddenly Tufte isn't the one standing next to you,  it's your third grade teacher and she's got the red marker out.

Why?

Well, sometimes when you're showing super-cool, cutting-edge Tuftean design to a room full of Microsoft devotees, anything that isn't blue with a fade and sorted into a box is going to be met with criticism.

But sometimes it's because less is often NOT more -- sometimes it's just LESS.

Tufte's ideas have helped me produce far more eureka moments for my designs and made them better received than any other single influence. But sometimes you really have to watch where that line is -- the line past which you've reduced away too much and let your interface design veer cold and ungenerous, if not downright alien.

When you have let your design drift in that direction, it's admittedly of some comfort when you realize other experts can make the same mistake.

Especially when it's the guy who designed the interface of the Edward Tufte Web-site!

Now THAT page was designed by someone who took Tufte's ideas too far into a less-is-more realm. The whole top half of that page looks like a site that lost its stylesheet.

Sometimes MORE is more and sometimes data can't speak for itself. As a UI designer it's up to you to give that data a voice and find that perfect middle ground.

Required reading for anyone designing software for humans

Discovered an extremely well-versed and well-spoken UX designer online yesterday working out of New York by the name of Whitney Hess.

There's an ad for some brand of cereal on TV lately in which a customer inquires of the store manager as to the product's quality. The gag is he's so used to fielding the same questions about the product that he anticipates every one of her questions before she has a chance to finish her sentences -- to her amazement.

 Upon encountering Whitney's observations, I felt a little like the amazed customer in this ad. I'm thinking it and she's saying it -- and way better than I ever could have.

Her Blog, 'Pleasure and Pain' has posted to it a presentation entitled 'The 10 Most Common Misconceptions About User Experience Design' that should be required reading for anyone endeavoring to create software for human beings.

I might have changed the title to something like 'The Top 10 Reasons Your Clients Aren't Giving You References,' but I suppose that veers obtuse.

Bravo again, Ms. Hess.