The business value of elegant design

In my last post, I highlighted the design process, suggesting that designers and architects should consider using creativity, in addition to methods and patterns, to build a truly useful system.  In this one, I'd like to talk about the business value of this idea.  What does the business get by adopting good design practices?

Before I go too far, I'd like to pass along a recommendation for a book on the subject, "Sketching User Experiences: Getting the Design Right and the Right Design" by Bill Buxton (link).  I have been told that this book will eloquently explain what it means to use good design principles and why every business will benefit.  I have not read the book (yet), so my opinions are unfiltered.  I speak from personal experience of 28 years in the software business, including my focus on the field of "human-computer interaction" (HCI) while attending university and years of passion around creating simple, effective, easy to use systems. 

I'm also taking a page from a friend and trusted colleague, Peter Moon, who has been sharing his passion for design with me over the course of the past year.  He inspired me to write these posts.  Thank you, Peter.

Cycles of innovation

First off, I'd like to clarify what I mean by "using wild creativity."  The process of design, IMHO, is a creative one, but not a crazy one, and we are not seeking 'perfection.'  You can use creativity without blowing the budget or going into 'analysis paralysis.'  First thing is to understand the process itself, and then to understand when, and how, to apply it. 

When I'm talking about using creativity, I'm talking about a creative process, the result of which is to expand the number of design choices available.  You take a problem and brainstorm out different possibilities in what I call an "expansion cycle."  That gives you many choices to choose from.  Then you evaluate each one, dropping off some of choices for good reasons like feasibility, cost, alignment, schedule, and risk.  This happens at a 'reduction point'.

Each time you do this, your number of design choices is more constrained, and your reduction cycle brings you to a narrower range of choices.  After a few cycles, you get a choice that you can live with and you commit to using it.

The amount of time that this process takes does not have to be any longer than the normal design cycle, especially if you are using agile principles and you have the customer close by.  You don't commit to expensive and time-consuming technical prototypes until about the third cycle. 

The first expansion cycle is done on paper and white boards.  Same for the second one.  Sketch.  Scribble.  Be creative.  Wave arms.  Use the cheapest, quickest, most flexible tool that will work.  Paper is good.  Some folks have adapted tablet input devices for sketches.  That's a pretty good idea, IMHO.  Just keep it creative.

Design is not only for user interfaces

One beef I have with many discussions of design is the notion that this cycle of creativity is really useful for user interfaces, without much discussion of how to use this concept for system architecture.  The reality is that the architecture of the system is a construct built through the creative use of various architectural and design patterns. 

When sketching out design choices for system architecture, you can consider different patterns for integration, data management, logical representation, rules management, flexibility, cross-cutting concerns, etc.  It is just as creative, but the effect on the final product is not visual, but rather a quality effect.   Your system quality attributes benefit: flexibility, reliability, scalability, security, throughput, etc.  So don't take the things I'm saying as "applying only to user interface design."  I include U/X but do not limit the use of design to U/X concerns.  It's a good method.  Use it everywhere it works. 

Understanding what customers value

When you are looking for business value, you have to look for any changes in measures of value... things that our six-sigma friends call "CTQ" or "Critical to Quality."  These are "the things that are important to the users."  When you listen to your customers, you find out what is important to them.  Don't assume you know.

This is more than collecting requirements.  This is about finding out what the customers think is important... what they value.  Look at the decisions they have made, not just the things they say.  Listen to their language, not just their words.  If someone is effusive about using "simple software with limited choices" but they use really complex software on their desktop, then drill in... there's more there. 

Understanding the customer is the first step in designing a solution, because only when you know how to measure your success in the terms that the customer would recognize, only then can you be effective in selecting a good design.

The business value of meeting customer value

Customers don't share all of their requirements with IT, even when it is in their best interests to do so.  (Obvious, right?)  But who is to blame for failing to capture requirements?  Both of us.  We get so wrapped up in functional requirements: the things the system has to do, that both customers and software folks can lose track of the intangible yet important things that drive purchase and use decisions: feel, crispness, comfort, friendliness, ease, and a connection to the metaphors that the customer is familiar with.

This is what Apple got right with the iPhone and what Google is chasing with their personal device.  This is why Amazon's Kindle is pretty cool... not just because these devices are simple, but because they are appealing.

Example 1: Here is what happens when you deliver software that works wonderfully well, but no attempt was made to create elegant design.  Note the milestones: how frequently does the user have to request an app?  Also note that I indicate the time between funding a new version and getting it. Are they happy with the app when they are waiting for the next version?  Maybe, maybe not.  IMHO, the answer is quite often "no."  This is the unhappiness that drives cost. 

How much money does the enterprise spend on this app over it's lifecycle.  

Example 2: Here is what happens when you deliver software that works well but feels great too.  Some things to note: fewer requests for change, and further apart.

Consider the cost argument: how much does enterprise spend on this app over it's lifecycle?  More or less than above?

The total cost of ownership (TCO) includes costs incurred to maintain and update an application for many cycles.  The longer an application goes between cycles, the lower the total cost.  And an investment in good design can dramatically stretch out the time between maintenance cycles on an application.

Therefore, it is cost effective to spend a bit of time using creativity in developing new applications, not only in user experience, but also in the structure and patterns of the application's architecture.  The cost of any one project may be affected (or not) but the TCO will go down... and that is what we all pay for.

Comments

• Anonymous
  November 02, 2008
  PingBack from http://mstechnews.info/2008/11/the-business-value-of-elegant-design/

• Anonymous
  November 05, 2008
  Great points. Had to check what IMHO is. Would be good if you give few practical SharePoint examples as well (for beginners like me!).

• Anonymous
  November 09, 2008
  My experience differs: I do not see demand for a new version as based on discontent.  What I have seen is almost the opposite: the better the application (especailly in feel) the more users actually the application, and the more requests for change we get. I see requests for change as a sign of life! I agree with your initial proposal: use of creativity brings us to better applications which have more value - but I would measure the value in increased takeup, and requests for change. In the requirements space one of the categorisations I use is between "conscious" requirements, "unconsious" requirements, and "undreamt of" requirements.

• conscious ones stakeholders can tell you about
• unconscious ones a good analyst will eventually ferret out
• undreamt of requirements are the magic sauce: things stakeholders would never ask for, but which really good people can come up with. I tell BAs that designers (you might call them solution architects) are the possibility thinkers of the process, and will come up with lots of "what-if" ideas for the project that the BAs need to help them evaluate. That's where my teams handle this creative process: not purely inside the design team.

• Anonymous
  November 10, 2008
  Hi Steve, Some time soon, I'll blog about the difference between a business requirement and a specification item.   Until then, suffice it to say that I would not be surprised to hear about an analyst that was creating candidate designs and envisioning specification items implied by that design.  The difference is important but subtle. I do not know if that is what your team are doing, but it fits the pattern.  Regardless, it is a distinction that may not have a negative consequence, especially if you have a good rapport with your customer.  Agile dev teams avoid many problems caused by failing to manage the distinction between a business requirement and a specification item. Iterative dev teams using traditional methods often mess up, especially in user acceptance testing, if this distinction is lost.  Major cause of problems. I'll blog about the distinction soon. --- N