Successful projects begin with sound solutions

By Chad Kluck on


Whenever I head a project I try to keep user focused. Users may be internal or external to the organization. External users include the general public visiting a web site to learn, research, or complete a transaction. Internal users include the employees going about their day to day tasks of filing client notes, developing or marketing programs or services, interacting with customers, or completing other administrative tasks.

As I develop solutions for groups it is important to have group buy-in as well as keeping the end user experience (internal or external) in the forefront. Also, rarely can I get together with a group and pull a finished solution right out of the box after one meeting. Every user population an organization serves is different.

The process I use has key points laid out to be understood and embraced by group members so that sound solutions may be developed. It is the foundation for the group to stand on to keep us together and focused. Once the group has bought into each of these key points, and the success of the project, they feel ownership and personally responsible for success and failures. If there is ownership of the success, it makes new projects easier to sell. Ownership of the failure reduces the blame game if the group can point to some inanimate list and identify a key point that wasn't followed.

Once you go through this cycle often enough you will build confidence in yourself and group members. The key is to follow the steps and iterate quickly. Drawn out projects with longstanding bugs and thorns are a sure fire way to kill any momentum and confidence you or your group may have built up.

  1. Watch users, understand their needs, and what they need to accomplish.
  2. Look at logs, keyword searches, and user traffic to see what users are trying to accomplish and to see what is important to them.
  3. Prioritize needs vs. wants.
  4. Prioritize organization needs and wants vs the organization’s client/customer/visitor needs and wants.
  5. Identify problems.
  6. Design and receive input about solutions.
  7. Realize that sometimes the user doesn’t know what they need or want.
  8. “Because it’s always been done that way” isn’t a requirement.
  9. Develop a solution with a set of requirements that simply solves a real problem--simply.
  10. Anticipate new problems and pitfalls.
  11. Walk through the process and test.
  12. Refine the solution.
  13. Implement the solution and monitor its use.
  14. Iterate quickly by fixing problems and building in enhancements (not features) as needed.
  15. Never “set and forget”--instead always “monitor and maintain.”

In the end there should be a solution to an existing, real problem, not a solution to a made-up problem which doesn’t exist. The solution should also be simple for the user. Streamlined with minimal steps, convenient, and understandable. The general public (e.g. website visitors) should not have to be trained on its use and they should be able to pick it up and “go with it.”

What are "real problems"? Real problems are the convoluted processes that users give up on after becoming frustrated half-way through their task. Real problems are recurring tech support calls that clog up the support team. When a diverse group of users report the same problem or ask the same question, there is a failure somewhere in the process.

What are "made-up problems"? New, hot technology that everyone is using (and the media is hyping) but does not solve a current business need at your organization. Typically group conversations start out, "If we used X what could we do with it?" (Remember the "If we bought Newtons for all of our employees, what are the top ten things we could do with them?" The conversation should have been, "We have these ten problems, and if we bought Newtons it would solve all of them," followed by a reality check, of course.)

Spend your organization’s time fixing low hanging fruit, problems that already exist, or supporting proven technology rather than following a shiny distraction. Taking on more distractions starves other projects and clutters up the workplace. Of course, by all means experiment and play, but only after your daily chores and emergency repairs are completed.

New features should be built upon a stable model. Do not neglect monitoring and maintaining as you pursue a new bullet list of features. Features should be enhancements. Enhance the user experience. Enhance the process for accomplishing tasks. Features should not clutter the user experience or deprive existing, inadequate features from their own much-needed enhancements.

When releasing a new version your bullet list of enhancements should always be longer than your bullet list of features.

Focus on user experience. Design products, technology, and websites that are simple, clutter free, easy to use, and benefit the user. If you make the process simple and enjoyable your users will stick with it. Let them accomplish a task easily (maybe two or three!) and they will more likely generate additional transactions with your organization before getting on with their life.

Imagine if you made your mobile app so useful that the customer was able to buy toilet paper, diapers, beer, dog food, AND sign up for the premium account offering re-curing monthly deliveries of these items all while standing in line at the bank! You might actually be able to hold their attention before they have a chance to open their "Simpson's Tapped Out" app and check on their Springfield.

As you follow these key points they will help you focus on the user by putting them first and valuing their time, interests, and real-life problems. Do not put bad design, your own interests, or political interests of the organization in the way of the user. Create a sound solution and let the user accomplish what they set out to do.