My Education in Engineering Design

A little about me,

My name is Eric van Velzen. I am currently completing my first year of engineering at the university of Toronto. My specific engineering program is titled Engineering Science and will take me through 2 general years of study before I specialize into a stream.


I’m from Calgary, Alberta, where I grew up and began to discover what the world had to offer. I was a speed skater for 5 years, a sport which is as intense as it is technical, requiring skill blended with strength. Speed skating would not work without the equipment we use, either, which has been carefully designed to allow us to go faster. Over my years of training, I improved mentally, physically, and learned to tune my gear to it’s very best. This is how I learned to go fast. I discovered that the balance between strength, knowledge and design is entirely necessary to achieve the speeds desired. I feel this balance is required in many more things in life. Much of the work I do as an engineer is no exception.

And About myself as a Student Engineer:

Engineering continues to attract me because of the three elements engineering brings together: the diverse studies of math and science that I love; putting the studies to use in real world applications, solving the kinds of problems I want to solve; and constructing my own designs, where I am involved and ‘getting my hands dirty.’Engineering Identity-Following from this are my future aspirations in my engineering design career:

My current area of interest is aerospace, and I plan to pursue that as my discipline of choice after second year. I like this field because of the current advances being made by companies like SpaceX, which strikes me as extremely meaningful and important. Further to this, I am interested in being a part of the development of such leading edge technology.

In or outside of aerospace, I also aim to have a strong role in team projects engaging in engineering design. As a result, developing my teamwork abilities is something I would really like to do. Even better would be to develop my skills in a team working on an engineering design project, which allows me to practice and improve on the engineering I really enjoy.

My strengths and weaknesses in with respect to the above are as follows:

On a high level, my key strengths follow from my strength in writing and documentation:

Generally: My work and processes are heavily documented and well written out, making them easy to go back to for reference or recovery of an old or discarded idea. In combination, I am comfortable using document sharing platforms like google docs that allow me to fully document all my progress, and also make that fully available to my team members so they can also leverage all the documentation.


  • Document based team collaboration
  • Idea development through documentation
  • Articulating ideas through use of visuals:
  • Organization of information
  • Engaging with stakeholders
  • I am also an articulate communicator.

Find out more about my strengths on my website here!

My weaknesses primarily follow from being limited to only one year of engineering education:

  • My interest in working with leading edge technology is severely limited by having only complete first year in engineering, and having very little relevant technical expertise gained from high school.
  • Limited experience working on design projects that take place over a long duration (more than about 3 months).
  • Also limited experience working in design groups of more than 3 other people.

My weaknesses will all be improved with more experience in engineering jobs, which makes me eager to take up engineering design work where I can find it.

Taking these strengths and weaknesses into account, I have developed the following process that is partially a reflection of what I have done, and partially aspirational in what I would like to become: See My Process below. 

For more detail on the things I have done, check out My Work, especially this post about my process in action.


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: