About a year ago I saw a google executive, Vince Chirico speak on a panel at a local conference. One of the things that stuck out from that session was what he said about Google’s philosophy on how it builds new applications. He said:

Google focuses on Utility, Usability, and Monetization. And in that order

Every Google application has had deep thought given to what features would be best. Once the application is near feature complete, they look at usability. Usability is the secondary priority.

I was chatting with John McRee, one of the authors of Effective UI: The Art of Building Great User Experience in Software, about how that model is a bit broken. And, more importantly, how they are missing a critical piece of developing effective software, user experience. We often talk about the difference between usability and user experience and John just blogged about it. Well worth a read.

But even if Google’s divine trinity is good enough for them, is it in the right order? Should usability come after utility? I think if you are evaluating an application you can say that without utility is is not useful. But I would argue that without usability, it does not offer utility. When developing software, shouldn’t we have the conversation about utility and usability at the same time? And can’t we do better? Can’t we also make the software enjoyable?

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?

First, “suck” is too strong a word. The original goal when we developed our site 3 years ago was to show what we do rather than try to describe what we do with fancy marketing copy. The site certainly does that – we often hear:

“I went to your website and instantly understood what an RIA is and how you guys were different” 5/12/2009


Ironically, we’ve even been asked, by several very large software companies, to license our tile navigation components for their own use. 


I’m certainly not trying to defend the user friendliness of site – it certainly suffers from usability issues and it can be a bit challenging to fully navigate all the content we have up there. But I don’t think it is a necessarily a clear example of a Flashtastrophe (as claimed here)  . I think you either love it or hate it. 


So, how did a self-proclaimed, user experience agency wind up with a site that has challenges?


Wrong Tool For the Job

Our initial objective for our website to show what we do. That meant we had to come up with a flash-based, “RIA” solution. However, HTML is often the better tool to create a marketing website. We preach to our clients “just because you can, does not mean you should” and our site is a direct contradiction to that philosophy. We were stuck between 2 opposing business objectives.


Plumber’s Sink Syndrome (aka cobbler’s shoes)

As we’ve grown our company the last 2 years, our website has always been something we’ve wanted to re-address. We’ve continued to hire amazing design talent, telling ourselves that we’d put these great experience designers to work on our own site. However, the demand for our services has been larger than we could have ever hired for, and our own marketing initiatives have had to suffer. Trust me when I tell you that Rebecca (our former CMO and now CEO) and Chris (our director of marketing) have been begging for time from our design talent. Just as a great plumber has no time to fix their own sink, we have had no time to properly focus on our own site



Too Close

The people at EffectiveUI (as you could imagine) all have very strong opinions on what our site should be. People passionately dislike the current site. In fact – we use our website as an interview question for designers and developers. We ask “so, what do you think of our site?” – If we hear “I love it”, it almost always excludes that person from being a great fit. Once we had an interviewee say “EffectiveUI my ASS!”  – although he didn’t have the skills we were looking for, he certainly had the right hutzpah. These passionate opinions have made it difficult for us to get consensus on what the site should be. The team is all a little too close to our company and what “they” want from the site – it is VERY difficult to take the proper, objective view of the site’s goals when its your own site. I believe this is the reason why most other interactive agencies’ websites suck as well :)



Outsourcing was not an option

If we did not have the time or the objectivity internally, why didn’t we outsource it? We debated this for quite some time actually. Outsourcing is the logical choice. It allows us to focus on our customers and brings in an objective third party to help us drive consensus across the organization. But, to be blunt, we were worried about the negative PR we would receive if it ever got out that we outsourced our own website. We ultimately decided that we had to figure out a way to do it internally.



Once we started treating our website re-design as though it were client driven, rather than an internal project, we started to see some great progress. 


No excuses – I know that the site needs work, and that we have let it go for far too long. But cut us a little slack, the rest of our portfolio is pretty awesome :)

Predictably Irrational: The Hidden Forces That Shape Our Decisions is a brilliant book – a must read for anyone trying to understand people’s decision making processes.

The book outline written by Bill Odom sold me (thanks for the referral sean) … a little excerpt:

The Power of Price
Why a 50-Cent Aspirin Can Do What A Penny Aspirin Can’t
The placebo effect is well-known and real. It’s not just a matter of fooling oneself; placebos can actually trigger endorphins and opiates and other biological reactions that actually change body and experience. What is interesting, however, is that price has an impact on efficacy.
Ariely, Waber, Shiv, and Carmon made up a fake painkiller, Veladone-Rx. An attractive woman in a business suit (with a faint Russian accent) told subjects that 92% of patients receiving VR reported significant pain relief in 10 minutes, with relief lasting up to 8 hours.

  • When told that the drug cost $2.50 per dose, nearly all of the subjects reported pain relief.
  • When told that the drug cost $0.10 per dose, only half of the subjects reported pain relief.
  • The more pain a person experienced, the more pronounced the effect.
  • A similar study at U Iowa showed that students who paid list price for cold medications reported better medical outcomes than those who bought discount (but clinically identical) drugs.
  • A further study on SoBe Adrenalin Rush showed that students at the gym reported less fatigue when told that the drink was more expensive.
    • And this wasn’t just self-perception. Ariely gave the subjects a 15-question puzzle as well.
      • The control group that didn’t drink SoBe got 9/15 correct
      • The “expensive” group got 9/15 correct
      • The “discount” group got 6.5/15 correct
    • One more variation: Ariely printed “Drinks such as SoBe have been shown to improve mental functioning” on the cover of the quiz booklet, and referred to 50 scientific studies showing its efficacy.
      • The “discount” group improved their score by 0.6
      • The “expensive” group improved their score by 3.3…in other words, they did better than the control group!
    • The effect declined when subjects were asked to stop and reflect on the relationship between price and quality. They were far less likely to assume that discounted drinks were less effective.

Amazon Link

For the last year, the industry been hearing a lot about designer developer workflow. Both Adobe and Microsoft are developing tooling that enables designers and developers to integrate more effectively, and iterate on software more rapidly. Let me ask a question that seems obvious: So What? Who does this “rapid iteration” serve?

Look at Adobe’s own diagram for RIA workflow:

Ironically, this diagram does not show true iteration – it only accounts for “design tweaks”. Where’s the business requirements? Where’s the measurement of milestones? And… the most important question, where is the person that the software is intended for?

I’m not completely dense, I realize that Adobe’s diagram is not intended for for use as a project planning roadmap. They aremerelyshowing how CS4 fits into an RIA project – (folks at EffectiveUI often look at our public facing process documentation and complain that it is too simplistic or not entirely accurate – truth is, every project we do is unique in its own way so it is impossible to accurately & concisely diagram any realistic software process)

Where was I …. oh yeah – workflow…

It is easy to get stuck in the tooling and forget about the end result – to value process and the technologies over the final product. There is a shift happening in our industry – I would say we are trending in the right direction. New workflows are forcing designers and developers to collaborate – why is that good? Because it forces humility into the process. In the software creation world, “Big Egos with Big Ideas” rarely produce “Big Wins”.

A Healthy Conflict

Our projects are lead by 2 types of architects. One is technical, of course. But we do not categorize the other architect as a “designer”. Design is just a part of the overall objective. We’ve adopted the term “Experience Architect” – Both architects are held accountable to 2 goals – 1) end user satisfaction and 2) ensuring a business success. While the Technical Architect focuses development architecture and legacy integration, the Experience Architect focuses on the end user and the business and user goals as well as brand consistency and aesthetics.

I have yet to work on a project where no compromise is required. Designers will always need to make compromises because of technical or integration limitations – development will always need to make compromises because of what the end users really need. Where I’ve seen projects fail is when one department is given priority over the other. When design “owns” the initiative, you can wind up with software that looks amazing, but is ripe with performance issues. When development owns it, you can wind up with software that performs, but is not usable. When both teams are equally subservient to the user and business goals – they are forced to work together.

There are some surprising results from this type of structure … interestingly enough, developers have good ideas for usability, and designers can challenge development into new ways of thinking.

What about “me”
It is time to look beyond mere team collaboration; we need to involve the people who the software is intended for. We need to listen and have empathy for those we are creating for. I know – not an original concept… but we must keep saying it until it is heard. New workflow improvements only get us half way there and do not ensure highly usable software…

%d bloggers like this: