My Process

Main Process:

A visual representation of the process I’ve developed for myself

The central, linear processes:

  • Team brainstorm:
    • This is where we get together as a team and come up with ideas for solutions in a variety of ways. Brainstorm broadly refers to the generation of ideas. This may also be called “creativity.” It can be done using techniques like ‘SCAMPER’[1] or ‘6-3-5 Brainwriting.’ [2]
  • Check against requirements 1 & 2
    • This is where we narrow the set of ideas created in ‘Team brainstorm.’ Techniques I use include a Pugh chart [3] or a pairwise comparison chart [4]. From this, we can choose to take the best concept or the best set of concepts and work with them going forward.
    • This is a more strenuous assessment of the concept against requirements, and aims to get information about what in the design could be improved, or if there is a fatal flaw that will tell us it must be discarded.  
  • Sanity check:
    • Kind of self descriptive, this is the point in my design process where time investment in the design becomes significant and the damage of pursuing a poor concept becomes very large. At this point it’s a good idea to balance the risk of the current concept, and consider if requirements need to be reworked before the amount of work to do becomes very large. Up to the sanity check, only a small portion of the overall time in the project has been invested.
  • Initial discussion or analysis with team
    • After a concept has made it, we meet as a team to come up with a plan for investigating each one further. This includes breaking up the work, a plan of action for each concept and considering what kind of testing should be done for each concept.
  • Investigation: Research, prototyping and testing
    • This is box is perhaps the most abbreviated part of the process. It includes research, building prototypes of the concept and assessing them against the requirements.
  • Further analysis with team & Disregard concept vs. Pursue concept
    • At this point, the team decides if we are going to keep going with the concept, based on its performance against the requirements.

The loops and side boxes:

  • Develop Requirements Process
    • This section has been pushed to the side, as sometimes requirements models already exist as complete, and in other cases they need to be created potentially from scratch. The box represents that requirements are created as the process proceeds and new ways to assess the designs may be needed.
  • New information uncovered
    • Often in both the design courses I have taken so far, I have observed that in the midst of an investigation into one concept, myself or a member of my team will have an idea or come across some bit of information that inspires them with a new idea. In the interest of making the most of all the ideas we come up with, I have represented in my model how we should hold onto that idea and give it the same treatment as ideas, hence why it cycles back to the top of the diagram.
  • Iterative Design Process
    • This is a loop referring the common technique of iterative design. The loop loosely describes how a design should keep being tested and improved until it is deemed suitable for the final product. It is highlighted in green because it is a key loop the process of improving designs.

General Comments:

  • Why team vs individual work?
    • To build on my personal strength of doing my best work alone. The flipping between teamwork and individual work is meant to send team members away from meetings with work to do, and bring them to the next meeting with results. I do my best work by myself, and like to focus only on team work when I am with my team.  However, individual blocks are not meant to be done in isolations from the rest of the team. Collaboration may still take place, just not an explicit team meeting. So like talking in a group chat.  
      1. The key individual work block is Research prototyping and testing. This activity of ‘investigation’ fits in well with what I can do effectively alone.
  • The original process behind this:
    • This process is based on Frame-Diverge-Converge-Represent (FDCR) taught in my design course. It is also empirical, meaning that it represents what I have observed myself and my team do in the 2 design courses over first year. So this process is basically how I understand and implement FDCR with the amount of experience I currently have.

Develop Requirements Process:

A visual representation of the other component of my process

Context on what this part is:

This section is a representation of another aspect of design which I have also conducted a lot of work on. I have chosen to represent it as a separate process because it may or may not be needed before moving into the process proper.

The Develop Requirements Process  is launched only if there are perceptions in me or my team’s perspective that the current problem definition, objectives, requirements, or other aspects are sufficiently lacking and have the ability to be improved significantly by my team.  

These feelings will arise if there is a problem in the way the original design task modeled or captured the reality of the situation where it is located. This can be better explained  using the following diagram, which comes from the first lecture of my first design course. The diagram itself is a high level representation of how engineering design works. The first step, circled in red, is where the real world is modeled in some way. The design process proper that I have also represented is within the “Theory” category.

design process explanation.jpg
From my first design course: ESC101, Lecture 1

Going into the develop requirements section is a somewhat subjective decision, and, as shown in the design process proper,  it could be launched into at any point in the design. This said, it would become more risky to start modifying the problem as more detailed work continues to be done, and more iterations are taken towards the final design.

This was partially the case in my second design course, and we balanced it by using an abbreviated, quick version of the Develop Requirements Process to change the problem as we developed and changed the solution. This kind of circular changing of the the problem and the solution at the same time must be very carefully done, in order to preserve the ‘essence’ or intent of the design; any key features that make the problem what it actually is. Without this check, me more my team may find themselves designing things that no longer have the desired effect.

Elements of interest:

  • Identifying the Essence of the design task:
    • This simply means that me or my team must very explicitly understand what in the original given task we would like to keep. This is mostly an analysis of the problem presented, and the essence is likely to be some of the provided high level objectives, stakeholders, and constraints. After this point, all elements in the original task except for these are open for push-back.
  • Need to make more changes
    • This is the iterative element of this design process, and the loop can go back to which ever step is most appropriate.

Stages 1-4:

This process has been heavily based on the Frame – Diverge – Converge – Represent model of engineering design that was taught to me in my design courses.

The stages are as follows:

  1. Frame:
    1. This is where the issues we have with the original design task requirements become well outlined, and made ready to address.
  2. Diverge:
    1. Now alternatives or improvements are developed for the problem areas.
  3. Converge:
    1. From the total collection of possible changes, the best few are selected. In the case, the means of selection is based on how much the changes will support the design proper as it begins.
  4. Represent:
    1. In this stage, the changes are put into the design task. A final assessment can then be made about how well this new design task will allow myself or my team to create a good solution in the design process proper.  This assessment partially occurs within the design process proper, as it is during the use of the requirements that it will be most clear if they are sufficient.



  1. Mind Tools, “MindTools,” MindTools, [Online]. Available: [Accessed 26 February 2017].
  2. O. P. C. O. A. V. M. Marcela Litcanua, “Brain-Writing Vs. Brainstorming Case Study For Power Engineering Education,” Elsevier Ltd, Amsterdam, 2014
  3. D. S. Burge, “Burge Hughes Walsh,” 2009. [Online]. Available: [Accessed 26 Februrary 2017].
  4. P. P. Filippo A. Salustri, “Pairwise Comparison,” Ryerson Univeristy, 27 12 2005. [Online]. Available: