This is not a criticism of clients, however. There is so little information that clearly defines their role. Sure, there is no shortage of material on usability, accessibility, online marketing and copywriting, but who has the time to read all of it?

…

One of the biggest problems in most web projects is that the client starts making the decisions that are best left to the web designer. Not only does this lead to bad decisions, but also inevitably leaves the web designer feeling undervalued and frustrated.

This problem can manifest in a variety of ways, however ultimately it comes down to a single issue – the client is trying to find solutions to their problems instead of relying on the web designer.

…

The most obvious occurs at the design stage. After seeing your design the client comes back with comments such as ‘make the logo bigger’. This is their solution to a problem that they have with the prominence of the branding. If they had expressed the problem instead of the solution, it would have enabled you to suggest alternate approaches. Instead of making the logo bigger, you could have possibly added more whitespace or changed its position.

I highly recommend the read. It also looks like the blog post author wrote a book called “The Website Owner’s Manual“. Maybe I’ll have to get a copy and see if it is any good.

Related posts:

1. Software Development With Clients In Mind
2. Great PHP Article: Leadership in Software Development
3. Web Design & The Cookie Jar: When Dealing with Clients

I’ve been searching for awhile for a good example for this subject, and when I saw this sketch, I knew this would be perfect. It outlines two large problems with developing solutions for clients: quality & suitability.

In the sketch (transcript avaiable) each architect presented their solution. One was very well designed with high quality in mind. The second solution was well suited for their needs, but obviously has a sub-par quality. Which brings us to the conclusion, which solution did the developers pick? The poorly designed one of course! Why? Suitability, how well somethings fits, comes before quality for consumers and clients.

These seems rather obvious, but in-fact many developers get caught up in quality and then are totally surprised when their clients aren’t happy. Why? Because as developers we notice and respect quality a great deal more than suitability.  However, clients rarely consciously notice quality. Sub-concisely they’ll notice speed, performance, bug-free, etc. However, they don’t really realize it, it is just something they come to expect. If a software solution doesn’t suit their needs as they would like, no matter how high of quality the solution has, clients and consumers will think its poor quality.  So how can we deliver a high quality solution that also is suitable for their needs?

Understanding Needs

Before you can meet a need, you must understand it. I think software development education is severely lacking in helping students learn to understand client needs. There is a lot of education on theory, best practices, and technologies like programing languages and database design. However, at the end of the day, these techniques fall under the “quality” category. Don’t get me wrong, all these skills are extremely important and deserve the time and effort they receive. But what about suitability? I don’t care how well a program is designed and coded if at the end of the day it doesn’t suit my needs.

This is what my current boss calls the “get it” gene. There is so much more to software development and design than just under the hood. Like I’ve said before, clients and consumers don’t really care whats under the hood as long as it is working. For them their number one concern is having their needs met. Have you ever received a specification, followed it exactly, only to have your boss or client turn around and say that it won’t work for their needs? It has happened to me, and its extremely frustrating. It feels like such a waste of work many of the times.

Developers who “get it” do more than follow specifications. They can visualize the people who will use it and understand what they need. Specifications are usually just a good outline, and when following it a developer needs to ask himself these questions as he works:

• What are the needs of my end-user?
• Why are they doing this?
• Is this a practical way to accomplish this task?
• Is it easy to understand and follow?
• How often would they do this task?
• Can they do it in a reasonable amount of time?
• Does this make my client more productive?
• Is this really filling their need?

I know of a software development company where in the 80s they created a software product for video rental stores. They wanted to be different from the rest of the competition. Everyone else used the keyboard as their only method of interfacing with the program. However, the mouse was becoming a popular standard with computers, so they decided they would use the mouse to navigate and execute transactions instead of a keyboard. They worked hard, created their first version, and released it.

There was just one problem: it took a lot longer to use the program than the competition. While one person had to move and click across the screen for just about everything, the competition could quickly use keyboard shortcuts and do the same thing in 1/4 of the time. In a retail store, if it takes 4 times longer to get customer through checkout, it is a serious problem. Not only that, but it was more work moving and clicking the mouse.

In short, while the interface was sleek, elegant, and it was easier to train, it didn’t fit the primary needs of their clients: check out clients quickly. This repetitive task wasn’t quick enough. Imagine if your IM client required 5 steps to send a message. You wouldn’t use it, it would a giant waste of time.

How To Become More Understand

I’ve jotted down a few ways a developer can work on becoming more understanding:

• Meet the Client – I would suggest any key developers who will be working on the client’s project should meet the client. Developers should feel free to ask questions to help them understand better the project. I suggest the developers be briefed first by the project manager, ask him questions first, and then any unanswered questions can be asked to the client. I’ve also believe that putting a face to a name always makes business more personable.
• See the Need – If at all possible developers should go and see the need that they are trying to fulfill. If you’re working on a Point of Sale program for an automobile supplies store, try and visit the client and see where your software will be at work. I remember working on a tool to help prep kiosks for deployment. The client sent pictures of the work area, and the lead developer went to visit the warehouse. See the environment helped the entire team understand the needs and challenges we faced, and helped up create a better product.
• Open Communication – There should be one point of contact with the client where questions can be asked. If there is something you don’t quite understand or isn’t clear, the Project Manager should be able to get answers in a timely fashion to keep things moving along.
• Frequent Client Feedback – This can be a double edge sword, and expectations about “feature-creep” should be set and kept. However, showing the client regular progress is important. Getting feedback during the entire process will actually help eliminate feature-creep at the end. While testing in the Alpha and even Beta stages of the project can be hard, using tools like Camtasia and Jing can help get feedback from clients when change is easier to make instead of a day before the deadline.
• Usability Testing – Try to have an environment that is easy to quickly perform usability testing. This should be done throughout the entire development process. Like I’ve said before, its easy to make small changes as you develop. However, making a lump of changes at the end can be expensive and frustrating.

From jr. developers to project managers, it is important to understand the needs you are supose to fullfill. The reason computers and software has become to popular is its ability to make our lives easier. Focusing on all aspects of software development, and not just the technical aspect, can make the difference between an okay developer and a great one.

Related posts:

1. Great PHP Article: Leadership in Software Development
2. Web Design & The Cookie Jar: When Dealing with Clients
3. Speaking: Utah PHP Usergroup – Streamlined Web Development

I’ve seen this happen so many times it isn’t even funny. You have a company with dozens of individuals giving their input on how something should be designed. As in the video, the end result is usually the same: a product that doesn’t accomplish it’s goal. This is what I call the “Cookie Jar” effect, when you have too many “hands” in the cookie jar.

The Problem

Each person involved in the situation has their own goals, ideas, and motives. When designing a company website, each person could easily say “I want to make sure my department’s product is on the front page!” The front page is also a huge breeding ground for debate, seeing as how each person wants a piece. However, if you try to cram each goal in, you’re going to get a very confusion result.

One example I like to use is ESPN. Now I don’t think ESPN’s web team is bad, I actually think with all the content they must serve and cover, they do a good job. However, if a regular company’s website looks like this, I don’t care who you are, your website needs help.

Where are my eyes suppose to look? Where am I suppose to go? ESPN’s entire front page is designed around the idea that visitors come very often, and they learn once how to get to their content. Once you “drill down” into the website, its navigation and content doesn’t because as over-bearing.

The Solution

The video hit the problem on the head without, even though most people would miss the concept. The #1 solution to preventing an over complex and useless product is: testing. Notice at the end of the video the people had came back and said after testing they wanted a few more changes? Why were they not testing from the very beginning? The entire message of “STOP” was lost due to conflicting goals and unclear direction. If they had make their original sign, tested, then made some alterations, tested, and continued on that cycle this whole problem would have been avoided.

I can’t stress this enough: if you find yourself or your project caught in continuous cycles of debating about how to do things, start user testing.

A book that I highly recommend is “Don’t Make Me Think! A Common Sense Approach to Web Usability” by Steve Krug. It talks about these principles and gives great examples. Hopefully next time you get in this situation it won’t be as big of a headache.

Related posts:

1. Five common PHP design patterns that aren’t used enough
2. Retrieve Current Module/Controller/Action inside View Script / Layout Script