Introduction to the design process
My design process is grounded on experiences I have had working on various projects, both in teams and individually as a Student Engineer, and working with other teams in my workplaces and online. My model is adapted from elements of Clive Dym and David Brown's "Engineering Design: Representation and Reasoning", and NASA's BEST Engineering Design Process, which was adapted from the Museum of Science, Boston's five-step Engineering Design Process (Museum of Science, Boston, 2014). I've chosen to represent it as a hierarchical model similar to UTeachEngineer's Engineering Design Process, with distinct sections and sub-sections which are interconnected with each other (Guerra, Allen, Crawford, & Farmer, 2012).
Note that at each phase of the design process, I have indicated that we may chose to proceed back to a previous phase either because of new or modified understanding of the project, or to better satisfy the objectives of those we are designing for.
Phase 1: Analyze the Problem
Before we start finding a solution to a problem, it's crucial to know what the problem actually is. The Analysis phase is potentially the most critical, as if it is done incorrectly or without care then progress made in later phases might not be progress towards the actual goals of the design activity. The Analysis phase can be broken into 3 interconnected sub-tasks: Interact, Identify, and Explore. Click a sub-task below to read a detailed explanation.
Interact with Stakeholders
Stakeholders are anyone who has some interest in the design activity, or may be affected by and solutions. Generally, primary stakeholders will propose the design activity to the Engineer, or will be the first point of contact for the Engineer to understand the problem. Stakeholders are not only people: the environment in which the design process takes place is also crucial, and understanding how the solution fits in is a key first step.
For example, on my home page, I briefly mentioned my involvement making a server-side component of a web chat application. Prior to diving into the actual design and code, my first step was to understand the existing application and its users as much as possible. In the end, this allowed me to develop the API for interacting with the server in a way that was identical to how the application interacted with locally stored files, greatly simplifying the work that would have been needed to be done to implement it.
Develop the design requirements
Once we've talked with stakeholders and understood the environment of the design space, the next step is to identify what the challenge is that the design seeks to solve, and develop an explicit set of requirements or goals that must be met for the project to be successful. In NASA's BEST Design Process, they explain that the first step is to "clarify exactly what the problem is" (NASA, 2014). Once this is understood and written down (so it can be referred back to), we're ready to dive into the project!
Research and explore existing solutions
Finding the ideal soluiton to the problem is something I value, and is not possible without doing some amount of research. This may include looking for existing solutions that could satisfy the needs of your stakeholders, or doing research on how you yourself could develop a better solution.
For example, I was faced with the design challenge of making developing this design process. Since it has to fit in with this website, it was important to me that I find a good way of representing the key and detailed information. The idea came to me that I would use some kind of dialog box, but I knew it wouldn't be the best use of my time to code them from scratch. About a minute of searching brought me to the jQuery UI dialog method, which fit my original needs for this page (later on I decided this method was cumbersome for users, and as such I changed to the simpler current design of showing and hiding pieces as necessary).
Phase 2: Creativity and Exploration
Once I've got a sufficiently good understanding of the design space (note I say sufficiently, since it's almost always necessary to go back to analysis throughout the design process), it's time to start exploring possible solutions. In this phase, we generate as broad a solution set as we can that we think will satisfy the stakeholder's needs.
Often it is the case during initial brainstorming or prototyping of soluions that we find there isn't enough background information to keep going with a design without speculating as to the stakeholders' needs. In this case, we go back to Phase 1 to fill in the gaps in our understanding. Alternatively, we might have found a new piece of information we feel is relevant but didn't come up in the analysis phase. Again, we return back to the start to verify necessary information.
Phase 3: Iterate
In the iterate phase, we look at solutions generated and see how well they meet stakeholders' objectives. Many design models are cyclic at this stage, prompting the engineer to return to earler steps as necessary (Dym & Brown, 2012). In my model, I chose to work with multiple designs at once in this phase, combining the best elements of each to produce a candidate esign for the next phase, or one that can be iterated upon again. This is also the phase where I like to "cut down" some of the solutions from the previous phase, specifically those that don't meet stakeholders' requirements, or those which may simple not be as good as other potential solutions.
Again, we can take this page as an example. As discussed above, I had originally selected jQuery UI dialog boxes to display more detailed information. While this design worked well on desktop computers, it was ineffective on mobile devices. It also had the unintended side effect of increasing page load times to load the jQuery UI library. I decided that I still wanted to keep detailed information hidden away to keep the page clean, so I instead chose the slide toggle display method that is used above.
Phase 4: Execute
The final phase of my design process is to present a prototype to the stakeholders. I say prototype, because the whole process is often run multiple times: Notice that if the design doesn't completely satisfy the stakeholder, we can return back to Phase 1 to get a better understanding of what we may have missed, or back to Phases 2 and 3 to generate and improve upon more ideas. If the stakeholder isn't satisfied, it is important to me that I know why, so that I can take appropriate steps to remedy the situation from there. Once a solution that satisfies all stakeholders is found, we can then recommend and implement it.