Learn the rules before you break them

Designers and visionaries love bucking convention. Stop them, until they’re ready.

Working with hundreds of designers and developers in my career, I’ve come across almost every type imaginable.

There are the artists, who pour themselves into every project. They bond deeply with their creations whether they’re websites, marketing materials, brands, or actual fine art (I once offered to buy a piece that a student in my art class in college had painted. She refused. She couldn’t bear to part with her creation).

There are the engineers that understand the math and science behind user experiences or emotional connections. Most of my favorite brands had their logos designed by engineers. Designers that understand the complexities of grid-based design, scale, weight and space.

There are generalist creatives that just seem to be incredible at every artistic area of their lives. They paint, create websites, shoot photography on the side, and cook masterpieces of culinary delight while blogging about their experiences. Some of my favorite designers and developers have this type and they make the absolute best freelancers.

That is by no means the full creative list — there are seekers, musicians, athletes, strategists, salesmen, and hermits. The best creatives from all these types, though, have one single thing in common. They understand the rules.

“Smokey, this is not ‘Nam. There are rules.”

Every game in life has rules. From football to foozeball, there are rules dictating how we can participate. These rules can be broken, but if you’re a hockey player and you slash another player with your stick in front of the ref, you’re going to get penalized. If you understand the rules, however, you might be able to get away with a bit of slashing without getting in trouble.

Creatives play in the same way. We have to learn the rules first, then we can start to test the boundaries to make a lasting impression. Let’s take a look at the basics for designers and developers.

The Fundamentals of Design

• Unity/harmony — When all elements are in agreement, a design is considered unified. No individual part is viewed as more important than the whole design.
• Balance —A large shape close to the center can be balanced by a small shape close to the edge. Balance provides stability and structure to a design.
• Proximity/Hierarchy— Proximity creates relationship between elements. It provides a focal point. Proximity doesn’t mean that elements have to be placed together, it means they should be visually connected in some way.
• Scale/proportion—Scale is the relative size between elements. Scale can also be proportionate to the distance or area between, around, above, below, or within elements.
• Dominance/emphasis — Dominance is created by contrasting size, positioning, color, style, or shape.
• Similarity and contrast — Contrast is the juxtaposition of opposing elements (opposite colors on the color wheel, or value light/dark, or direction — horizontal/vertical). Contrast allows us to emphasize or highlight key elements.

Fundamentals of (Lean) Software Development

• Eliminate waste — Lean philosophy regards everything not adding value to the customer as waste. Such waste may include: Partially done work, Extra processes, Extra features, Task switching, Waiting, Motion, Defects, Management activities
• Amplify learning — Software development is a continuous learning process based on iterations. Software design is a problem solving process involving the developers writing code and what they have learned. Software value is measured in fitness for use - not in conformance to requirements.
• Decide as late as possible — The more complex a system is, the more capacity for change should be built into it. The iterative approach promotes this principle — the ability to adapt to changes and correct mistakes, which might be very costly if discovered after releases.
• Deliver as fast as possible — In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration.
• Empower the team — The lean approach follows the Agile Principle, “find good people and let them do their own job,” encouraging progress, catching errors, and removing impediments, but not micro-managing.
• Build integrity in — The customer needs to have an overall experience of the System. This is the so-called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, its price and how well it solves problems.
• See the whole — Software systems are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process — by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated.

Fundamentals of User Experience

• Visibility of system status — The system should always keep users informed about what is going on, through appropriate feedback within reasonable time
• Match between system and the real world — The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
• User control and freedom — Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
• Consistency and standards — Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
• Error prevention — Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
  (Read full article on preventing user errors.)
• Recognition rather than recall — Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
  (Read full article on recognition vs. recall in UX.)
• Flexibility and efficiency of use — Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
• Aesthetic and minimalist design — Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
• Help users recognize, diagnose, and recover from errors — Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
• Help and documentation — Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Breaking the rules

Now that you know the rules, it’s ok to test the boundaries. Try iterations, test and analyze, but remember that if you’re design or code isn’t working the way you want it to, check the rules. You may have strayed too far from them and it’s affecting what you’re trying to build.