This class is for hopeful engineers who want to make sure that the fruits of their labor go on to benefit many users. I’m tired of seeing hours of engineering time wasted building the wrong product and useless features. I’m tired of software projects that are cancelled because they are “out of control.”  I want engineers to have confidence when they start a project that they will know when they are done, and that specs won’t change out from under them.  I bet you do too.  SWIFT can help.

This class is for frustrated product marketing people who want to know how to tell engineers what to build.  I’m depressed by detailed marketing requirements that result in products with the right features but assembled in a useless way.  I grieve for the product managers who slaved over these requirements and who are flabbergasted by the resulting product that comes out of engineering. I cringe thinking of the abuse poured upon them by the sales force who can’t understand how to sell this product against the latest new offering from a competitor. I want to see this end.  SWIFT can help.

 This class is for the many overworked people in technical support who want to impact future products so that they don’t become support nightmares.  Customers deserve better products and support engineers should not have to face the frustration of customers who get hard to fathom products.  SWIFT can help.

This class is for suffering technical writers who are tired of being asked to document a poorly defined feature to make it easier for users to learn and use it, and it is for trainers who are frustrated that they have to give training to cover poor designs.  All too often these people are expected to fix problems that date to project inception and because they start work at the end of the life cycle and are gating release they are given no time to do their work.  SWIFT can help

This class is for general managers, held accountable for results, who are tired of hearing “there is never enough time to do it right, but always enough time to do it over”.  It is for people raising financing for projects who know that they won’t get multiple trips to the plate to get it right.

If you are trying to be more successful in contributing to the design new products and services in any of these roles.  This class is for you.  Your job is one of the hardest imaginable.  Because you are working on something new you can’t rely on existing evidence.  And there are so many interdependencies between the idea for a new product and its success in the marketplace. It takes a lot of good fortune to succeed.  It is no wonder that it is said that “It is smarter to be lucky, than its lucky to be smart”.

Despite that component of luck, a lot of the problem is really just complexity.  It is hard to know everything you need to know to be sure.  So you have to make choices. Where to focus.  What do you NEED to know to move forward, and what would you like to know, but are willing to guess at for now. 

This class will help.  It is full of risk reduction strategies that will help you identify and stay focused on the most important problems.  You may still choose to move forward without more information in one of the areas covered here, but you’ll knowledgably make that choice, and you’ll know what to watch for as symptoms that you choice poorly and should revisit your choices.  So this class may make you smarter, and even though that won’t necessarily make you luckier, you may be on path to helping to make your own luck.

What you will learn

With this class you’ll learn techniques that ensure that once the product is done that you WILL be able to sell it, no matter what the competition does.  You’ll learn how to arm your sales force to sell it.  You’ll learn how to define specs for the engineering department that won’t change with every change in competitive offerings.  You’ll define specs that engineers know will address what you need.

And because they won’t change your engineering projects will be done sooner.  And they will result in less code to write, less code to test in QA and less problems to support in the field.

Your products will be perceived as easier to use and delivering more value with less learning required.

You’ll be able to tell well in advance how good your design is, and you’ll be able to verify that results you get in release meet your original design requirements.

What is SWIFT?

What is SWIFT?  And how will it make it easier to design products and services that sell? And can be built?

SWIFT is a cradle to grave approach to understanding why people buy products and services, and taking that understanding and turning it into requirements that engineers can build from and which will ensure that customer’s needs will be met by the resulting products and services.  There are many steps along the way that allow you to gauge how well you are doing, and the goal is to reduce risk and gain certainty before investing in expensive development.

Of course, any step could be skipped or short-cut, at concurrent increase in risk. However, in general this is not a good idea. Too often this results in a development schedule that balloons out of control – because developers don’t really know how to tell when they are really done.  Features and requirements shift and pop up at the last moment.  The result is bloated products that are too hard to use, are full of buggy code that had to be written and tested and now has to be supported in the field, but which wasn’t really necessary or even desirable to start with. 

With SWIFT this doesn’t have to happen.  By the time you complete detailed design with SWIFT you’ll have an effective acceptance test that both you and your developers can use to insure that your goals have been met.  This is perfect if you want to outsource development, even to foreign development teams.  Because they know how to tell if they are successful they can test at any time to see if there work is really done.  And if they pass the test, you’ll be sure that it is done too.

Organization of SWIFT Courses

This class is divided into the following parts:

Introduction

This is the section you are reading now.  It tells you what SWIFT is, and what it can do for you.

The 10 Step SWIFT Design Process

This is the main part of this class.  Each chapter covers one step in the ten step SWIFT process. For convenience, I have grouped these into 3 major sections that group steps into larger design and release processes. While work can proceed on several steps simultaneously, there is a natural top down flow to the process and readers are urged to read these chapters sequentially.  Additionally, there are a lot of relationships between results in one step to work in other steps, and this will be much clearer if you read all of these chapters.

The ten steps are:

Conceptual Design

This is the first of 3 phases of SWIFT. This first design phase involves investigating who the key stakeholders are that need to be influenced to make the product sell, what their goals are and what tasks they are currently performing to achieve these goals. From this we posit our new products or services and then compare how much faster, easier or more accurately stakeholders are able to meet their goals with the new products or services.  This provides assurance that customers will be motivated to make their purchases, regardless of what the competition is doing!

Identify the Stakeholders

In this section we discuss how to identify and characterize all the stakeholders necessary to make a sale. We’ll learn how important it is to create archetypal characterizations, and to identify key roles people play and traits they have that influence their buying decisions.

Goal Oriented Design

In this section we discuss how to identify and categorize goals.  Goals are what provide people’s motivation, including the motivation to change which products they are using. We’ll see that there is a hierarchy of goals and that motivate more powerfully than others.  We’ll use that in trying to find what goals to address in our designs.

Task Oriented Design

When people have goals they come up with tasks to perform to address them.  Sometimes they are effective and sometimes they aren’t. What drives people to adopt a new product or service is the reduction in effort, time saved, increased accuracy or pleasure they get from the experience of using the new product or service  We’ll determine what they are doing today to figure out how good our solution has to be. Then we’ll hypothesize our solutions and check that they are sufficiently better to get people to switch.  We’ll also look at the effort involved in switching itself: learning about the new offerings, acquiring it, and mastering it.  We’ll see how that affects adoption as well.

Detail Design

Now we have an overall idea of a hypothetical product or service that we think will provide a better experience to the stake holders we have identified. But before we build it, can we verify that it will be good enough?  Can we estimate more accurately, and even quantitatively what benefits stakeholders will experience?  Can we define more precisely the features of the product so that engineers can build them in a way that assures we will wind up with the overall results we want?  The Detail Design section is a way to peel the onion and go increasingly deeper in our understanding of the precise requirements we want to develop to.

Cognitive Design

We start by understanding the limitations of the human processor that powers each of our stakeholders.  We are good at some kinds of skills and poor at others.  We want to choose wisely so that we maximize what people are good at, and limit requirements on them to do what people do poorly.

We evaluate these skills in terms of human memory, reasoning, communication, perception and motor skills.  We see that there are techniques for estimating performance time and accuracy for some of these skills, even before we build a prototype, thus giving us confidence that our designs will provide the improved experience we posited during task analysis.

Visual Representations Design

Taking into consideration what we learn about perception, we can start to select visual representations  that are more compelling and clearer to stakeholders, thus ensuring that they will have the desired experience.

Widget Selection

At this point of time, we have some idea of what the visual representations (the “look” or “appearance”) of our product or service.  We also have a defined a set of tasks or actions which are the behavior or “feel” of our product.  With this in mind we can select among different kinds of pre-programed user interface pieces, widgets, that might want to use in our designs.

Data  Requirements

In addition to look and feel of a user interface, most tasks take place multiple times, or take an extended period of time to perform.  Design features can support users in completing tasks accurately and quickly by off loading much of the need to remember things, which can be achieved by using computer storage.  Additionally, tasks usual require information to work on, and create information as a result.  Certain forms of that information are more efficient and effective than others.  We’ll look at considerations that you might want to build into your requirements regarding these factors.

Method Requirement

At this point we can start designing algorithms that will assist us in transforming our data inputs into our desired outputs.  We’ll talk about ways to derive these requirements from the earlier task scenarios we defined in conceptual design and worked out during cognitive design.

Release and Production

At this stage, we should be pretty sure we know what we want to build.  We have very complete requirements of what the hypothesized product or service should be, and pretty good expectations about how well we expect it to perform when we give it to actual stakeholders.

Prototype Usability Tests and Product Acceptance tests

So, now it is time to actually build parts of the product and test our hypotheses, and refine our design if we aren’t seeing the results we expected.  We talk about how to use the tasks scenarios we talked about earlier to verify that we are achieving our design goals.  This allows us to reduce even more risk before committing to final code.  This section talks about how to perform actual usability and verification acceptance tests.

Release, Ship and post release field results

Now we have a finished product or service and we start delivering it to our stakeholders.  Are we getting the results we expected? Why or why not?  We learn how to verify our successes and build on them, and how to recognize our mistakes and fix them.

The SWIFT team

This section describes the composition of the interdisciplinary SWIFT team that performs the SWIFT process.  This section also discusses important behavioral rules guiding how joint design is performed.

Appendicies

This section contains information that you may want to use as reference material, such as pointers to other books that may help you develop your SWIFT skill further, and Examples of deliverables that might be produced in various steps of the SWIFT process.

References

Here are some references to books and other materials and individuals that have influence my development of SWIFT design practices.  By going to these sources as well, you can deepen your intuitions regarding SWIFT as well.

Examples

Some examples of deliverables from various stages are included here to give you an idea of what these documents might look like.

About the Course Author

My background is as a software designer and executive with more than 25 years experience designing, developing and managing software organizations, in R&D, Engineering, Product Marketing and General management positions.  I’ve worked at several of the largest computer companies, including ten years at HP, and a stint at Sybase, but I’ve also worked and consulted for many start-ups which is where a lot of new product design takes place. 

While I’ve been General Manager, VP of Engineering, Director of Software Engineering, Product Marketing Manager, and many other titles, my favorite title (which I got to pick for myself) is EXPERIENCE DESIGNER.  As you work through the SWIFT process you’ll see why this is an apt title for the skills this class will train you in. 

At some companies, the locus of product design is Engineering.  In others it is product marketing.  Some places put it in program management. Wherever this responsibility is located, and whatever you are called, if you are determining the requirements and design of new products, you are doing “Experience Design”.  I am hoping this class will help you be more successful in this role. 

I’ve occasionally taught my SWIFT method in classes offered through University of California at Berkeley, and University of California at Santa Cruz, particularly through the extension programs that are aimed at continuing education for current professionals.  I’ve also lectured on this topic many times for the Association of Software Design and also for the World Wide Institute of Software Architects at locations such as Stanford University and Xerox Palo Alto Research Center. 

This method is the heart of my consulting practice, offered through Prescient Software. This consulting is typically offered to senior executives and supports development of business plans, and product plans as well as supporting many fund raising and customer awareness activities, as well as supporting actual implementation of final products.  Although this method was originally developed to aid in the development of software products (my personal area of expertise), I’ve found from the people that I have trained that these methods are applicable to new product designs of all kinds of products, from VCRs and calculators to laboratory instruments and operating systems.

The origins of SWIFT

Designing the Products and Services that Customers want, through Experience Design

I developed the SWIFT process over a period of years from my experience designing and developing products at several companies, but particularly at Hewlett-Packard between 1980 and 1990.  During that time I developed several technically interesting products, which were not commercial successes. While it was great to be the subject of an editorial in a major computer magazine (Unix World) because of these technical successes, and to be invited to speak at many conferences, this was ultimately unfulfilling, because we weren’t able to commercialize our products. 

As I became more aware of the reasons our work couldn’t be commercialized by HP, I resolved to avoid this situation in the future by ensuring that a commercial market would be available for my products before building them.  At the same time, I had seen far too many product designs that sales departments were eagerly building but which engineering could not build.  I didn’t want to make that mistake either.  So I set out to figure out how to build products that could sell, and sell products that could be built.

SWIFT came out of this, and my first success with it came shortly there after when I lead the design of MergeAhead, a simple product that allows two people to simultaneously edit the same document (e.g. one programmer fixing bugs and another developing new features) and then use MergeAhead to combine them into a single document with everyone’s changes.  This product received a cover notice in Sun World at introduction, because of its simple and elegant design – a rarity in most version 1 Unix products at that time.  Seeing the many users benefiting from frequent use of MergeAhead and its successor MergeRight has been very rewarding.  If I go to the trouble of building a product, I want to know that the efforts of my colleagues and myself will not be in vain. Seeing customer testimonials is the highest personal reward.

What does SWIFT mean?

SWIFT is actually an acronym for SoftWare Imagineering Fellowship Teams.  This captures part of the initial insight and impetus to SWIFT.  The Software part is obvious, I was developing Software products and so that was what I was designing a process for (though it turns out to be applicable to many other areas).

Imagineering is a word coined by Walt Disney to capture the essence of an imaginative understanding of the needs coupled with artful engineering of solutions.

Fellowship Teams is a name I used to distinguish a particular kind of cross-disciplinary team.  I’ve found that the best way to ensure success is to ensure that all the bases are covered, and that every discipline has some bases it covers better than others, others that it does less well.  By building inter-disciplinary teams we can have the ability to get the strength from multiple disciplines and participants.  For instance, when I developed MergeAhead, I had a technical writer and a trainer involved in the design – but their goals were different than usual, this time it was to help ensure that no manual was necessary (because no one would want to have to read one) and that no classroom training was necessary (because if the product required it, people wouldn’t adopt it quickly).

Fellowship teams differ from other interdisciplinary teams in one particular way.  In many teams there is a pecking order: Senior Manager, Engineers, Marketing, Technical Writers and Trainer, Support staff.  But this pecking order gets in the way of good results when there is a question that is really the domain of expertise of someone low on the pecking order (like Technical Writers or Support staff).  Often time their very valuable contributions are ignored. 

So to avoid that, in Fellowship teams we have a rule.  Every member must have at least one area where they are regarded as the final expert, or resident “Fellow”.  They are required to LISTEN to input from any other member in any other area.  But in any design decision concerning the fellow’s specific area of authority, they will have the final decision.   I find that this not only builds better respect and working relationships among the team members but it avoids some of the real problems that can occur when design is performed by consensus in a committee (Remember the old joke that a Camel is a horse designed by a committee?)