June 25, 2011
Sometimes when I'm struggling to complete a task on a website (or am watching my wife throw her arms up in frustration), I ask myself "What genius decided to build it like that?"
Having been on the other side of the web design fence for some years, I've come across many reasons why web sites or web apps don't always work exactly as users would like them to. Let's take a look at some of the main reasons why these seemingly 'bad' design decisions get made.
After all, it's not like the web team is setting out to create a bad user experience. However, when it happens, more often than not, one or more of the following factors has a part in why.
In my experience, the main reason poor design decisions are made is because web teams have too much work on their plates to spend the time needed to go through all the steps of the design process (user research, card sorting, paper prototypes, wireframes, usability testing, etc).
It's not that web teams don't want to perform these steps; it's just that they have so much to take care of — managing existing web properties, working on a range of new development projects, dealing with stakeholders and clients — that they just don't have the time.
More often than not, the designer is forced to do the best they can based on their judgement and whatever best practices they can find from whatever research they can fit in.
Even if a web development project doesn't have a fixed deadline (which is rarely the case), there comes a time when you have launch in order to move on to other work.
I don't recall a project where we've said "Yes, that site or application is perfect. Let's launch." Instead, you end up identifying the fixes and improvements that can wait until after launch and adding them to a post-launch punch list.
Of course, given that you'll be moving on to other projects once the launch is complete, it's not a given that the punch list will ever be completed.
Never discount the importance of the HIghest Paid Person's Opinion (HIPPO). It's not uncommon for the web team to arrive at a design direction or decision, only for it to be overruled by the head marketing honcho or another exec.
In my experience, when reviewing a web design mockup, few stakeholders will pay much attention to content or support of user goals, instead focusing on the overall visual design, branding, color scheme, and so on. And if some or more of those elements don't match their personal preferences, it's back to the drawing board, regardless of how well the design functions from a user standpoint.
It depends on the individual, but for those of us with families to feed and ongoing work relationships to maintain, you have to pick your battles carefully. Sometimes, the safest option from the standpoint of personal self-interest is to 'follow your leader' even if it is not necessarily in the best interests of your users.
Chances are, not everyone on the web team is a star performer. There comes a point where you can only iterate on a design or piece of functionality so much before you have to implement it in order to meet the project deadline.
There are certainly times when I've been driven to giving pixel-level art direction, all the while being conscious of how this is taking me away from other duties. Being well aware of the law of diminishing returns and the need to get this piece of work done, eventually you have to decide that it is good enough, even though you know it's not at the level of quality you would like.
A phrase I like to keep in mind is that "the perfect is the enemy of the good." Many times, although you would like a piece of design to be "perfect", more often than not "good" is sufficient for your users, and it is not worth the extra time and effort elevating it beyond that.
Being part of a service organization and with people's interpretation of design being so subjective, you can't just ignore the input of your clients, whether they are internal or external.
Consequently, web design projects often involve compromise and give and take. As the representative of the web team, you have to decide which areas you are going to fight for and where it's worth giving way. Again, keeping the needs of your users in mind, it can be better to give in to small bad design ideas if that means you can say no to something that you feel is more important.
This won't come as a surprise, but the goals of an organization are not always aligned with those of its users. Businesses want people to sign up for newsletters, view ads, provide personal information, etc, while the user just wants to complete their task as quickly and as easily as possible.
This can lead to design decisions that further the interests of the organization (pop-up signup forms and interstitial ad pages, anyone?) at the expense of the user experience.
The organization may also have security goals that come at the price of user convenience. No one wants to put CAPTCHAs on registration forms or require customers to create strong passwords or answer multiple security questions; sometimes it's just necessary to prevent against malicious attacks.
Web teams rarely see their users and customers, and so it's incredibly easy for them to become isolated from their audience. Website users are seen as aggregated numbers in analytics programs and not as individual people trying to accomplish goals on your site or application.
Combine this with the issues of having too much to do and not enough resources, and you have a potentially serious problem where the web team designs for themselves or their internal stakeholders and not for their users who may have considerably different design requirements.
Not every website out there is operating on the latest content management system. Sometimes, the limitations of the technology being used to manage the website mean that problems with it remain unresolved and improvements cannot be made without a significant investment of time and effort.
If these issues are small or are not easily fixed, you can end up with an increasing backlog of needed improvements to the site which may only be resolved by moving to a new platform or CMS. And you know how long those projects take.
These are some of the factors that I've come across in my experience that lead to bad web design decisions being made. If you have any others that you would like to share, please let me know in the comments.
Posted on: June 25, 2011 | 5 Comments