I think most would agree that the general state of web site design is still in its infancy, at least as practiced by most companies. While there are some notable exceptions, many sites, even from major players, are often either very difficult to use, downright ugly, or both. I’ve been thinking a lot about this lately, and I have formed some theories as to why so many sites are bad, and what it will take to make this a better world as we all spend an increasing amount of our life interacting with the web.

I have long noted that too few companies invest the time and resources in user experience that they should, and I plan to focus more on that general topic in the coming months. However, what I’ve had a harder time explaining is why companies that do invest still often have such bad sites.

Two edge cases in particular struck me as interesting. On the one hand, so many of the graphic/visual design firms have these beautiful, artistic sites, that are difficult to read and poorly structured. On the other hand, many of the interaction design firms have very usable sites that are easy to navigate and find the info you need, yet are boring, primitive and unappealing.

I think what these two cases illustrate is that the disciplines of interaction design and visual design are very different and that to have a site that is both usable and appealing you need both skills on your design team. Some teams are very lucky and they have a designer that is talented at both types of design, but in more cases I think they just expect that since they hired a “designer” that person should be able to do both, and they can’t.

Even worse, but most common of all, is when the company has neither type of designer, and they look to either the product manager or the UI/Web engineer to design the site. When I talk to enterprise companies this is unfortunately still the norm. When I talk to consumer companies, they usually have one or the other type of designer.

Many teams feel that the visual design of a product or site is not really important. They argue that what matters is the functionality and the value proposition, and that things like nice colors, fonts, icons and layout are just unnecessary and superficial fluff. I strongly disagree with this view, and the more products I see the stronger I believe a) in the role that emotion plays in successful products; and b) the direct role visual design plays in creating that emotion.

You can show the exact same functionality to a user, one with wireframes and one with a good visual design, and the overall response can be dramatically different. I’ll discuss this in more detail in a future article.

Much like product management and product marketing are different functions requiring different training and skills, interaction design and visual design are different functions requiring different training and skills.

I have oversimplified somewhat here. I haven’t discussed the critical roles the product manager or usability engineers play in coming up with a site that is both usable and enjoyable. And if the site performs like a dog, or is riddled with bugs, or is littered with advertising, then that will of course impact the experience in a big way too. But fundamentally I believe you need both interaction and visual design skill sets to deliver a good user experience, and that these people need to work closely with the product manager to define the product, which includes both the functionality and the user experience.

Email to a friend

Sign up for the free newsletter here.

In many product organizations there are problems between product and marketing. The problems might range from mild friction to downright dysfunction.

In theory, there shouldn’t be a problem. The product team is trying to create a product that customers will love, and the marketing team is trying to find these customers and convince them to come give it a try. It sounds straightforward enough, but in practice it’s not so easy.

While I often emphasize that product management and product marketing are very different functions and best served by different people with different skill sets, I wouldn’t want anyone to think that marketing isn’t critically important, because it is. Further, it’s not enough to have talented people in both product and marketing. These people must collaborate effectively for the product to succeed. Together, you must come up with a recipe for product and messaging that effectively meet several competing needs.

There are three pieces of the product/marketing puzzle:

- First, you have to decide what you’re going to tell your prospective customers in order to entice them to visit your site. It has to be simple enough to be easily understood yet compelling enough to attract.

- Second, you have to understand your target customers enough to know where to reach them to tell them about your site (and/or make it easy for others to do so).

- Third, once the prospective customers visit, they have to like what they find when they get to your site. The product needs to support the messaging that attracted them. It’s ok if the product actually does more than what’s expected, but it must at least meet the user’s expectations.

All three of these have to be working well for your site or product to succeed.

If you have a great message but the product doesn’t support it, users won’t return. This situation is all too common. This may be due to the product not having a value proposition that is useful, or it may be due to the marketing team not understanding or appreciating the value proposition (if this is the case, don’t blame marketing – you likely need to fix your value proposition), or possibly the marketing team gets tempted by compelling messaging, and/or is measured by delivering prospects rather than satisfied customers.

If you have a great product but your messaging isn’t compelling, users won’t know it because they won’t visit to find out. Even with a great product it can be tough to come up with simple, clear yet compelling messaging. You need enough so that the prospective customer clearly understands what you do and why he should care, but not so much that he gets overwhelmed. One tip is to realize that you don’t need to describe everything you do. You can just highlight the one or two major benefits that resonate the best.

Even if you have a great product and great messaging, you still will fail if nobody knows about it. Effective marketing programs can have a dramatic positive impact on your product’s success when the marketing team understands the different target customers and knows how to reach them with a compelling message.

So all three have to be working well – you need a strong value proposition that is well supported by the product and you need to get the word out to the people that will care. The only way these three things will happen is if product and marketing work effectively together.

Email to a friend

Sign up for the free newsletter here.

Normally I focus on the product definition aspects of creating successful products. My reasoning is simple: it doesn’t matter how great a job you do in building your product if it isn’t the right product. That’s really the role of the product manager; to define the right product at the right time. However, there is one little detail that too many product teams seem to miss, even when they define an otherwise excellent product. That is, the product has to actually work.

I wish that by now, after roughly 30 years of “modern” software development, we wouldn’t have to keep talking about this, but in truth, while there are many notable exceptions in well-run companies, the state of software quality in general is still awful. During the boom times of the nineties, when Internet sites were developed and launched in a just months, with little concern for quality (“just call it a beta!”), this was an especially severe problem. Things seemed to get better for a while, but now I fear we’re on a downswing again.

I’m pointed to new products and sites almost daily, and I get so frustrated when the quality issues are so bad that they completely obscure what great innovations or contributions may lay behind them.

Largely this is due to the general state of software QA (quality assurance) in our industry. There is a huge chasm between best practices and common practices. For engineering teams that know how to design and build for automated testing, and know how to measure quality and ensure against regressions, the tools and practices are well established and the results are real.

The problem is that far too many teams still are doing little better than was done a generation ago. Testing is all too often still manual, the priority of the testing is so low that it’s the first thing to get cut in the rush to launch, the QA organization is understaffed and especially undertrained. The logic goes like this: this site is for teenagers, so lets hire some teenagers to run through the site and find bugs. I’m all for giving teenagers jobs, but a) this is no substitute for the knowledge of how to systematically and rigorously ensure that a release of software meets the specifications; and b) manual testing quickly breaks down when you are turning out new builds faster than you can manually test the product (which today is almost always the case).

Typically, the product manager worries about the spec, and the engineering manager worries about delivering a quality implementation of that spec. However, the product manager is ultimately responsible for the success of the product, and if the quality is so poor that the user experience is severely impacted, then it’s essentially the same problem as if the features are the wrong ones.

This doesn’t mean that the product manager needs to micro-manage QA, but it does mean that the product manager needs to take a very active role in defining release criteria, including and especially software quality. There’s nothing wrong with the product manager asking his engineering or QA manager colleagues questions about the QA staffing, funding, and testing process.

The irony is that too many engineering teams still believe that modern software testing practices cost more money or take more time than doing it manually. If done properly, you’ll find significantly faster time to market, more productive QA staff (with greater job satisfaction), and most importantly, a much better user experience.

Most types of software don’t need to be perfect, but remember that it’s all about the user experience. If the product is a mess, with bugs constantly getting in the user’s way, then your product will suffer. If this is the situation you face with your product, you’ll need to argue for fixing the problem at its core, investing in QA staff, tools and process, and prepare to trade off some new features you want so that your engineering team can have the time to clean up the product.

(Can you tell that I just wasted several hours doing battle with a product from a company that clearly has no clue? ;)

Let’s hope that someday soon a note like this will no longer be necessary.

Email to a friend

Sign up for the free newsletter here.