I have held multiple job titles tech writer, developer, information architect and currently UX designer. Underlying all the job titles and skill sets is general problem solving ability that was needed to succeed. Here are three techniques that I have personally found very useful in improving my problem solving abilities.

Essential and Accidental Complexity

In the famous No Silver Bullet essay, Fred Brooks discussed two types of complexity that impact software development productivity. (Brooks attributes the original idea to Aristotle)

1. Essential complexity is complexity that can’t be reduced further. These are the difficulties in the requirements that are unchanged by the implementation.

2. Accidental complexity is complexity introduced during implementation. These are side effects of solving a problem.

I find this very useful to understand software requirements. Essential complexities come from users, organizations or society at large. Consider tax filing software as an example. The tax codes are the essential complexity. They are laws set by the government. From a software’s perspective they can’t be simplified further. But the accidental complexity, like saving user input, is under the software team’s control. If a problem will be not be present in another implementation medium then it is an accidental complexity. In the case of tax filing software, another medium is using a real accountant to file taxes. Will an accountant ask if you want to save your information when you leave her office?

For designers, solving essential complexity is usually more valuable than solving accidental complexity. User’s feedback often points at implementation details like “I want a button that will do x”. A good designer should distill the feedback to its essential complexity and then solve it. The best interface is no interface.

Known unknown

Software projects are about reducing uncertainty. When a project starts there is a lot of uncertainty. By means of research, discussions, mockups, prototypes and software, information is uncovered and the uncertainty progressively decreases. A framework to track the information space around a software project will be helpful.

Donald Rumsfeld popularized the idea of partitioning our understanding of the world into four quadrants. When I started hearing references to “known unknowns”, I assumed they were sarcastic comments. It took me a while to realize its benefit. I find it especially useful for thinking about user research. The four quadrants are:

1. Known-knowns. Things I know that I know.

2. Known-Unknowns. Things I know that I don’t know. I know the identifier or label of the data point, but I don’t know the data point. This is a manageable information space. Once I know the label then I can take proper efforts to uncover the data. Quantitative research methods are the right methods for tackling this area since I know what I’m are measuring.

3. Unknown-unknowns. Things I don’t know that I don’t know. At the beginning of a projects, I’m starting from this quadrant. Qualitative methods are the right methods for tackling this area since they yield richer information.

4. Unknown-knows. Rumsfeld didn’t use this category, but it can be derived. Things I forget that I know. Sometimes I forget take into account something that I already know.

Stephen Covey – Urgent/Important

Like most people, I have a running to-do list. I found that how I structure and order the tasks in my list determines which task I will do next. A common trap for me was spending more time on easy but less valuable tasks. Or working on tasks at the top of the list and realizing that a more urgent task is at the bottom of the list.

After I read Stephen Covey’s Seven Habits of Highly Effective People book, I started following his recommendation of dividing tasks based on urgency and importance. This technique makes me vigilant by organizing tasks based on what I value as importance. Instead of using four quadrants as he prescribes, I use two categories – urgent and important. Most of the time the urgent tasks are not important and important tasks are not urgent.

My goal is to spend more time on important tasks, since they are more fulfilling. Urgent tasks can’t be eliminated completely. But having all tasks in the urgent bucket is a sign of reactive work mode. I consciously try to spend some time on important tasks, even if I have a lot of urgent tasks. When I have no more important tasks, it is a signal that I have to start some initiatives to solve problems that I’m passionate about.

The Mazda MX-5 is the best-selling two-seat sports car. It is famous for being light weight and fun to drive. Mazda follows the principle of Jinba ittai, Japanese for horse and rider being one, while developing the car. The principle comes from the Japanese sport of mounted archery, where the rider controls the horse with his knees. This principle has guided Mazda to create a car that is known for its driving experience and not its features.

Design Principles

Designing is the act of making choices. Design principles guide us in making decisions. In that process, they also become the criteria for evaluating the decision made. In projects riddled with ambiguity and fuzzy goals, design principles are a good antidote.

There are two different usages of the phrase ‘design principle’. One school of thought is principles in using visual medium like line, shape, and color. I’m using ‘design principle’ as a more general rule that is understood and followed by anyone. (Just principle is more accurate, but I like the sound of design principles.)

Collaboration tool

“If you know where you’re going, it doesn’t matter how fast you get there.” Jared Spool

In large projects, communication within the team is a major bottleneck. Especially in globally distributed teams, conventional modes of communications like meeting and email are limiting. There will be only limited timeframe for meetings due to timezone differences. And everyone is overloaded with email these days. In effect, the amount of information communicated within the team is finite.

Design principles bring all the team members to an agreement about the goal and perhaps the strategy to reach the goal. This is so much better than agreeing to the solution. This will allow the team members to work independently while still maintaining a common goal. As team members work around the same design principles over time, mutual trust will increase and the amount of information communicated to get the same task done will decrease.

Choosing design principles

Selecting design principles is difficult, because there is no right or wrong principle. But it is an important conversation to have with oneself and with team members. Conflicts about the principles can also be harder to resolve for the same reason. However, if these conflicts are not resolved or even acknowledged up front, they can become painful and tedious later.

Bret Victor gave an inspiring talk on choosing a career based on a principle. In the talk he gave two qualities needed in a principle:
* It should be actionable. Phrases like ‘keep it simple’, ‘easy to use’, ‘beautiful’ are ambiguous. And can’t be acted upon.
* It should also objectively divide a situation into right or wrong.
I will add that the design principles should not point to solutions. They should show the way. So choose any principle that has these qualities, and make sure everyone buys into it.

Design principles don’t guarantee success. At the least, it guarantees clarity of thought which I think is better than success.

Learning is a nonstop process. Since graduating from Michigan three years ago, I have learned as much as I did in school. These are some lessons that were the most revealing and useful to me.

Design has to complement business and technology

I used to think a product can succeed solely based on its design. Any decent idea, with a good user interface will result in a successful product. In other words, I had a hammer and every problem looked liked a nail to me.

Don Norman argued that technology has to advance first for innovative breakthroughs. Design research is needed for identifying incremental improvements to existing solutions. But with just design alone we can’t go very far. His message signaled me to get out of my tribal mentality. And realize that design alone is not sufficient for success. It is important to understand the value that technology is bringing to the product. Even as someone who likes to code, this was revealing.

Good business strategy is the third ingredient in successful products. I admire a lot of products that are not commercial successes. Palm pre had some amazing design details that iOS and Android took many years to implement. But it didn’t have the right business strategy and technology. Design has to work with the business strategy. If the business strategy is to increase the sales within the existing customer base, then a completely revamped interface would not work well. I need to understand how the product I’m working on will generate revenue, directly or indirectly.

Everyone doesn’t know design

During grad school, I was surrounded by deadlines, wannabe designers, sticky notes, and MacBooks (in that order). It didn’t occur to me that one day I will work with people who don’t know design. When I started working, I was looking for opportunities to use phrases like contextual inquiry, fitts law, short term memory in my sentences. I think people were polite when they ignored me when I tried too hard.

There is definitely an increasing appreciation for design and usability in the industry. But non-designers don’t speak the design lingo; and I don’t think they have to. It would be useful, but I can’t assume it. This realization changed how I communicate with people. When I start working with someone for the first time, I explain my process in simple terms. While presenting solutions, I explain it from the user’s perspective, instead of a designer’s perspective. Just like physicians who explain how our body works and what went wrong to help the patient understand the situation.

All problems are not equally important

Our lives get more complicated as we grow up. As kids we don’t have todo lists and projects. At some point we start organizing our lives. A similar evolution happened in my approach to problem solving.

I used to focus my energy equally on every aspect of a project. It is so easy to get stuck at designing the signup page. It is an interesting problem, but it is not valuable. Now I get the lay of the land, identify the value of each step and allocate my energy proportionally. Or I try to do this. But prioritization is a skill that takes a lot of practice and I just got started. As I learn to pick my battles, may the odds be ever in my favor.

Fundamentals of design are timeless

Technology has been evolving rapidly. Last year’s technology is already obsolete. I tended to think technology problems are unique to our times. When I was a developer this assumption was correct. Often the issues are specific to the programming tool. As a designer I continued this mindset, getting my information mostly from RSS feeds, Twitter, latest products. I was interested in only the latest and greatest design soutions, thinking, process, etc.

Subconsciously I was trying to follow the current trends in my design solutions. As a result, I would not be able to explain all my design choices. Fortunately, I also read some good books, in addition to online content. As I followed the trail of references from books I liked, I developed a better understanding of the basics of design. Cognitive Psychology especially has given me lot of reliable concepts.

I still catch-up with the latest developments and get inspired by them. But I’m more aware of my design decisions and reasons behind them. Here are the influential books I have read recently that are at least a decade old.

• The Humane Interface taught me about the perils of software mode, designing for short term and long term memory.
• Designing Visual Interfaces, 1994, presents user interface design as a communication problem.
• Semiology of Graphics, originally published in 1967. I’m still reading the book. The theory in the book has given me a very reliable structure to analyze data and map it to a visualization method. Can’t recommed this book enough.
• The Mythical Man Month. This book is about software development. I promise you that most of the examples in the book will be familiar to anyone who has gone through a software release cycle.