You are on page 1of 8

The Design Process: Differing Published Approaches to the Design Process for Graduate Designers.

Executive Summary
This paper is intended to look at the design process. It has a focus on experience and how this affects the process one adopts, and also, in turn, the development of a designer as they gain experience. It includes an evaluation of six of the leading published design processes giving a good scope to the research, and showing not only the similarities between them but the differences too. There is then the inclusion of an experiment using the Verbal Protocol Analysis method, analysing a fourth year student design team carrying out a task. This serves as a very different way of analysing and studying the design process using a thinking aloud method to see how people work in a teamwork scenario. The results showed that the experienced students showed a lot of the characteristics suggested in many of the design processes evaluated in the literature review. This goes forwards to back up the notion that a designer will develop their own personal design process, taking influence from other sources, but giving it their own distinctive qualities. Experience in design teaches a designer better than any published book as it is the doing and the seeing that really makes a mark on a person. Being taught to follow the general pattern to almost all design processes, though, especially iteration and evaluation, is only ever going to be positive and should be encouraged.

Introduction
Imagine that you are in your first job as a designer and your manager has asked you to lead a team of three or four graduate designers working on a new design project. Before you start any design work, she has asked you to carry out a small research project and make recommendations on the following questions: What design process will you use? How does this process compare with other processes you might have selected? What behaviours are you going to encourage during the design activity and why? So the premise of this report is to investigate and evaluate a variety of design processes leading to a conclusion which addresses the three questions. The processes are all differing in some element, and this gives a good scope of comparison. A graduate designer will have their own process which they have developed whilst in education, but the influence of a published and trialled method could help to improve their approach further, producing better results. This is a key point of discussion for this report. The report is structured in a simple progressive manner. It starts by attempting to define a design process, which gives clarity to the questions being addressed in the report. The System Design Process (Blanchard and Fabrycky 2006) is then described in detail as a point of comparison for the other processes as it provides a thorough and detailed practice. The next section then looks at five other design processes and finding points of comparison and difference between them and the System Design Process. This gives a good scope of reference literature to then be able to draw conclusions from. The Verbal Protocol Analysis [VPA] technique is then described and explained, with results observed in a recent implementation of the technique analysed and evaluated. This is then tied in to the reference literature in the discussion section, giving yet more comparison leading to a final concluding piece addressing, and in the context of, the questions set in this introduction.

What is a design process?


The term, design process is harder to define than immediately appears. Clearly it is the process or method you use in order to design something, but it is at this point it becomes evident how broad a spectrum the term covers. The method is something that can be very individual, and often is, and the end design again could be any number of outcomes. There are countless published approaches to the design process, and then countless more adaptations of these, all of which have an element of subjectivity about them.

As a graduate designer, being exposed to these approaches appears have both positive and negative effects, a topic that is discussed fully later on in this report. Getting a graduate to think more like a senior designer, and recreate their process, could be a good way to develop the more junior designer into having a more structured creative mindset, producing better results. There is also a case for saying that by being influenced or even confined by a structured, methodical approach, you could be restricting the designer from their own personal process, resulting in a substandard end product. Comparing every published design process would be a fruitless endeavour as many are very alike or at least share some similarities in the way you progress to a final design. For this reason this report looks at six processes with different ways of approaching the conception of a new design by a team, the first being the System Design Process.

The System Design Process


One of the most in depth published design processes is the System Design Process, developed by B. S Blanchard and W. J Fabrycky (2006). Being maybe the most in depth method, it is a very good point of comparison to the other processes. The basis of the method is to design a system to solve a problem or need, using a strict system of evaluation and validation at all stages of development to ensure the system is as efficient and optimal as is achievable. For reference, the term system in the context of this process means a number of components assembled or connected to form a larger unitary, integrated whole (Blanchard and Fabrycky 2006 p.3). This system could be anything from the enormous London Underground system, to something simple and widely used like a key and lock system. This design process is extensive but can be broken down, and for the purposes of this report, abridged, without losing any of the relevant material as some fragments of the process are not wholly relevant to this report. The book divides the process into four sections which will be used here also. The first section is the Conceptual Design stage. At this stage a team will be looking to identify a need or desire within the given area. For example if a current system is not meeting the necessary performance goals or is too costly and inefficient, then it can be improved by design. Given this need the next stage is a system feasibility analysis which is fairly self-descriptive. The team will evaluate the problem and the likely ways of solving it making sure it is not beyond their capabilities to actualise a solution. At this point the team can then develop a system requirements analysis. Operational requirements are a large proportion of this analysis answering questions like, How long is the system to be operated for, by whom and in what location. From these requirements the team can then define the system specification which is necessary to conceptualise ideas. At this point there is a deliverable, the Systems Engineering Management Plan. This serves as a record of the project, denotes team roles and also the method by which prospective tasks will be carried out. The final stage is one that is consistent throughout the System Design Process, and that is evaluation. At the end of each stage there is a formal audit to review the teams proposed system and establish what is moving forward. The conceptual design review is specific to this first section, and the design directions are put forward to the preliminary design stage. (Blanchard and Fabrycky 2006 chapter 3) The second section is Preliminary Design. The team will be looking to see if their system concept can be developed within all the existing constraints, like time and cost. To make sure the system is understood in full detail the team will then develop some sub system requirement using a top-down and bottom-up approach, discovering the lowest level of system components and everything in between. These can then be used to draw up detailed specifications defining the technical requirements for the system which allows the team to develop the detailed design requirements. These play an integral role in what is subsequently designed as they define the basic design objectives for the system. There is little mention of individual concept generation but it is assumed to be an ongoing process throughout, coming together as a team to evaluate designs. The team at this point will use engineering design tools like CAD to develop concepts further. Before moving onto the third stage there is again an evaluation stage. Trade off studies will be carried out and it is a good time for any team members with any concerns or flowering ideas to make them vocal. Some members may be more introverted and it will take this coming together for them to express opinion. (Blanchard and Fabrycky 2006 chapter 4) The third section is titled Detail Design and Development. Having evaluated the generated concepts, and the project itself, the team will revise and update the Detail Design Requirements. This is really just a continuation of the iterative system development process. The next stages are where the real design side of the process become familiar. The assembled design team is given individual design direction to suit their expertise, akin to the economic term specialisation, having the team members each do what they are best at. The team designs the sub systems to the specification and requirements and then must integrate the system elements. These can then be modelled using CAD and other design tools. The use of design data and

information, such as design drawings and analyses, is integral in this stage in informing the designer, ensuring the elements are correctly designed and modelled. From this point onwards it is really just a development from a basic model to prototype to final product. The team will then test the prototype in its environment and then review for any changes that need to be made to correct any design deficiencies or even to incorporate a new technology. This is the third stage of evaluation. (Blanchard and Fabrycky 2006 chapter 5) The fourth and final stage is Testing and Evaluation. Once the design has been ironed out and any easily identifiable design deficiencies are eliminated it is time for extensive testing against the detailed design specification. As this stage can be very expensive it is vital that the previous stages, particularly the evaluative stage at the end of the third section, are carried out proficiently to avoid wasting money on a prototype that will fail testing. This process of iteration and evaluation throughout the process is demonstrated very clearly in Figure 1. by the Royal Academy of Engineering (2007). You can follow the process up to this point on the top left Accepted System. This illustrative view makes it a lot easier to decipher what is being explained in this part of the report. The team will collect data and analyse it and any system modifications that are deemed necessary from the data, analysis and feedback can be examined at looking at the cause-and-effect relationships to show any deficiencies in an element. (Blanchard and Fabrycky 2006 chapter 6)
Figure 1. Systems Procedure. (RAE 2007 pp.16-17)

The book and the process, although very detailed and resourceful, are fairly longwinded and condensing them for this report is a challenge. It could be argued that an approach like the System Design Process is maybe better suited for a more high risk venture, be it monetary or a risk to health, as the levels of evaluation and iteration could be more time consuming and expensive than they are worth. As a learning tool though, the book could be invaluable as many young designers would not factor in a lot of these stages, and certainly not as much iteration and evaluation in their work. This may be because the stakes are low in education as it doesnt actually cost the student anything more than a few percentage marks if their design is wrong. Designing for market is maybe a process you can only fully learn and appreciate with experience.

Other Published Design Processes


Perhaps a design process more suited to a smaller, lower stakes project is the Product Design and Development process by K. Ulrich and S. Eppinger (2004). There are many similarities between this and the System Design Process but it is the differences that substantiate it. Both agree that there is a front end process of inputs going in, conforming to a specification that the back end can use. The Product Design and Development process though has a more relaxed approach to achieving this result. It accepts that a design process rarely proceeds in sequential fashion, something that the Systems Design Process does not (Ulrich and Eppinger 2004). This means the designers have some flexibility and freedom which is something young, graduate designers may respond well to given that they will not have fully developed their own design process yet. Using a process that dramatically changes the way someone works seems unlikely to draw an immediate or positive response in terms of design output. There is also a much greater focus on organisation in the team and the company with there being a more senior supervisor to report to and be advised by (Ulrich and Eppinger 2004), which will clearly be beneficial to the graduate designers, learning from a person of experience and knowledge, extending their education whilst at work. Another, different example of a more simplified process can be found in, Engineering Design: A Project-Based Introduction by C. Dym and P. Little (2003). This again has a lot of similarities to the System Design Process in the general flow of the process, but some interesting differences and also a novel concept generation approach. The stages of design are more or less the same, with feedback and iteration, but with no decisions made until they need to be. The Systems Design Process does give the impression throughout that you must fully complete each stage before moving on which seems quite restricting and confining,

especially when a decision is maybe not ready to be made by a graduate designer that needs more time to look at the problem and develop concepts. There are also some useful practices for a graduate designer included, most pertinently, ranking of design objectives, which better directs your design, and morphological concept generation, which allows you to generate many more original designs by separating the overall system into sub systems. There does seem to be a better focus on the concept generation side of development than is found in the System Design Process. (Dym and Little 2003) The third process for comparison is Engineering Design Methods: Strategies for Product Design by N. Cross (1994). This book takes a slightly different angle on the design process, using a system of three models which someones design sequence could fit. There is a greater focus on design thinking which is something a graduate should be mulling over. As a designer you have to realise how you work best as when you are working in a team, there is no real point in setting out on a design process and gaining no results as the team is reliant on your part as much as you are on theirs. Use of a different process to the other group members may seem impractical, and likely is, but if the outcomes will be better then it may be worth the inconvenience. Another key point made in the book is around user centred design. Having a focus on which the design centres is ultimately going to change the design process at some stages as the scope of the project is immediately narrowed. The team will almost immediately have an area of concentration, and often it will be the existing products on the market and their problems. This kind of analysis would obviously not be found in the process of a team designing for an emerging market so is something to be considered when generating a design process. (Cross 1994) Having a focus for your design could even be taken a step further. Inclusive Design: Design for the whole population by Clarkson et al. (2003) talks about designing human centrically for inclusivity most likely using a descriptive model, working almost backwards (Cross 1994). This behaviour is a relatively new take on design, something that has developed around a need that was, in some cases, previously ignored. It could be an interface issue effecting millions, or an ergonomic issue effecting just 50 people, but by designing inclusively, it is affectively ruled out (Clarkson et al. 2003). This is an excellent characteristic to develop in a young graduate and would bring great benefit to the world of design if exposed to all young designers and graduates. It is about overcoming the challenge and not just designing certain users out of the product. A very different focus to design is found in Breakthrough Products: Innovation from Product Planning to Program Approval by J. Cagan and C. Vogel (2001). The approach is very money centric and could be viewed as quite narrow minded. The principle notion is that the very best products on the market use high levels of technology and style, and that this is something that all companies aspire to create, leading to increases in profit. This is clearly not true of all companies and probably opposes the principles of inclusive design, as a section of inclusivity is surely cost, and high end products are not available to everyone monetarily. One behavioural concept mentioned though is looking for Product Opportunity Gaps. These gaps are comparable to consumer needs, the difference being that the chosen POG will be the one most likely to deliver a profitable product (Cagan and Vogel 2001). This in some industries, say a large company like Unilever, could be a very useful way of thinking and therefore may be something to encourage in graduates. All of the literature reviewed here informs eventual conclusions well but there is one more major consideration, and that is teamwork. Teamwork itself is not mentioned in great abundance in any of the books above but is patently the underlying factor in deciding on which, if any, of these processes to use in practice. There are a number of ways of testing and analysing how a person works in a team, maybe most famously the Myers Briggs Personality Indicator test, which is detailed later on, but there are much more subjective analysis methods which allow you to look for certain traits exhibited during select tasks. One of the best methods for doing this is Verbal Protocol Analysis (VPA).

One More: Verbal Protocol Analysis


The Verbal Protocol Analysis method gives you the chance to examine how a team works. It could be viewing and analysing your own team or watching another team and understanding how they progressed to a final design. This allows you to better understand not only your team but also yourself and how you work in a team. It then gives you the opportunity to change any traits in yourself that you deem not to be desirable. This section describes a VPA analysis carried out on four fourth year Product Design students at the University of Leeds.

Background to the VPA Method


Verbal protocol analysis is most simply described as thinking aloud. The subject will complete a task and is encouraged to be vocal by being placed in a team. The results are then recorded by the manner outlined in the method section to follow. This method has been developed by many different researchers since the early 1990s, and has been proven effective many times

over too. More recently though, it has been made particularly relevant in the study paper, Comparing freshman and senior engineering design processes: an in-depth follow-up study by C. Atman (2005). In this research paper the study compares the results of design tasks between a group of 61 senior student engineers and a group of 32 freshman engineers. These groups were both set two design problems and verbal protocols were compiled to analyse and compare the design processes of the two groups. The results gained from this showed some clear results that more than suggest that your design process alters over time. (Atman 2005) A study like this gives a good view to the educators on what teachings have been embedded into their students. From this they can review their teaching methods and maybe mould future students more effectively in their time in education. This method could easily be applied to newly employed graduate students and used for the benefit of not only those students but also the employer, as will be explained in the discussion.

The Method
The study carried out to inform this paper involved the team receiving a relatable design task, and being given 25 minutes to complete it. The task concerned designing a traffic calming measure to reduce the risk of collisions with pedestrians at a point well known to the students undertaking the study. The area of road in question was in fact visible from a window in the observation room. The road is a busy route into the centre of Leeds and is situated alongside the School of Mechanical Engineering at the University of Leeds. There is a bus stop is positioned outside the building and there are frequent busses running. On this side the flow of traffic is over two lanes, one being a lane specifically for busses. On the other side of the road there lies a pub, the given point of reference to cross safely to, and a busy pedestrian footway. This side has only one lane of traffic flowing. The students were given the brief and some plain paper to work on. Information, such as cost estimates of traffic crossings and so on, was available, but only by request to the host. This lets you see how proactive the students are, and gives an idea on how much importance they may place on research. The host video recorded the task and this recording was then used for analysis. This is a lot easier than trying to note behaviour live, and allows for a more detailed analysis. This video analysis is carried out by viewing the subject and noting down the category of activity that the persons actions fall into at that moment. A sample is taken every 10 seconds and the task lasts 25 minutes. This means that there is a lot of data and the results are therefore clearer and more reliable. The categories are outlined in figure 3. Each category is part of one of three design steps. These are Problem Scoping (containing PD, INFO and ASSU), Developing Alternative Solutions (containing IDEA, MODALT, FEAS and EVA) and Project Realisation (containing DEC and MODSEL). These are used later on when the data sheet has been filled. Once the subject has been analysed and the data is collected and input the template Excel spreadsheet will generate a graph showing how the subject performed on the task. It gives a depiction of that subjects design process. When repeated for the remaining three subjects, the spreadsheet develops a compound graph combining the results of all four group members. This shows how the group worked as a whole and will highlight if the subject being studied has a differing process to the rest of the group, and how that may affect the group dynamics.
Figure 2. The VPA categories.

The VPA Results


Having collected these results and generated the VPA graph, it is time to decipher what it all means. The shape of the graph is really what is being analysed. Below (Figure 3.) is the findings from the study described here.

Figure 3. Results from the VPA experiment.

These results show a recognised pattern of progression towards a final design; a design process. The problem scoping step is represented in the first of the three magenta blocks at the base of the graph. This is the first stage of every one of the design processes mentioned in the literature review. Every process starts with a problem definition, be it Cagan and Vogels Product Opportunity Gaps or designing for inclusivity, finding a need or a product that is not inclusive. The contrast between the different processes is evident here too though. While the problem scoping stage is occurring as expected, there are also some jumps into both Developing Alternative Solutions and Project Realisation. This is something that is only really mentioned in one of the books, and is something that seems quite different to the System Design Process which is very formulaic and doesnt allow you to progress and think about solutions until you have ticked all of the boxes prior. The Descriptive Model found in Nigel Crosss Engineering Design Methods is the closet comparison to this jumping between steps. This working backwards from a solution is something that was witnessed in this study and some students did suggest a solution within the first three minutes which were then worked on and eventually used for the final design. One of the immediate things noticeable when analysing a subject is their role in the group. Within two minutes you begin to see which subject has taken which role. A clear leader tends to nominate themselves and drive the project forwards, whereas some will stay quiet, thinking, to then voice an idea that they have processed. In this study we will call the leader Subject A. This person developed a plan or process very quickly and had everyone else conform to it. Subject A also kept watch on the time and really tried to keep the group in check. Subject B had a much more relaxed style. This person voiced numerous ideas very early on, often then analysing feasibility within moments and then discarding the idea. This subject was happy to be lead by Subject A. Subject C had a very focused manner, only speaking when they felt something was worth saying, often a comment on feasibility relating to the information they had at hand. This subject was clearly looking to research the problem and really understand it before making any decisions, a process seen again in all of the books in one way or another. The final student, Subject D, was very quiet. They said very little throughout the process, and only really spoke to agree on movements in development. This person would be seen as very introvert, something that can sometimes lead other members of the team to disregard any comments that they do make. The team after around 10 minutes moved on fully to the Developing Alternative Solutions step. They felt as if they had researched the problem in detail and could now develop some solutions to it. For a short while discussion is far less prevalent and all of the subjects sketched ideas, often referring back to the information for reassurance on their chosen design directions. This step was only really completed when the team were given a verbal 5 minute warning. This pushed the team into having all concentration on the project realisation step. All subjects sketched the chosen idea, a traffic island crossing point, and compared their visualisations of the idea. It is interesting to note that with just 2 minutes remaining the team returned to the problem scoping step and evaluated the design to the requirements. This is common practice in many of the published processes, none more so than the System Design Process. The team had designed a solution to the problem fairly effectively in the given time. The solution was feasible and sensible and therefore it must be said that they were successful in completing the task.

VPA Results Discussed


The results show an expected path towards a design solution. The books that are reviewed here are based upon many years of research and experience, and for this reason you can see almost all of them being performed more or less from start to finish. The key differences seem to be in age. Experience is the integral factor to developing a design process. As fourth year students, the subjects showed professionalism and knowledge in how they went about designing for the problem. This is something that a first year would more than likely not show, as is proven in C. Atmans paper, showing the contrast in processes between the two. It seems that with age and experience comes the drive for research. It is important to understand the problem in detail before you go off trying to solve it, and this is something that a designer comes to realise with experience. A younger designer tends to want to throw themselves into the design side of the process and solve it as quick as they can so that they have the time to develop the idea and perfect it when it is maybe likely that they have missed something key in not researching properly. This key point would have likely been spotted by an experienced designer, and they would have designed around it.

Personality plays a very heavy role in team work too. This is something not mentioned in any of the books reviewed. To have a truly effective team, the ideal scenario would be for every member to know what each of the other members strengths and weaknesses are. If they know the persons personality and character then it is easier to understand where they are coming from and what they mean. A well known and established method for understanding these characteristics is the Myers Briggs Type Indicator. It is a psychometric test which establishes how a person sees the world and what their psychological preferences are (Wikipedia 2012). This test gives a very good depiction of the person and how they will work in a team. This allows other members to build around a persons traits and use them more effectively in the team. It could therefore be a good idea to take one of these tests before beginning a major project, so that the team is integrated and understands each other better than a team thrown together would normally. The VPA method itself does have some floors. The data recording process is highly subjective. The person analysing the recording has a guideline on what each category means, but the descriptions are somewhat open ended and what one person may consider as generating ideas, another may actually see it as modelling alternative solutions, and so on. This means that comparing results across different tests carried out in different places by different people may not be as accurate as it could be. There is also no defined category or thinking. Some designers will sit quietly for lengths of time analysing the problem and rationalising solutions before saying anything. In this test they would be recorded as inactive during this time which is not a true depiction of their activity. It is however still a very useful practice and can help to develop a designer, allowing them to see how they work in a team and allowing them in turn to improve upon this.

Conclusions
A design process for many is personal and particular; something developed over time and influenced, but not wholly led, by common practice. To have individuality in your work there needs to be some individuality in the way you work. If ever designer was to work to the same method you will see very similar, structured results. A graduate designer will work differently to a senior designer, and as a team leader it is important to show them how senior designers work and think as these are the ones with experience. They have developed to what is likely the perfect process for them and therefore, even if it is not your perfect process, it will still be something to learn from and develop upon. So, What design process will you use? The question is, do you need a set process? This paper has looked at various design processes and found that they are all fairly similar. To confine a team to one singular process is likely not to have an optimal outcome. If the process has to be a set published restricted method, to be adhered to fully, then it could be argued that you dont need a process. You need to adapt these methods into your own personal process. If a published procedure has to be chosen, the Product Design and Development process by K. Ulrich and S. Eppin seems to have the most rounded and relevant process. It allows for have some flexibility and freedom in the way a person works and this seems to suit a graduate designer far better than the more contrived processes like the System Design Process, which seems more likely to cause the young designer to lose some drive and interest in the project as they cannot get on with it the way they would wish to. As much as graduates do need direction, it is clear that they need space to develop their own personal design processes. It must fit around their own strengths and weaknesses and allow for the team to pick up where they may not perform as well as other members. How does this process compare with other processes you might have selected? The answer to this is becoming to come together already. Ulrich and Eppinger have developed a process that allows for flexibility and this is something not seen so much in the other books. As stated, the System Design Process does have a very modular restricted way of proceeding and maybe doesnt isnt tailored towards a young graduate, who is still developing and needs less restrictions on creative output and process. Both the Creating Breakthrough Products and the Inclusive Design books are too specific and again restrict creative output, this time my channelling it. The behaviours found in both of the books are worth passing on though, as they do encourage some valuable qualities in design, which could not only benefit the company monetarily and even reputably, but also benefit the wider population, especially through inclusivity. What behaviours are you going to encourage during the design activity and why? The main behaviour that stands out is iteration and evaluation. You must evaluate as fully as you can in order to fully understand what is being designed. C. Atmans paper shows this where the differing ages and experiences work differently. The older more experienced designers will research thoroughly and understand the problem. You will then see them constantly iterating and evaluating the design, checking it does suit the purpose it is there to serve. This is integral to design and has to be encouraged. Another behaviour that, as mentioned before, is very beneficial is designing for inclusivity. This equates simply to good design. If everyone can use the product, not

only does it reach a wider market, earning the company more money, but it also satisfies the needs of all users. This is almost the perfect design and that is surely what every designer would strive to create. Any graduate learning to design like this early in their career will go on to be a better designer in the future than they would have had they not been encouraged to use inclusive design.

References
Blanchard, BS., WJ. Fabrycky. 2006. Systems Engineering and Analysis, 4 edition, Upper Saddle River, New Jersey, USA: Prentice Hall. The Royal Academy of Engineering. 2007. Creating systems that work: Principles of engineering for 21st century. London, UK: The Royal Academy of Engineering. Ulrich, K., S. Eppinger. 2004. Product Design and Development. USA: McGraw-Hill. Cross, N. 2008. Engineering Design Methods: Strategies for Product Design, 4 edition. Chichester, UK: Wiley-Blackwell. Dym, C., P. Little. 2003. Engineering Design: A Project-Based Introduction, 2 edition. Australia: Wiley and Sons. Clarkson, PJ., R. Coleman, S. Keates, C. Lebbon. 2003. Inclusive Design: Design for the whole population. London, UK: Springer. Cagan, J., C. Vogel. 2002. Creating Breakthrough Products: Innovation from Product Planning to Program Approval. Upper Saddle River, New Jersey, USA: Financial Times Prentice Hall. Atman, C. 2005. Comparing freshman and senior engineering design processes: an in-depth follow-up study. Design Studies. 26(4), pp.325-357. WIKIPEDIA. 2012. Myers Briggs Type Indicator [online].[Accessed 9 November 2012]. Available from: http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
nd th th

You might also like