Skip to main content

Author: Santosh Shaastry

Practicing Simplicity in Analysis

Have you ever realized that innovations aim for one or more of these – Faster, Better, Cheaper, Sleeker – all these and more, while trying to keep things SIMPLE.

Only a few years ago, if someone told us that huge market existed for tablets it would have sounded presumptuous if not impractical. Tablets have actually replaced desktops and laptops across the world – from Sales representatives to home makers, the user base for tablets is diverse. This is a phenomenon that is worthy of a research to understand how human beings “adapt” and “absorb” simpler designs all the time! Don’t we always wish everything is simple and easy to do? – paying bills, buying groceries, watching a movie, reaching out to a loved one across the world at the touch of a button etc.

Analysts work with business problems and are expected to SIMPLIFY the problem to define a practical solution! After all, why would business folks need “analysts” if the job defining solution is “that” simple? Being one myself, I began on a quest to understand what ‘Simplicity’ actually means (and feels like) when consciously understood and applied to our day to day work. I did research great deal of books & articles that detail the importance of and offered tips to “keep things simple”. “Laws of Simplicity” (by John Maeda) stood out for two reasons: 1) Categorization of different principles in to 10 laws (embodiment of a law itself!); 2) Clear and practical uses of each of these laws.

Here I present my views of some of these “Simplicity Laws” that I found highly beneficial in the process of “Analysis”. I hope the same is true for you as well!


Analyzing a business problem requires a thorough research about existing process & practices, emerging trends, competition and current capabilities. This could well lead us into a minefield of information. If not carefully managed, we would be trapped in this minefield and eventually lose out by delivering incorrect or inefficient solution.

Thoughtful reduction of what I call “3D” would help in differentiating the “noise from the sound” and leave us with clear, relevant information

  1. Data which is irrelevant
  2. Discussions (with stakeholders) that are futile
  3. Documentation of every little fact that comes our way


As we work to identify different solutions for a business problem, variety of information shall be at our disposal. Applying the first law of “Reduce” in the hope to overcome the problem of “Disconnected Data” may not work most of the time, because it only eliminates what we do not need. This is when we must activate our brains to look for patterns in information and assimilate information. This creates a systematic approach to “clear the clutter” and also help us find information when we need it and as we need it! As the book “The Art of Organizing Anything” (by Rosalie Maggio) captures, it is possible to organize anything. Why not organize what we analyze? And organizing information as soon as we find it definitely helps in the long sprint!


Have you ever been in a meeting in which you did not get what is discussed? I know exactly how it feels – puzzling. Such puzzling could trigger thoughts that range from irritation, helplessness to fear of the unknown! You probably guessed it – domain knowledge is necessary to be a successful analyst but is not the only one. With the barrage of technological innovations happening around us, which I think is great, we must strive to learn “new stuff” all the time. Competition is the other factor that “forces” us to learn something, but that does not cause as much excitement as our proactive ability!


Ofcourse! If we cannot rely upon our co-workers, nothing would ever get accomplished at the workplace. So the obvious is beside the point. As analyst, we must identify trust-worthy “source of information”. Don’t we use Google to search for most of the information? Do we trust all the 38,10,00,000 results that Google throws up for the word “analysis”? As we gather information, note down the source of that information. Revisit the source (probably while Organizing) to check the allied information, acceptance and authenticity.

If interested, I welcome you to explore the other laws of simplicity and share your valuable thoughts on how the below laws impact analysis OR even do they?!

  • Time
  • Differences
  • Emotions
  • Failure
  • Context
  • The One – that combines three keys: Away, Open and Power

Don’t forget to leave your comments below.

Assumptions in Analysis

Being an analyst is not an easy job! As thrilling as it may sound, working with unknowns is a nightmare. As one begins to work towards identifying the unknowns, an important challenge comes to the fore – How do we manage the unknowns that remain so even after dedicated efforts? Should we give up? Having loose ends impact the overall solution that shall be developed. And eventually impact the business objectives or even worse leading to failure of the business objectives!
Assumption – Defn: a thing that is accepted as true or as certain to happen, without proof.

Assumptions are as important as architecture, design, solution, model etc. Identifying assumptions is not rocket science and is not a cakewalk either. Discussing the solution with engineers, or design with architects, or while interviewing users – are some entry points that help capture statements or boundary conditions that have the potential to turn into actual assumptions.

While in the nascent stage of solution or requirements definition, assumptions provide a wonderful placeholder to document and manage the unknowns. As numbers of users grow and product/software evolves requests to modify the solution increase as well. Most of these requests, if not all, would require a change in the assumptions that were initially documented. It is extremely important to keep review the assumptions periodically and keep those up-to-date. Take, for example, an assumption that smart phone users may not have the blue-tooth switched on all the time, thereby indicating an extended battery life. With the arrival of smart watches, which must be paired using blue-tooth with a smart phone for optimum benefits, the assumption on blue-tooth usage must be taken out of the solution!

Applying reverse engineering principles, assumptions could actually be used to identify ways to improve and evolve solutions/software thereby improving business value. Personally I have immensely benefited from this activity and have come up with innovative thoughts to improve solution or identify gaps in the solution.

I prefer to manage assumptions by using a simple structure, defined below:

  • Actively managed – These are the assumptions that carry a high risk and could change very quickly
    • High Impact
    • Medium/Low Impact
  • Others – Though these do not pose high risk to impact the solution. However these provide a way to capture the boundary conditions for the product/software.

Google Glass – Take a moment….What, in your opinion, are the top assumptions in the Google Glass project? In my opinion those would be,

  1. Wi-Fi connectivity is available
  2. People not having a perfect (say 20/20 or 6/6) vision cannot obtain optimal use out of it
  3. Applications built for this product shall differentiate between a proper eye-gesture and natural blinking!
  4. The glass device shall not obstruct natural viewing.

Simple analysis of these assumptions

  1. Assumption 1 has tremendous impact on the software that shall be built for Google Glass device. Unlike tablets or smart phones, Glass is a device that requires real-time data (restaurant reviews, monument details etc) for best usage.
  2. Assumption 2 captures a basic usability requirement that is just not a part of the current version of the product (let me know if it is!).
  3. Assumption 3 addresses a very important characteristic of the applications built to cater to the Glass device. If we cannot differentiate between the natural blinking of eyes and a specific gesture, the results of using the device could range from being bad to disastrous.
  4. Assumption 4 captures a basic usability requirement!

Please share your views on how identifying assumptions helped in analysis of a problem.

Don’t forget to leave your comments below.