User Experience

On the use experience team you are going to control the feel of the product.  Will the user achieve their goals seamlessly or will they be frustrated and start looking for more problems? So what can you do?

• Fail fast.  It’s way faster for you to test UI on paper with users than it is for any developer to code it up.  And if the experience on paper doesn’t work you don’t have to rewrite code… which leads to quality problems.  Just refine it offline until you have a winner. Only winning designs should move onto development.  Trust me… you’ll still have to iterate once it’s been implemented anyway… but you can minimize this up front.
• K.I.S.S.  Unless you work for Microsoft your team does not have the resources for complex features with lots of options.  I love brainstorming new, exciting UI, but most of the time it’s not worth breaking conventions for unless you have a lot of time for testing. Stick with what’s worked on Google, Amazon, & Facebook for the last few years. 
• Performance is quality and while animations are fun they CAN NOT get in the way of the user. They are there to reinforce the user action and the user shouldn’t ever be waiting for one to finish.
• Keep those blinders on and stay focused on the feature/flow you are working on.  I’ve seen UX people and designers get sidetracked all the time by looking into surrounding UI, features, and issues. Take a note, save it for later, and move on.

Marketing

Like the sales team you also own the first touch so your role is also critical in the users perception of quality.

• Pull the right customers in.  If the message you are sending about the product isn’t pulling in the customers your company/product is optimizing for then those people are going to be frustrated users if they make it through the sales pipeline.
• Show people the product.  Maybe it’s because I’m visual, but there is nothing worse than a company site that doesn’t have the product described in pictures at least.  Ideally there are also quick videos that explain how you are going to solve my problem.  If I can’t see the product and it’s hidden behind stock photos of happy customers then I assume you are somehow ashamed of the actual product… and I should be ashamed to run it as a customer… so I’ll look for more issues.
• Make your message a WHY.  What’s the cause or belief that you want everyone to be able to convey in their work?  It will give people focus on what is really important since not everything is equal.  Telligent, for example, lives and breaths social customer communities.
• Keep people on message – At a small company you probably own both internal and external communication.  It’s critical that everyone is on the same page about the solutions the product aims to provide since everyone will touch customers. 
• Test your messages and your WHY. Test them internally and test them with customers before you finalize them.

Part 4 will look at the role of PM’s & Leadership.

Consulting Services

If you sell additional services, and code enhancements in particular, then you also own the quality of the product that was shipped. Your on the front lines working every day with a customer who is perceiving the final experience of the product through all the customizations and integrations that you have implemented for them.

• Customizations and integrations require just as much of a test plan and unit tests as code that ships with the product. Anything I previously said about how development team members own quality applies here for the improvements.  A customer will never differentiate between groups at your company… good and bad perceptions apply to everyone.
• As experts you are engaged to prevent customers from shooting themselves in the foot.  This applies to technical choices (deploying on underpowered hardware) AND softer choices about site policies and configuration (requiring too much information to register).
• The goal isn’t that customers are up and running… it’s that customers are achieving what they set out to do.  Because if they aren’t achieving their goals then your services are easy to blame… quality of experience is key and you helped set them up.

Customer Support

I work with some outstanding support people that exemplify the traits below – they own product quality to.

• Quickly gathering information and reproduction steps for bugs that are reported… and making sure the bugs are fixed quickly.   Make sure your product team is accountable for fixing at least 90% of the issues that are reported in each next release.
• Identifying support trends and forcing the team to address them… each quarter the product team should be looking to address “supportability” by looking to reduce the top time consumers of your support team.  It may not be a bug… it may be confusing UI that customers call about frequently… which costs everyone money.
• Communication and closing the loop is critical. Like the lonely tree, If something is fixed in a service pack it doesn’t do any good if the customer that reported the issue doesn’t know it’s been addressed.  This is really hard to do well.

In some ways your goal should be to eliminate the need for your job… except that if you do this well your company will have more customers to report issues… and you won’t need to hire an army to support them.

Part three will look at the role of the User Experience & Marketing teams in product quality.

Me: “We’re responsible for the quality of the product.”

Test Manager: <Laughs>

Me: “Then who owns it?”

Test Manager: “Everyone – the job of the QA team is simple to accurately measure the state of product quality consistently.”

It’s true.  The QA team does not own quality. They are there to accurately measure the state of quality during the development cycle… but real quality is actually a perception formed in the minds of your customers about your product.  The reality is that everyone who touches a customer at your company is responsible for their perception of your products quality. Now lets examine how different roles own quality.  Because no one reads really long posts I’m going to break this up.  Hat tip to Jim Holmes… who inspired this series.

Part 1: Sales and Developers

Sales & Account Managers…

You own the first touch before I may have even seen the product. If no one gets back to me for weeks then I assume that no one would follow up on any issues I may encounter.  If three people get back to me with duplicate questions I assume you can’t properly coordinate basic ownership… let alone product development as a company.  I recently had a company that didn’t get back to me… but did add me to their company mailing list.

Once we’re working together (customer & sales) I form my product expectations from you.  If you say I’ll get the following features & values out of the product then my expectations have now been set.  I’d rather be told “No, we can’t do that today.” than “Yes” followed by months of frustration trying to make the product do something it really can’t do.

This means you have to know the value props and product features like the back of your hand… and be OK with being honest when the answer is “no”.  As a customer I’ll respect you more for that… and will probably come back when I realize a competitive sales person miss-represented the product to me.  You do not have to know how the engine in the car works… but you have to be able to tell me if I’ll go 0-60 in greater or less than 10 seconds.

Developers/Engineers…

You are building whatever it is your company sells and you’ll be the first ones blamed (right or wrong) when something goes bad for a customer.  Entire books and blogs have been written on the subject, but I’ll try to highlight a couple of bullets:

• Demand clear expectations or clearly set and communicate them yourselves for overall functionality, performance, security, and scale.  Get clarification on what the non-happy path behaviors should be.  Never assume. An assumption is a customer that’s going to have their expectations set incorrectly.
• Write tests that validate these expectations.
• Write code you would be proud to print in a book.
• If you see complex code… simplify it. Understand what complex code looks like… there are any number of tools available to you that you can use to measure it with.
• Understand the problem your feature is solving, the user goals,  and WHY you are building what you are building.

Part 2 looks  at Consulting Services & Support.

Lets look at the edit icon for example:

Since this is a PhoneGap app it’s rendered in Webkit.  Webkit treats all screens as if they were normal DPI. So 1px on an iPhone 4 is actually 2 retina display pixels.  On the page I used the following HTML:

<div id=”goalEditButton”></div> <!– To represent the edit icon. –>

Then in the CSS I do the following:

#goalEditButton

{

height: 16px;

width: 16px;

background: url(./themes/apple/img/edit.png) no-repeat; // This is actually a 32×32 image

-webkit-background-size: 16px 16px;

}

The 32×32 image is used so the pixel resolution is doubled when it’s forced down to 16×16.   Of course if you want to save some load time for lower DPI screens then you’ll need to have a CSS file specifically for each case and switch between them ala:

<link rel=”stylesheet” media=”only screen and (-webkit-min-device-pixel-ratio: 2)”
type=”text/css” href=”retina.css” />

If you want more information and even slicker techniques (leverage jquery to switch images automatically) then I recomend reading the following articles:

http://blog.iwalt.com/2010/06/targeting-the-iphone-4-retina-display-with-css3-media-queries.html

http://aralbalkan.com/3331

• The packaging was minimalist, but not a joyful experience like unboxing an iPhone.
• The remote and base station, however, feel like they have a place in your entertainment center.  The proper weight and “shinyness” make it an attractive alternative to the 5 remotes you are about to put in a box.
• The setup of the PC software took about 20 minutes to run before I could start configuring the remote. It seemed stuck on the part where it connected to the internet so it could have been an issue with my connection.
• Once I could configure the devices the hardest part was looking up my model numbers.
• I was shocked it had my 12 year old Sony amp and knew all the commands that the original remote had. I don’t have to get off the couch to set the base level now!
• I was also shocked that I had to use my current Tivo remote to make it understand the Tivo button.
• On the first pass it set up the proper macros for basic things like “watch TV” and they worked like a charm. 
• It took me a long time to figure out how to create a truly custom macro. The option was hidden as a radio box choice.
• The first thing my wife said was “I thought it would have a picture of Duncan (our dog) on it”. 
• The second thing she said was “Why does it need a power cord?”  I’m personally hoping that it stays charged for decent stretches of time.
• I realized I’m spoiled by the awesome iPhone touch screen so I wasn’t as impressed by the screen as I was hoping I would be.

Having said all this, I’m a big fan.  The configuration is 100x easier than entering all those arcane codes into remote controls.  Its unfortunate that Logitech doesn’t spend a little more time on the configuration software since you don’t get that first “This is awesome” experience until about an hour in when you test the “Watch TV” command.  I wish the software had that feeling as well. 

The lesson here is that you’ll get people to write blog posts about your product if you can get them to say “Wow” in the first hour of using it. 

Now I’m just hoping that our dogs are past the whole “oh, a shiny dog bone!” stage so I can keep this thing around.