story boarding


We hear allot about design…..

  • Simplicity of the design,
  • Durability of design,
  • Beautiful design,
  • Failure in design, and
  • Blah-Blah-Blah design.

What the heck is all of this stuff about design?  Thousands if not tens of thousands of books have discussed, formulated and promoted design as the key to outcomes.   But as we see the buck stops at the talk and often goes no where beyond that stage.  Why is this happening?


Myth #1 – Design is not a Title

Sure you may have the word in your position but design is not reserved to one person or one group.  Everyone does some sort of design.  Design is not a task but an interconnected set of events that compositely give us a sense of doability, complexity and direction in which to advance the development of a product or solution.  I’m sure that most have sat in meetings in which business units will sketch out what they are doing and what they would like to have happen… this is design.  Albeit possibly not to the formal liking of the purists it is none the less design, don’t make fun of it!  Even the administrative assistant who is arranging that all important luncheon meeting is doing so by design.  Some possibly from experience and habit and in some cases by a sketch of things to do and organized into some paradigm that they (or others) can utilize.  So design is not reserved just for those titled but everyone is a designer unto their own rights.  If we think back to our childhood, the moment we observed things and later picked up a crayon, pencil or pen our goal was to design something.  Maybe it was a big red barn, a portrait of our family (in stick figure form along with fido) or maybe it was a more ambitious project to form shapes that lead us to the creation of letters.  All of this is design.


Myth #2 – Design is Necessary

I prefer to think of design as not being necessary but merely the natural bi-product of thinking.  The human mind cannot process chaos, it strives to have order and seeks out some place where past experiences have had similarities.  The freeing of process to seek a base of information is essential but in doing so we need something that gives us certainty about so so many questions.  Some look for solutions, others question the importance and some even wonder whether we have got some reasonable level of completeness.  To answer these and many other questions we look for help and to achieve this we look to formed methods and techniques.  Experienced individuals will have their own preferences and even some custom made methods that they rely upon to acquire design awareness.  I have relied on tools such as Unified Modeling Language (UML) (structural, behavioral and interactive models) to exercise the multifaceted features of an application project but my design toolbox isn’t limited to this one approach.  Such techniques as high impact inspections, test driven design (TDD) and rapid story creation have been equally valuable and gratifying. These all are beginnings leading to a design vision.  It very well can be and often is more than one, and this is okay.  Multiple options give us flexibility and alternatives which we are most often going to need during the course of a project.  In the case of Agile projects if we look at the arrangement of stories into families, usually surrounding the notion of work to be performed we have a design that can be lifted from it.  In the more classical context of waterfall or v-model methods we are more apt to conceive design as a bi-product of understanding and embracing design.  Both the same yet achieved in difference ways (and possible with prejudice different expected value to be achieved from each of the approaches).


Myth #3 Design Is Magical

This is where it gets a bit dicey…. is design something you do regardless of sound engineering principals being applied or not?  Those who are proponents of building and exploring (which is by definition research) really do so without a design.  I would, from practical experience, say yes.  Its not that its not important or necessary its because the process being used is intended and focused on doability and the possibilities that can be exploited, nothing more. For this reason this sort of work is intended to lead to knowledge, which in classical terms is a defined requirements vision, to which the formalization for completeness can be exercised.  Unless we intend never to do anything more with it, including repair work, then design is not needed.  However, most will reverse engineer a design from what is produced to not only create a positive maintenance atmosphere but also to definitively answer the question about whether the endless possibilities of the research has been reached.  For others design ‘anything’ are used as guides to form work and task lists of things to be constructed to achieve the desire outcome.  This includes a definitive understanding of how the piece parts will work in harmony or contention, based on the desire of the design outcome (and requirement visions).  The creative aspect of design takes place as the result of formation and the convergence with specific technologies be it hardware, software or idiom (SaaS, Cloud, Big Data, etc.).  Its this exercise that we start to seeing balancing, or the absence of, occurring.  We hear the term dependencies to reflect the level of cohesive and interdependencies that exist in design.  There are reasons for tight cohesiveness, often centered around constraints (memory, bandwidth…) but sometimes its caused by gross negligence and poor practices.  Design management cannot be taken lightly, it required purposeful and dedicated attention to insure that all is made right.


Myth #4 Design Is a One Size Fits All Proposition

Will the concept is rational, at least in so far as the initial deployment, subsequent activities that involve changes and modifications results in an erosion to design.  This produces some interesting challenges for such paradigms as the software reuse factory, refactoring and agile driven modularity.  So how can this be overcome if at all?  Since it is a foregone conclusion that our lives will not remain static we have to assume change.  We might even have a pretty good idea as to where it will take place, when it is like to occur and to what extent it can be expected.  If we have even the slightest idea about any of these things we can insult our general design in two possible ways.  The first is by utilizing a plug-n-play approach where pieces can be exchanged in an out of the solution set.  The second more difficult approach  involves design retrofitting, the act of redesign taking place as changes occur.  In order to sustain durable and reliable design one must have software support to provide us with real time dynamic vision  into the solutionset.  Using this information is like having a dashboard that permits us to address the impact of change as to the target design it is being made against.  Not all design is evil.  In fact it can be a welcomed relief for legacy applications and those in which design was really never a strong point from inception (e.g. may be caused by rapid response driven deployment or first time out solutions).

imagesMyth #5  Design Mastery Can Be Taught

There are some things that you simply can’t teach without experiencing it.  It takes practice, failure, listening, observing and mentored guidance to become not just the ‘titled’ individual but one that clearly understands and has mastered design.  Disciplines such as structural and civil engineers mandate not just schooling but also board examinations and a period of internship.  Yet in information technology certifications are a matter of choice and not one of mandate.  Some might argue that the risks are different, but are they?  Maybe the most compelling reason for experience is the result of converting intellectual visualization into an habitual endearment to the means of achieving designs that work.  We sometimes make the mistake of thinking about the end and not about the means of achieving it.  In the immortal words of Steve Jobs, “Design is not just what it looks like and feels like.  Design is how it works.”.   Maybe this is why Steve Jobs worked so so well with his long time friend Steve Wozniak.



Engineering (from Latin ingenium, meaning “cleverness” and ingeniare, meaning “to contrive, devise”) is the application of scientificeconomic, social, and practical knowledge in order to design, build, maintain, and improve structures, machines, devices, systems, materials and processes. It may encompass using insights to conceive, model and scale an appropriate solution to a problem or objective.  (source: Wikipedia)

As humans we are apt to try and fool ourselves into believing that we aren’t perfect but we can be if we follow a ritualist approach to things.  We do this in order to convert what might be haphazard into a prescriptive, methodical and cohesive way.  One might ask why this is wrong?  In fact it is quite well intentioned and in most cases a quite appropriate thing to do.  Since the beginning of engineering like activities we have worked as skilled, talented artisans.  As the popularity and durability of the profession became established a need flourished to put formality (in written and pictorial form) to it.  But did we do it right or did we simply scribe forth what we had done and overlooked some of the more important aspects such as the ‘skilled craft’ element that only a select few can do?

I’m sure some of you have read ‘How to’ books, how often can you apply what is being written and have it turn out like it was intended to?  Skill, talent and even mental conditions are of immeasurable importance to the outcome whether we follow guiding instructions or not.  We often marvel at those individuals who can use (or not use) a guide and still overcome challenges and may even further improve upon what is being done.   The true purposes behind these pragmatic and detailed engineering frameworks is to institutionalize behavior in the context of the masses.  It is a foregone conclusion that the ‘masses’ must do something with it other than blindly use it.  People need to consume, explore, develop experience with and institutionalize it within the sphere of technical abilities.  It isn’t about adaptation but embellishment.  We hear time and time again that it “will depend” or “it may not fit all circumstances” and my reply is simply “rubbish”.  The framework of engineering is universal and if sound it will bear tentacles applicable to the situations and circumstances for which it is being applied.  An example is the comparison of traditional software development methods (waterfall, RUP, RAD, JAD, iterative, conical, V-Model…) against agility (Scrum, Xp, Crystal…).  They all have three components; a stimuli, construction and confirmation.  Whether the stimuli is created in an ah hoc fashion by inexperienced and unskilled individuals is irrelevant.  What we do with this source and the participants involve is a totally different matter however.  Its only when it start entry into the engineered construction cycle that we make choices about the raw materials.  If substandard or inadequate we know that it needs transformation to a level acceptable for advancement.  As professionals we are obligated to exercise prudent care, not reckless acceptance.  NO Engineering method will ever overcome environmental conditions that are unacceptable.  If one leaves these matters to chance or luck then its not engineering its what we would call ‘game theory’ and the last time I knew there was no mention of such facts in the annals of ‘best practice’.  The ploying of engineering practices to construct make best sense when in harmony with the intellect and experience level of its participants.  Even though there might be a better engineering approach to a problem one can never overlook the readiness of the people involved.  Too much, too dramatic and a steep uphill learning curve that has been contaminated by past failures is not a right setting for revolutionary change.  Let me be a little more to the point, it might be just what is needed however all of the other things (in the negative) that have gone wrong will only make this attempt ripe for failure by way of it being used as an excuse.

The art of engineering takes the pieces, places them inside of a vision (aka a design driven outcome) and is crafted and bonded together.  This is, as we all know, in the most simplistic and idealistic sense.  What really takes place is allot of effort driven by experience, compensated and grown through collaborative efforts, and willingness for open transparency as to what is taking place.  If it becomes an exercise in politics and hidden agendas the engineering initiative has failed from the onset.  This is about producing results and not about a total fixation on happiness.  Both can occur but not at the expense of the other.

This gives you a bit of a sense for engineering in its most primal sense.  Its pragmatic, yet flexible, intent on knowledge equality among the masses and a means to achieve sound/safe/reliable results.  An engineering method is only as good as the authors, for they are human.

ImageI think back to a course I took in college simply called “Introduction to Systems”.  With great expectations I imagined a program that would take some 5 years of field experience and round out my understanding about the topic and add some contextual perspective to my exposure.  It seems that my quote that “expectations is the road to disappointment” is quite true.  What I ended up with was a more global thinking on how various systems interplay.  My post class opinion was that it was a big waste of time, energy and value.  Some 30 years later I now understand, appreciate, apply and have drawn my own perspectives on the topic.

All activities whether involving technology, business or human existence is surround and involves systems.  Some are manual, others are fully or partially automated.  They are share one common element and that is precision (tolerable level mainstream management while succumbing to non-mainstream exclusion).  How we detect, treat, control and manage the exceptions plays a significant role in future system maturing.

What Do YOU Want?

ImageThe key word is “Requirements” but in using such a simple self-defining word we introduce risk.  We have a tendency to think in singular terms and fail to consider the multitude of other contributors to the specific “system” solution that sits on our project to-do table.  This system is often the melding of technology and manual participants.  It’s present state the culmination of years of change, some to address new opportunities and external mandates and others addressing delivery issues (often thought of as errors or bugs).

Each and everyday we are need of change.   These systems we have concocted involve various stake holders and constituents.  Many think that we have a single person, often the funding source or primary users, and that is all it takes to produce system solutions.  Far be it to consider other stakeholders who may be responsible for adjoining/interconnection systems.  Far be it that we overlook that there are solution providers, such as information technology or service contract company (aka outsourcer), who is likewise needing to be taken into consideration.  The real issue behind requirements issues include a failure to,

  • Include and address other involved parties,
  • Have sufficient regular experience (when you have this you need help),
  • Use means and models to lower omission risk,
  • Employ ‘clear thinking/green field’ approach (our rush to solutions places us asking what we had only with a bit of a face lift),
  • Think in the long term but define in the near term requirements that are impervious to change not the whipping post to common conditions,
  • Understand what is needed, what is nice to have and what is simply a big wish, and
  • Understand the importance of roles in defining what you what.

I’m NOT a Big Fan

ImageCall me different but I get turned over by thinking that one size fits all.  Whether it be a horizontal solution (usually driven by functions such as accounting, finance, procurement…) or vertical discipline (pharmaceutical, manufacturing, commerce, logistics…) you can try to make that size 10 foot fit into that size 8 shoe but it will be painful and will often require modifications that will be clearly visible.  Not to mention it will be felt throughout the life of the system solution.  We all know that we seldom see systems go away.  If anything they endure the test of time, albeit often ungracefully, and there often times that it would have far better if we cut our loses and moved on.  Some while back I wrote about the durability of applications which follow a very similar life pattern to individuals.  They progress from conception to elder years with all of the stages and characteristics of humans.  Some reach old age, into senility while the organization remains committed to keeping it on life support.  When this occurs a red flag needs to be raised because we are placing business values at risk.  These will often include customer service, efficiency, accuracy, timeliness and the all important increase in service costs.  So why do we keep the albatross afloat when its terminal?  Simply… the belief that a system is perpetual.  I can’t think of many things in life that last forever, when used, without a need for replacement.  The few often were engineered with change in mind and permitted element replacement will retaining the design.  It should be pointed out that from a general system perspective that design endures time much better than implementation (aka detail design).

Let Me Revert

ImageGetting what YOU want is a personal issue.  It makes use of your education, experience, exposure to those non-mainstream occurrences, understanding of risk and constituent systems and most importantly free/clear thinking without prejudice to the ‘how’ (unless absolutely necessary).

I’m not a big fan of written, book form, requirements.  They are difficult to use, analyze, maintain and are highly inflexible.  At the same time they will be required for a vast variety of purposes (internal control, future maintenance, training, study/analysis, etc.).  I am a big fan of facilitated story boarding.  This involves a series of facilitated free thinking sessions each geared to eek out requirements.  In complex and/or broad system situations there will be a need for multiple group meetings (culminating in a combined familiarization and closure meeting) and the use of tools such as ‘focus sessions’ and preparatory reverse engineering input.  Don’t overlook open issues as a part of these solutioning sessions, Issues point to unresolved matters and areas where complexity (sometimes ‘rightness’ comes into question).

You can achieve quality requirement generation results in 10 hours.  This is hard to believe for many since it is often a journey that is much much longer, seems to never quite settle down and becomes a nightmare to maintain.  Behavior is often linked to group debate and contention, ever changing ‘rightness’ in terms of needs and value, and the general inability to digest a substantial specification (let alone measure coherency and completeness).  The use of story boards make visible requirements, needs and thoughts.  One needs to avoid subjecting them to critical evaluation until they are considered complete enough to proceed further.  At that point discussions can take place, risk and effort can be considered, merits can be examined and delivery scheduling and be undertaken.  We want to make absolutely sure that we don’t start shooting down someone else’s ideas until we have get all of our thoughts out on the table.  Furthermore the needs are based on merit and not based on whether someone has a bigger stake or not.  What might seem trivial to you may be absolutely needed by the other party… be responsible enough to consider this factor.


ImageObviously there are allot of other things to consider when dealing with requirements (or needs).  Trace-ability, test-ability, segmenting epics/sagas, estimating effort, engineering a total solution (whether a piece or the whole) and maintaining control over change.  Change is our enemy if we fail to manage it but at the same time change can keep our business in the game.

A solution is the end to a vision and not the glory of accomplishment.  System solutions is about achieving goals that are important and doing so in a complete solution fashion (without one sided prejudice).