You are a bunch of elitist design snobs

Last night we held an incredible event at the IxDA conference. An opening party that included 2 DJs, a experimental digital marching band, a local band called Snake Rattle Rattle Snake, an open bar, and catering by the Top Chef winner. It was the best conference party I have ever been to.

I was asked to introduce the band, and I decided to say something about the state of user experience design to the group:

You are a bunch of elitist design snobs that only care about pretty pictures and fancy documents. When it’s all said and done, the world really does not care about design.

That’s what they were saying about all us five years ago. But over the last five years we have changed businesses, disrupted entire industries, revolutionized countries, and are transforming the world.

The nay-sayers have mistaken our passion for foolishness, our righteousness for arrogance, and our empathy for weakness. They wanted us to conform to the way things have always been. To comply with decades old processes that produced crappy software

People now know us as problem solvers, but that’s a half truth.

Yes, we solve problems. But more importantly, we effectively communicate the solutions…What we do is actually is one of the only true forms of practicing innovation.

Believe that what we do matters,

We are changing the world..

Software Planning and Requirements – Effective UI

Thought I’d share an excerpt from Chapter 3 of our book “Effective UI: The Art of Building Great User Experience in Software“. By far, this the most definitive explanation of why enterprises need to reconsider how they’ve approached software development in the past. RFPs, Fixed Bidding, Waterfall, all have dangerous implications to the success of any software project. Many companies use the wrong analogies when planning projects; they plan using construction metaphors. This chapter does a great job explaining that in reality, planning a software development project should be more like planning a war.

—————————————————-

Uncertainty and the Unknown

Uncertainty and the unknown are enormous, unavoidable, and fundamental components of every software development project. Being at peace with this reality means you can approach the project in a way that adjusts and flows to account for the unknown. If you fight uncertainty and the unknown—or, even worse, if you suppose they don’t exist—it’s a path to defeat.

The mistaken belief that uncertainty can be entirely stomped out through upfront planning and everything can be known in advance is the root of many of the worst problems and errors in the management of software proj- ects. This arises from the misapprehension that software development is com- parable to and can be managed like other types of large-scale engineering proj- ects—building a bridge across a valley, for example. Bridge building and soft- ware development both have components of science and engineering, and of art and craftsmanship. But the role of uncertainty and the unknown, and the way science, art, engineering, and craftsmanship work together throughout the course of the project are very different. Those differences demand a fun- damentally different approach to management of the project.

The notion may seem discouraging, but it’s much more accurate to compare software development to war than it is to compare it to bridge building. While the battle of software development is fought more with electrons and Mountain Dew than bullets and napalm, the battlefield is a complex, dynamic, unpredict- able system of activity residing in shifting political and operational contexts.

The Humility of Unknowing

I am the wisest man alive, for I know one thing, and that is that I know nothing.

—Socrates

To demonstrate how uncertainty and the unknown are inevitable compo- nents of a software development project, we’ll examine why the bridge- building analogy fails and the war analogy succeeds. But even with the aid of analogies, it’s extremely difficult to explain why uncertainty and the unknown are unavoidable to someone who’s never been in the trenches of a software development project. Much of the understanding comes from see- ing how design, creativity, and inspiration factor into every aspect of build- ing an application. It also comes from having seen how false certainty, and the demand for it, can cause failure and lead to poorly designed products.

It’s difficult to explain or prove this fact except to state it this way for now: you understand your project far less than you think you do.

And so do your stakeholders, by the way. For your project to be successful, you need to cultivate in yourself and in your stakeholders a certain humility and a recognition that, for as much as you know, you know very little, and that the essence of the project is to investigate and solve a complex problem and not simply to implement a known solution. Embracing this humility of unknowing isn’t a resignation to defeat or admission of weakness, but rather is a state of wisdom required to allow you to succeed.

The Weakness of Foresight and Planning

The great uncertainty of all data in war is a peculiar difficulty, because all action must, to a certain extent, be planned in a mere twilight, which in addition not infrequently—like the effect of a fog or moonshine—gives to things exaggerated dimensions and unnatural appearance.

—Carl von Clausewitz, On War

Everything required to design a bridge to a valley is knowable in advance and can be planned to an extremely high level of accuracy before construction begins. All of the important goals, variables, and constraints can be accurately obtained before design begins.

Once those key considerations have been discovered, the design of the proj- ect begins and can be entirely completed before construction starts. With accurate and complete designs in hand, construction is then all about ensur- ing the pieces all come together as designed. Construction is not concerned with any remaining questions about the design and isn’t burdened by the risk that the design will change during the course of construction.

By contrast, a general preparing for battle can estimate the strength and disposition of his forces, the resources and capabilities available to him, the attitudes and aptitudes of his commanders in the field, the lay of the battle- field, the strategic goals of the battle, the state of the enemy’s forces, and the parameters for success. He also has history and personal experience to help him intuit how events will unfold. Based on this knowledge, he can formu- late a plan for the battle.

But this plan, no matter how carefully devised, is inherently incomplete and imprecise. It is wholly premised on estimates of the conditions before the battle and entirely ignorant of the unforeseen conditions that arise during the battle. These unforeseen conditions are based as much on the vagaries of weather, emotion, chance, and uncertainty as they are on even the best-laid plan. This reality is the basis for the famous quote:

No battle plan survives first contact with the enemy.

—Helmuth von Moltke

The same is true of software development. No matter how well you think you understand the domain and no matter how earnestly you’ve thought through the requirements, there is still great uncertainty in the original facts and premises and a vast depth of the unknown still awaiting you. As with battle, the outcome will be determined at least as much by what comes dur- ing the course of the project as by what comes before it.

Not all unknowns are bad, by the way; it’s in solving the unforeseen problems that great design and inspiration can take place. Some unknowns may be rev- elations about your customers and users that fundamentally change how your business interacts with them, or they may be undiscovered opportunities for progress, innovation, efficiency, and improvements to your company’s bottom line.

—————————————————-

If you are interested in reading the whole chapter, you can download it here.

More excerpts are available here

Better yet, don’t be so darn cheap and just go buy the book here

A respectful disagreement with some good friends

Recently, my friends at Forrester Research published a great white-paper titled “Best Practices In User Experience (UX) Design”, by Mike Gualtieri. In it, Mike quotes someone who I very much admire Bill Buxton at Microsoft, author of “Sketching User Experiences,” who said:

. . . the last thing that you should do when beginning to design an interactive system is write code.

The point of this particular section was to warn program managers and development managers about the dangers of rushing into code too soon. I want to be very clear when I say this as to not be misunderstood : For most enterprises, this it the absolute WRONG thing to do.

In the last 5 years, we have developed over custom 250 applications, mostly for the Fortune 1000’s – and in every circumstance where we were not allowed to start coding early, we have experienced (to put it mildly), issues.

“Why?”, you may ask… 3 reasons:

Reason #1 : Integration

We are not architecting a building, which can be easily described in blueprints and executed in a waterfall fashion. Software is a complex and adaptive system that requires constant refinement and compromise. How do you know that your designs are going to have the data structures to support them? How do you know the legacy systems can handle the newly proposed business logic and user flows. Simple, you don’t, and can’t without early technical prototypes (aka – coding very early)

Reason #2 : User Feedback

Once you get developers involved, you can have them develop prototypes to test designs for utility, usability, and desirability. Paper prototypes and design compositions just to not have the tactile feedback required to truly measure how a user will actually interact with the software.

Reason #3 : Collaboration

Truth is, our developers often come up with some of the best interface design ideas for our clients. When you remove them from the early stages of design and user research, you miss out on a wealth of logical thinking. Having the team collaborate early will often save you a TON of money and heartache.

To give the benefit of the doubt to my friends above, I will say that the way many enterprises are coding today is not always effective. They are leading a project with developers, and design is often an afterthought … I’ve heard, on many initial client calls:

We are all done with the code, its really good. But our executive team does not like the way it looks, and we are getting feedback from our beta customers that the software is hard to use. Can you guys take the next two or three weeks and skin the application to make our executives and users happy?

Microsoft’s Bing kicks Google’s behind

At the surface, Microsoft’s Bing may look like Google, but once you dig in a bit you notice a lot of nice little enhancements that make a huge diference.

Microsoft's Bing Search Results

I’ve only been using Bing for the last 2 hours and I’ve already decided it is my new favorite search engine. The search results look very similar to google’s, but  Microsoft’s added a ton of little useful features. My favorite is the left sidebar with search history and related results. I also really like the pop-out details you get whenever you hover over any search result. The site is very ease to use, but obviously has a lot of deep complexity in its design; a lot of “spit and polish”. Small things you may not even notice, like how the image search’s counter (IMAGES;”>1-16 of 1,510,000 results) will update as you scroll – pretty nice little feature that I’ll miss if I ever go back to search images on Google.

If you agree that Bing is useful, you may get frustrated if you are a Mac user because you can not update your Safari search bar to default to Bing. Luckily, I found a helpful little utility and how-to that remedies the situation.

I know there may be a temptation to argue the quality of the results – that somehow google’s search algorithms are somehow better and more sophisticated. First, good luck with that discussion, the results I am receiving are just as good as I get from google for my “real world” use . Second, who really cares? There are countless studies from Forrester and Gartner that prove people value ease of use more than they value content. Bing has the “ease of use” thing down. It’s pretty ironic because Google beat out Mapqwest’s user experience years ago with Google Maps, but they failed to innovate in search UX and now have been leapfrogged by Microsoft.

It is obvious to me that Microsoft has a renewed focus on user experience. Thy are investing heavily in us (the end user) and that investment is truly paying off.

Our site “sucks” no more!

Well, I am excited to say we have launched our new website:

http://www.effectiveui.com/

In an earlier post, I talked about the difficulties we were experiencing with designing and building our own website. I think, given our company objectives, the team hit a home run. What did we want to accomplish?

Form VS Function

Obviously, the site needed to “show” what we do rather than just writing clever copy  & creating pretty graphics (not that wit & sex appeal aren’t important – something that I lack on both counts). We fundamentally believed our site needed to be “rich” while also delivering the appropriate marketing messaging. We are a little worried that our site might make us look more “interactive agency” than “user experience agency”, but that is a hard line to balance.

Message

We really needed to overhaul our messaging. We have changed quite a bit over the last 3 years and our previous site made it very difficult to highlight our focus on the 3 key areas all good UX companies care about: strategy, design and technology execution.

Tactical Marketing Objectives

The team did an awesome job doing things you may not notice, like creating a flash based website and make it easy to update the content. They also incorporated deep linking and HTML/Flash mixes in a very sophisticated way. I’m really proud of the way this thing was built.

I’d love to hear your feedback on how you think we did. Go easy though, I do bruise easily :)