Design Principles

This is a living document and was inspired by Thoughtbot’s Playbook for which I found myself nodding my head continuously as I read through it.

Visuals are Better Than Words

People need to see ideas and not hear about them. Many people do not have the ability to see abstract concepts in their minds. You should create visuals and mock-ups to express ideas in a concrete manner. I have been using Balsamiq to create mock-ups quickly.

Always Put Yourself in the User’s Shoes

• What state of mind are they in?
• What is their skill level? Are they an expert or novices?
• Do they understand jargon and abbreviations?

You should watch people do their job. What they tell you they need and want may not actually be true. Often users will not be asking for the correct problem to be solved. Watching people do their job will help you get to the core of the problem that needs to be solved.

Prototype Solutions

• Demo early and often to get feedback early.
• Most people do not know what they want until they can touch and experiment with it.

You should built prototypes and demo them to the target users during development. Additionally, you can build out the user interface pieces but not have all the components completed. This allows you to make sure you are on the right track.

Gather Multiple Viewpoints

Gather feedback from as many different levels as possible. Start from the day to day users and go up to Director or Executive level. You may need to hold private meetings with subordinates as there could be political or personal hurdles where honest feedback cannot be given. For example, a Director may think that the current process is “x” and his subordinates in the meeting may be afraid to speak up on what actually happens in the “real world.” These subordinates can often provide valuable information into exceptions and one-offs that may throw a wrench in your design. You need to be careful with the lower level people as often times the subordinates may not see the big picture strategy of the new software.

Design with Iteration in Mind

Big bang projects do not work for many reasons

• You will never have accurate requirements
• Requirements change as people start to work with the software
• New requirements will surface during testing and early production use
• Issues that you thought would be trivial turn out to be large and visa versa.

Always assume that you will be doing a phased approached. This will serve many purposes

• It allows you to focus on the most important features first and push off “nice to have” enhancements.
• It allows you to appease people who are unreasonable roadblocks to improvement as you can always say their concern will be handled in a later phase.
• It allows you to get something into production sooner rather than later. Production software is where you will get the most valuable feedback.
  • There is a military saying that goes like: “No Battle Plan survives first contact with the enemy” which can be applied to production software.

When doing design and especially coding assume you will have multiple iterations and things will change.

• Requirements will change
• The business will change
• New requirements will surface
• People will change their mind
• People will hate the first iteration

When you are writing code never “paint yourself in a corner” with your technical design. This may include things like hard-coding values.

Requirements documents

• Don’t take requirements documents as the law
  • Requirements may not have been written by someone who understands technology. Alternatively, they may have wrong assumptions about the technology or development efforts required for a solution.
• Requirement gather and documentation often done without the technical person. Developers cannot code in an information vacuum. The technical person needs to understand the business process and problems being solved when creating a solution.
  • Your primary care doctor does not discuss your upcoming surgery without involving the surgeon or allowing you to talk to the surgeon. Why would you let a non-technical resource map out a solution that involves technology?