Ministry Design

There’s one aspect of ministry design that we have yet to discuss on this blog.  (I’m sure I’ll think of more.)  It’s how to get a ministry design effort started in the first place.

Since I’m writing to and for people who are interested in the processes of ministry design, it’s likely that you, my readers, are the ones to whom your church or parachurch organization turns to facilitate design.  It may be you, but it’s mostly likely some other leader, who has the idea that a new ministry is needed or that an existing ministry is desperately in need of improvement.  Then, you get called in and asked how to proceed, how to get the ministry design started.

It would be tempting to answer that the process begins by pulling together the requirements for the design or redesign.  However, that’s never where it begins, because there are always people, stakeholders, who have to buy-in to the need for the design effort and to the approach to be used.   The need, the driver, for the proposed effort should not be a problem.  It should be available from the motivation to start it in the first place.  However, some effort is needed to select the design approach, since there are many options to choose from.  So, you help select the best approach.  Then, the fun begins!  How in the world will we explain the need and the approach to the stakeholders?  The short answer is wit and wisdom, and I can’t suggest how to get that, but I can suggest several tools that might help in the needed “sales process.”  Here are some of my favorites:

• An Elevator Speech. Every sales rep. has one of these.  For a ministry design effort, it’s the description of both ministry to be designed and the approach to design, summarized to the point that it can be recited on a two-floor ride on an elevator.  There are many people who are interested in the effort but satisfied by this much information.  It’s a good start for the others.
• An Approach Summary. The approach that you and the ministry leader you are helping want to use for the effort will be more difficult to explain than the reason for the effort.  I have found it helpful to write a carefully thought-out one-page description of the methodology.  You may hand it to stakeholders, but, more importantly, you know much better how to describe it.
• A Design Team Charter. Many organizations use somewhat formal charters for their design teams.   A charter can be particularly helpful, whether required or not, because a good charter gives the purpose, scope, authorities, responsibilities, approach, and composition of the team.  They give evidence that the leader of the team has thought through the whole design process and its significance.
• Sample Products. It often helps to show decision makers what a completed design might look like.  This can be particularly helpful if some design products are graphical.  One example product I have found helpful for my Story Method is a sample story of a typical client experiencing the ministry.  Another is a map (techies call it a flow chart) of how a client would progress through the parts of a ministry.
• Testimonies and Endorsements. If the proposed ministry design methodology is in question, it helps to have statements from people who have experienced it tell how it worked for them.

Well, that’s the list that fits my post-length goal.  I’m sure you can add to the list, and I truly wish you would.  Tell me what you’d add.  Let’s get some action going around here.

This series of posts – the series that discusses matters that affect ministry design — is nowhere near comprehensive.  On the other hand, it has included several important points for understanding the needs of the ministry (Part 1), identifying components that could comprise the ministry (Part 2), and finding the relationships between the ministry components (Part 3).

During our discussion of these three topics, we have often mentioned the need to implement or flesh out our design before we can begin to invite people to benefit from its ministry.  My purpose here is to discuss implementation.

By implementation we mean preparing the various parts of our design and putting them together so that the ministry is “ready to go.”  This might mean something as straightforward as preparing a talk.  In contrast it might mean performing additional design to understand the details of a particularly complex part of our ministry.  In particular, if we have created a component during our ministry design that summarizes or nests several related components, and if we are not sure how this composite component fits together, then we have a design problem we must solve before we can proceed to implementation.

A few more examples of preparation might be helpful.  For our homeless dinner we know there’s a meal.  Preparing for the meal involves choosing a venue, designing a menu, setting up and setting the tables, and the like.  Letting people know about the dinner means we must figure out where to make its availability known, how to make it known, and printing or otherwise distributing information to the homeless people about when and where they can come.  For our homeless audience word of mouth is often very effective.  If our design includes a time to share the Gospel or pass useful information on to our guests, then we need to plan the program, secure the speakers or videos, and make audio/visual arrangements.  These are all preparation steps.

You, the astute reader, have probably already observed that many of the steps I have used to illustrate preparation could just as well have been described as design. They amount to designing the details of the ministry.  This is virtually always true.  A key issue in design is to know when to stop.  My rule of thumb is to stop designing formally when those who will prepare know how to do the rest without further guidance.  Rarely would we have to tell a chef how to chop onions.

So, what can we say about implementation?  Well, the first and easiest is that every component of the ministry needs to be implemented.  The second is that the various components need to be implemented in such a way that they work together.  It’s entirely possible that making them work together would require either that they be adjusted a bit or that something needs to be added to the design to make them work together.  But, of course, a good design team would have anticipated this. (??!!)

Let’s add to all this one more observation, and that is that the hardest part of implementation is planning it; that is, determining the sequence in which the various components need to be implemented and estimating how long each of the implementation steps will take.  This work is known as project planning, and there’s plenty of literature on this topic, so we’ll leave it at that.

That’s it.  We have a design, and we’ve figured out how to implement it.  For our example, the next step is to feed the hungry, and that’s a worthy thing to do.

So … in the past two posts we have uncovered some things our homeless ministry requires and, from these needs, identified several parts that are quite likely to be components of the dinner.

We recognize that, before we’re done, each of these components will have to be developed; that is, be well understood and fleshed out, so they are ready to serve their role in the dinner.  While for something as simple as a dinner we pretty much understand each of these parts and how to develop them, in other cases some components will not be so familiar and will require a design of their own.  In any event, it is good practice to write down what we know about each component before we continue with design.

However, there is one thing we need to know about every component of a ministry.  This is how the component is related to the others that compose the dinner.  In a previous blog post I discussed three kinds of relationships that components may have.  We gave these the names composition, collaboration, and specialization.  Here we’re particularly interested in composition and collaboration.  Specialization comes into play during the development of each detailed ministry, and we’ll postpone its discussion until a later post.

Composition recognizes that ministries can contain other, more detailed ministries.  So, when we look at our homeless dinner, the first question we should ask is, Are any of our identified components logically a part of one of the others?  Obviously, they are all parts of the dinner.  They are “nested” within it.

As I look at the list of dinner components we identified in my last post, I find only one that has components of its own and this is what we called the dinner.  To avoid confusion with the whole homeless dinner, let’s change this component’s name to “the meal,” rather than “the dinner.”  Now, we noted in identifying the meal that it is comprised of at least tables, chairs, silverware, dishes, and food.  These are nested within the meal component.  So, our dinner ministry design currently has three nested levels.  These are the whole homeless dinner ministry, supported by its key components (the meal, publicity, a planning team, etc.), and the meal, which is supported by tables, chairs, food, etc.

It is important to find composition relationships because they greatly simplify design and development.  In this case we can talk about the meal as a single entity and not worry about its components while we’re thinking about the whole dinner.  Then, we can design the meal independently of everything else.  The meal component represents all of its own components.  We can say it encapsulates them.

Collaboration is different.  It is what we usually think of as a relationship.  Given a bunch of ministry components, collaboration is how they work together.  As noted in an earlier post, there are two different approaches available to a design team to express collaboration: dependency by precedence and dependency by assistance.  We’ll not elaborate here because we did in the previous post.  We’ll focus here on dependency by precedence.  It is easier to understand and describe.

To identify the dependencies on our design, we ask each component, On what is this component dependent; that is, what has to happen before this component can happen?  For our homeless dinner, I think it is clear that the sequence of dependencies would be (1) the planning team, (2) publicity, (3) homeless people who come to the meal, (4) people to prepare and serve the meal, and (5) the meal.  A place to hold the meal happens at the same time as the meal. In this case both the meal and the venue have the same dependency.  This should be clear.

Please note that each of these components needs to be developed; that the design must be fleshed out to the point that the homeless people can start coming.  But this is development work.  It is not part of the design of the ministry.  We’ll talk about this in the next post.

Last week’s post was the first part of a discussion of some general challenges of or approaches to ministry design.
In it we focused on understanding the needs of our new ministry.  Recall that we selected as our challenge the design of a weekly dinner for homeless people.

In this post I want to make two observations  about the design of that ministry:

1. First, although in the previous post we didn’t state more than the most obvious of the needs driving the dinner ministry, we stated enough for us to get started on design.  We’ve said this before, but I repeat because it’s important to let it sink in deeply: All Design Is Redesign.
   At first. this aphorism suggests that whenever we design we should look for and embellish whatever previous design we have for the ministry.  And we actually have a previous design, a very simple one.  It is the design implied by the statement of our challenge: a weekly dinner for homeless people.  Most of us could picture this dinner in our minds and synthesize a pretty good picture of — that is, a pretty good design for — how it works.
   But there’s another application of the aphorism available to us.  This is that, if all design is redesign, then we should approach every ministry design challenge with the understanding that it need not be perfect.  We can always go back and redesign again.  We relied on this understand when we agreed that we have stated enough needs to get started on our dinner design.  If our design team had worked harder to uncover more needs, we’d use them, but since we’d like to get a quick look at what our dinner ministry might look like, we settle for the obvious needs and move on to the design phase.  We will undoubtedly return to redesign again.
2. Another observation is an answer to the question, What exactly do we mean by design?
   We mean several things, but one important one is that our dinner ministry has parts. We know this from a couple of observations from earlier blog posts, starting with A Ministry Is An Examaple Of A System. Since the definition of a system is “a set of connected things or parts forming a complex whole,” we know that A Ministry Is A Set of Connected Smaller Ministries.  And,if we don’t know what those smaller ministries (or ministry parts) are, then a huge part of our design challenge is to identify them. Fortunately, while indentifying them is hugely important, it is not very difficult. We have already hinted at several of them for our homeless dinner. I see:
   • Homeless people
   • A dinner (tables, chairs, silverware, dishes, food, etc.)
   • People preparing and serving the dinner
   • A place to hold the dinner
   • Some kind of publicity, letting the homeless know the dinner is available
   • A planning team

   This list is clearly not complete, but it covers everything we mentioned as needs, except it does not include any mention of the fact that we want the dinner to occur weekly.  This need is not a statement about what’s in the ministry, but rather about how it will operate.  We’ll have to treat this need a bit later in design.

Regardless of what design method we use, if we’re going to design a ministry, we need to know we can alwasy come back and make it better and we must first to identify its parts.  We have a good start at these.  Next blog post we’ll talk about what we do with the parts.

P.S.: (Want to find the component ministries easily?  Look for the nouns in your description of it’s needs.)

Ok.  Enough theory.  Today, let’s start to address a typical ministry design challenge.  What I have in mind (mostly because it’s new to me: I have not thought much about this as a design challenge before) is a weekly dinner for homeless people.  For this blog’s purpose this challenge has the benefit of fitting either a church or a parachurch organization.

My hope here is not to suggest a design nor to tell a design story.  It is simply to talk about what is involved in a design such as this.  There are, of course. several ways to address this challenge, and my purpose with this blog is to create a dialog about the various design approaches that might be applied, not to advocate an approach.  But, let’s admit it, I wrote a book about a specific method, and I’m not likely to stray too far from that.

For any design the first step is to say what needs to be done.  This step is generally called the requirements phase, but let’s not get fancy.  In setting out our design challenge we’ve already said quite a bit about wha the homeless dinner ministry is to be:

1. A dinner
2. For homeless people
3. Weekly
4. Done by our organization (whatever it is)

And, from simple logic, these observations imply a few other things:

1. There needs to be a place to hold the dinner
2. The homeless people need to know the dinner is available
3. There needs to be a menu, and it probably will need to be somewhat varied; that is, planned weekly
4. So, there needs to be a planning activity
5. So, there needs to be a planning person or team
6. It involves a loop; that is, several of the same things happen week to week.

That’s about it for simple facts and observations, but it’s not nothing.  I’m sure some design teams would begin design just from this.  However, most design teams wouldn’t stop here at documenting what needs to be done.

Under the Story Method of my book, Tell Me A Story: Creating Life-Changing Ministries from Stories, the team members would now each write a story about how someone (the protagonist of the story) would experience the ministry.  Some of the protagonists would be homeless people; others would be those who serve in the ministry; still others might identify another, still different, participant in the ministry.  Together, these stories will be rich in demonstrated needs (and, it turns out, in design concepts — we’ll consider these next week).

Under different design methodologies something other than stories might be used.  These could include needs exhibited by:

1. Analogies from other group’s homeless dinner ministries
2. Brainstorming of ministry ideas
3. Focus group interviews.

In my next blog post we’ll walk through some approaches to creating a design from these needs.  I’d like to continue here, but … well, too many words.

My apologies to Mr. Hemingway.

I’ve been thinking (I know, watch out!), whom, exactly, am I hoping will participate in the community this blog builds?  My answer is below and includes a lot of different kinds of people.  I’m guessing, though, that as this community builds, I’ll only be half right.  Nevertheless, I think it would be helpful to know what I think is possible.  Here’s my list, given in approximate order of their interest:

People who Design

Working-level pastors.  These are the pastors who have direct, hands-on responsibility for the development and conduct of their church’s ministries.  Just who these pastors are depends on the size and structure of the church they serve.  For a small one-, two-, or three-pastor church all of the pastors are likely to be in this category.  For a medium-sized church this category is likely to include all but the senior pastor.  For a church that is larger still there may be a layer of supervising pastors above those who have this direct ministry responsibility.  In any event if a new ministry is to be crafted, these are the pastors who do it, and these are the pastors who should have a significant interest in how to design.

Ministering Lay Leaders.  In many churches there is a close partnership between pastors and lay leaders.  No church has enough staff, so some ministries must be designed and led primarily by lay people.  They need to be thinking about how to design.

Program-level leaders of para-church ministries.  These people are the para-church equivalent of working-level pastors.  While pastors often have the help of engaged lay leaders, parachurch program leaders are often out there all alone.  Still, program leaders are called upon all the time to design and need to know how.

Christian Geeks.  (I use the term geeks lovingly.  Many people consider me one of them.)  These are church members (and, rarely, a pastor or two) who are fascinated by technology and see places where it could help in ministry.  It is obvious that they can manage the technology that is employed in ministry, but, because geeks are comfortable designing things, they often understand the design of a ministry as a system and can suggest improvements and direction from that unique perspective.  Besides, it’s often nice to have someone who likes to design helping those who just want to “get on with it.”  A forum for them should be quite helpful.

People who Oversee Design

Supervising Pastors.  In all but the smallest churches (and by number this is by far a majority of churches), working-level pastors generally report to a more senior pastor.  While these supervising pastors are not usually directly involved in the design of a ministry, they nevertheless have responsibility for it and (1) should be aware what’s in a ministry and how it will work and (2) may from time to time during design be called upon to provide or approve decisions on design matters.  For this reason they should have at least some familiarity with design processes and can be instrumental in assuring that better design methods are employed.

Parachurch Executives.  As for program-level leaders, executives of para-church ministries are the equivalent of supervising pastors in churches.  Like supervising pastors these executives are accountable for their ministries and should have some familiarity with design methods so that they can knowledgably enter discussions and decisions as needs arise.

Church Elders and Church and Para-church Board Members.  Elders and Board Members typically do not participate directly in ministry design, unless they also participate as a part of a specific ministry team.  On the other hand these leaders are often called upon to authorize or provide funding for a design.  While they do not need to be able to design, they can benefit from knowing how designs are done and understand why one method might be better than another.

These are those For Whom the Blog Trolls.

This is not a hypothetical topic.  It actually happened to me.

As I was learning about better models, I realized that what I learned about models also applies to the the systems that are modeled.  Better models provide insight into or approximate key characteristics of a system. So, if we are designing a system, these insights can be quite helpful.  I’ve said it before, but let me again claim that ministries are systems.  To justify these claims please let me go back to some basics.

The Google dictionary defines a system as “a set of connected things or parts forming a complex whole; … an organized scheme or method.”  This definition makes it pretty clear that a ministry is an example of a system.  It also suggests that

1. a ministry is a collection of things,
2. the elements of that collection are somehow connected, and
3. a ministry is an organized way of doing things for the Lord.

In this blog we have talked over time of each of these suggestions in the context of a ministry, so the conclusion that a ministry is a system shouldn’t surprise us.

A key thing I learned from some of the better models is that there are only three types of relationship that can exist between the collection of things that make up a system.  (Some models have fewer.)  Since a ministry is a system, this is, then, true for ministries.  I think it can be very helpful for a design team to quickly go through a check list of three possibilities and not have to wonder if there are more.

So, what are these three types of relationship?  Their formal names are composition, collaboration, and specialization, but before you glaze over, let me describe them.

Composition.  Composition means that a ministry can be composed of other ministries.  This is familiar: a student ministry is often composed of an intermediate school ministry, a high school ministry, and a college ministry.  We have talked of this before when we said, “every part of a ministry is a ministry.”  It works the other way around, too: W can look for opportunities to “compose” a ministry that includes several parts.  This often simplifies design.

Collaboration.  Collaboration means to labor together.  A synonym is cooperation, which means to operate together.  Ministries are interdependent; one ministry can depend on another.  There are two (at least) ways of picturing this:

1. What I will call dependency by precedence. Here we simply note that sometimes we will want one part of the ministry precede another.  For example, we might prefer that someone take a Bible survey class before proceeding to an in-depth study of Romans.  We can show this graphically.  Suppose we have two ministries, A and B.  If we would like ministry A to occur before ministry B, then we can draw a picture with two boxes, labeled A and B, with A to the left of B.  To this we add an arrow pointing from A to B, emphasizing that A happens first.  Dependency by precedence is the dependency used by my book, Tell Me A Story: Creating Life-Changing Ministries from Stories.
2. What I will call dependency by assistance. Here we recognize that some ministries will need to be supported by other ministries; that is, helped by more than just precedence.  For example, a Bible class teacher might need the assistance of a church’s audio-visual department for some artwork.  In this case the teacher requests support from the AV department, and, in time, the AV department returns a finished visual product.  Graphically, if we have two boxes, one labeled “Teacher” and the other “AV”, we would show teacher on the left and two arrows liking Teacher and AV, one from teacher to AV to show the request and one back from AV to teacher to show the AV response, the artwork.

Interestingly, in its simplest form, the “precedence” approach can be represented under the “assistance” model with only the backwards arrow, showing that, to use our example, the AV work precedes the teaching.  Of course, this immediately shows the usefulness of the more powerful model.  Because there must have been a request for the artwork, the ministry design team should ask, “what caused the AV department to do the artwork?”

Specialization.  Specialization means to make something special, set apart from the ordinary.  For a design relationship it generally means to change something simpler into something that better fits a need.  Imagine, for example, the simplest form of worship service.  Let’s call it the 3P approach: Praise, Prayer, and Preaching.  Now let’s imagine that the worship team wants to add holy communion to the 3Ps.  The resulting worship ministry will include all three Ps plus communion.  This communion service will be a specialized version of a regular 3P service.   We might also say that the communion service inherits the 3Ps, and its design includes something more; namely, communion.

So, there you have it, a checklist for our ministry design team.  Every time we add a new ministry element to our design, it is very easy and helpful to ask,

1. Is this ministry part of the other ministries of our design or does it include some of them?
2. Does this ministry depend on other ministries of our design either by precedence or assistance?
3. Can we design this ministry by inheriting its design from a ministry we already have and making it different or better?

This post is a week late.  For those of you who follow me, I’m sorry.  I intend to post at least weekly on Mondays.  I think it might help explain my tardiness if I tell you that a week ago we lost my dear wife’s beloved brother, Myron, to pancreatic cancer.  We’re grieving, but we know he’s healed and jumping for joy.

In my previous blog post we discussed the necessity of providing a ministry design team with a graspable and powerful tool for capturing the results of the team’s design efforts.  It’s an adage, but certainly true, that if a team does not document (record) its findings, then there is really nothing left but memories – lots of them: each different.  Why?  Because we each remember different things.   To minister, we need a single ministry concept to which we can all subscribe and which can be implemented to accomplish the ministry’s goals.

In that previous post we went on to observe that the tools available today to capture designs are much more powerful and easy to use than ever before.  Today I’d like to focus on what are arguably the most powerful of these tools: models.

Remember models?  In earlier posts we noted that models are powerful because they have the virtue of the thousand words of a picture … plus!  They may not reach a million words of value, but in terms of utility, they may exceed that.

Modern models are more powerful than ever — in part because along with the innovation that improved them came a deeper understanding of how complicated things work.  Techies call this understanding systems theory.  Please don’t glaze over yet.  Our topic here not systems theory; it is a continuation of our discussion on how to capture our ministry designs.

Models are now better on paper (or, these days, on a screen) because we have a richer set of modeling options (I’ll describe two categories of options in a future post).  Once we learn to prepare and read them, they pack a lot more information on a page than yesterday’s simple diagram, just as a picture of the front of a building (or another pictorial view) is better than just a floor plan.

However, the real power of models begins to emerge when they let a design team “walk through the design;” that is, to gain an understanding of how it will feel to the people who experience it.  This can be done, for instance, with a version of role play, where each member of the team describes how people will experience a different part of the ministry.  In walk-throughs, a team can keep track of not only the flow and feel of the ministry, but also of key performance parameters, such as how many people might be served at each stage of the ministry, how long it would take a person to go through that stage, or what range of outcomes might be expected from it.

Even more power comes from transferring a model to a computer, using software that allows a team to simulate the operation the ministry.  Simulations mimic a team’s walk through with the added benefit of going through the ministry quickly and many times, with different assumptions each time (for example, a different mix of people participating in the ministry.)

My trail of blog posts so far doesn’t allow me to substantiate my claim, but it’s important to know that I believe based on experience there are very powerful tools out there that can give us much better ways to capture and communicate our ministry designs and, in the process, gain confidence that our designs will accomplish what they set out to do.

Designs are ideas.  They are ephemeral things.  The problem is that until they are captured into something more concrete than our minds, we don’t have one design, we have as many designs as there are minds involved.  So, we need to ask, what might a ministry design team do to make sure it has only one design and not as many as it has designers?  In short, how can we capture and gain agreement on our team’s design?

Historically, there were three answers to these questions.  They were

• Words and documents
• Sketches and drawings
• A model: a scaled-down version of the product of the design (in our case a ministry) that emphasizes its major points.

Words have the benefit of allowing a complete description, including the rationale, of a design.  Sketches and drawings have the benefit of summary: they fulfill the aphorism that one picture is worth a thousand words.  They also seem to provide a better – or at least easier – connection than words to the way the human mind works.  Models are even better than pictures, but they are often a lot of work and, because they need to be approximations, they can be unintentional misrepresentations.

In many ways these historical approaches to capture a design are still today’s most common tools.  If a team announces it has just designed something, two of the most common questions that team will be asked are, “Did you write it up” or “Will you show it to me?”

True, today it is easier to write, sketch, and model than it was in times past.  We now have much better tools: word processors, spreadsheets, drawing software, team collaboration software, and even 3D printers, among others.  Ways to use these tools have evolved with them.  These range from simple forms to collect data, to fancy software systems that can turn collected data into impressive illustrations, to impressive three dimensional animations.

The utility of fancier tools to our topic, ministry design, is not immediately obvious, but who knows?  While the message is ageless, rooted in God’s plan, ministry approaches move with time.  How long ago, for instance, would a ministry design team have needed to design and build a television recording studio?

If this blog is to explore better ways of conducting ministry design, then we need to understand how better to perform this issue of capturing ministry designs.  And with that we need to keep in mind the issue of working “Across The Cerebral Divide” that I addressed in a previous blog post.

One thing, however, has to be clear.  We need a method to collect our design ideas as we go along, and this method has to help us:

• Bring our team’s design ideas together into an agreed-upon whole
• See the whole of our evolving ministry design and comprehend its interactions
• Explain our design to people outside of the design team.

So, it’s important early on in a design team’s activity that it settle on at least an initial plan for capturing the output of its work.   Agreed?

My book, Tell Me A Story: Creating Life-Changing Ministries from Stories, shows how an intricate ministry can be created by combining ideas from several stories. There’s a good reason why this works. It works because each story portrays one person’s version (vision) of a design for the ministry from the eyes of the protagonist he or she chooses (or, perhaps, is assigned) for the story.
Then, when the first story is considered by those working to develop the ministry, that team puts the story ideas into some convenient format (the book suggests some good ones). As soon as the second story is considered, the team begins to redesign the ministry. It takes the best features of both stories and makes a single, improved ministry from them. From then on, it’s redesign, redesign, redesign.
It’s true in general that virtually all ministry design is redesign. Even in the simplest of cases, for example, when one person sits down to design a very simple ministry. That individual comes to the chair with some ideas of what the ministry should look like. The next minute he or she is trying either to express those ideas in some form of document, outline, or diagram or to improve them. And the process proceeds by alternating randomly between documenting and improving, by capturing a design and redesigning it.
The approach of my book, what I call the Story Method, is almost exactly that. That is, it alternates between documenting and improving a design, capturing it and redesigning it. The only difference is that I describe a simple, orderly way to do this. I define a process that divides it into a sequence of steps, rather than a random walk.
We can say that the Story Method exploits the general principle, the aphorism, that all design is redesign. If you think about it, just about everything that is designed goes through a process of successive redesigns.
• An artist lays out a canvas, begins to sketch out his or her ideas, moves things around a bit, changes their size, begins to fill in the sketch, changes shapes, changes colors, scrapes a bit off to do it better, and so forth. The canvas captures the design, the changes are redesign.
• An architect does the same. The client comes with a mixture of specifications (three bedrooms and three and a half baths) and design ideas (master bedroom on one side and the other bedrooms on the other side). The architect turns this into a sketch (or two or three), the client suggests changes (not all of which will work), the architect resketches, the client changes some more, the architect draws a floor plan or picture of the outside, the client makes changes, and on and on until there’s no sense in changing more.
• An author gets an inspiration, writes a short description of his or her book, perhaps develops an outline, perhaps creates storyboards, and then writes, rewrites, rewrites, and rewrites, changing as he or she goes along. And then, of course, somebody else edits and makes lots of changes and suggests some more.
Design is all about capturing and changing. All design is redesign.

ID 50309123 © Feverpitched | Dreamstime