My Work


Over the course of 2 semesters of engineering design, inside or outside of my engineering design course, I can say I have been thoroughly introduced to the broad concept of design.

In my civil engineering course during first semester, it was detailed design, applying analysis techniques from structural engineering to iterate and create an effective design. In my second semester course, Praxis II, it was far more conceptual, and came down to details only in all the research and reading.

Along the way, it’s always been about balance. In my civil engineering course, I struggled to bridge (no pun intended) the massive distance between doing detailed calculation based analysis and trying to manage the very limited materials we had to work with to create the bridge. At this point, I learned about prototyping, and it never went away.

Indeed, the first time i found myself actually in NEED of prototyping was the project that had us build a beam from cardboard and glue. The challenge was to manage our finite amount of cardboard and see what was the size limit of the bridge we were going to build.

It was then that system 1 also found its way into my toolbox. It was solely my intuition that lead me to draw out a scaled version of the cardboard we had to work with, and sketch on it the scaled sizes of all the sections we would have to cut out. My group member used that to optimize our cutting and we were able to figure out how much more material we had to work with in various directions. This then fed back into our detailed design, we adjusted our dimensions for the bridge, and checked again the material we had. Then we locked in our dimensions and finalized our calculations.

The last half of this past semester in Praxis II was again about finding a complicated balance. My team was ambitious and aspirational, looking to great solution that was on a higher level than just a single device. It was a stimulating challenge to maintain a reasonable scope on our rapidly shrinking timescale, but also come up with something that we could feel satisfied with.

More thoughts and analyses on my learning over the course of my first year are around my website, primarily in the My Work section. Be sure to take a look!


My Strengths

Collections of events with photo-based evidence of my engineering design work:

The following is an explanation of all the strengths that I have listed in my About Me . This section expands and gives evidence for each of them. They also link back to my process in places.

Strength: Idea Development Through Documentation:

The most powerful tool I have for working through my design process by myself is to think things out using documentation. I write down all my ideas and use the written representation of my thoughts to organize myself, come up with ideas, and track myself. My design process works very well by doing it all in a document, as I can track all the concepts I have discarded, and the different iterations of documentation.

The following are some examples of me thinking out a task using documentation. These were all created in google docs so my group could also see my work.

Document: Designing a UI…

This is a document where i was looking into creating a digital user interface for the digital device we were going to create as a team. I never followed through because we shifted our design and this was no longer relevant.


As a team, we kept track of our progress at meetings through the use of meeting minutes. This is also a good example for the next strength in this list: ‘Document Based team collaboration.’ At each team meeting, we would all throw ideas into the meeting minutes for that meeting. It was helpful for us to write our thoughts and more complicated ideas, and was a good method to make progress even during remote (skype) team meetings.

My final example is just a reference to where I alone think out and execute a device selection. This is likely the strongest example of me developing ideas.


Strength: Document Based Team Collaboration:

Leveraging the collaborative power of Google Drive and Docs and related software, I am able to work with my team either in person or remotely on the same document, and collaborate through comments and suggested edits. As outlined in my process, my productivity is usually much higher when working alone, and this is still the case even when working in a document with other people. In this way, I have made myself extremely effective both in productivity and team collaboration.

The following images are examples of this in action within Google’s online collaboration software. The first 2 images are examples of myself and the other 3 members of my team all working at the same time on the same thing. All of us sharing our ideas to generate a quality product we all understand.

Inkedposter making methods of R14_LI.jpg

This is the poster we created for the final presentation of our project in our design course during second semester of my first year. The woman is for scale of what the printed poster will look like.

Inkedworking with the team_LI.jpg

This is the the requirements model myself and my team were creating for our RFP which was the first half of the design course in second semester. It is a different project from the one in the poster.


The following is a table I created in a document before the team meeting where we would decide these speaking roles. I did this to let my teammates think about who would say what before the meeting, and to set a groundwork to build on during the meeting. During the meeting we all looked at it and discussed it to change it into the second image:

speaker breakdown.JPG


Final result.


Strength: Articulating Ideas Through use of Visuals:

I enjoy using visual representations of information, whether it is for just myself, within my group, or for presenting a final product. I used this tool many times in the last semester of my first year. Here are a few examples:

For generating ideas:

Copy of File_001.jpeg

Myself acting out what it would be like to use a touchscreen mounted to the wall.



Here I was using sticky notes to keep track and arrange my ideas on a window.


For representing lots of information:


Here we are organizing information about the community we are investigating.

Copy of 0211_1.jpeg

This is a later representation, after we had found a lot more data. The person is Tiger Jian.


Copy of FINAL reqs chart ;).JPG

We used this visual presentation of our requirements model in a final document we submitted.

Strength: Organization of Information:

Organizing data is important when for being able to recall it quickly and easily. It also makes design processes go a lot smoother. It allows me to know what steps of my process I have completed or how many iterations I have gone though. It is very important to support the previously mentioned strength of ‘Idea development through documentation.’

Following from my outline of choosing a device, my use of the data table to hold the many details about the designs I was interested in demonstrates my ability to know how to deal with that amount of information.


In addition, here is a page of the final notes sheet I made for potential use in my final presentation. It was done very intentionally in this way, to hold all the key information from the data table but in a format that is far more easy to read. The ability to read it quickly was key during the presentation for either me or my assessors.

finaldata sheet capture.JPG

The final data sheet document here

Strength: Engaging with Stakeholders

The first component of my design course in second semester focused a lot on seeking out and engaging with stakeholders. I did just that and found I enjoyed it quite a bit.

Here are 2 examples of myself and my team doing that work:

This first one is the initiating email. It explains itself.

munizo email.JPG

This next image is of me engaging with a stakeholder as my team was about halfway towards submitting our final RFP on the stakeholders we had found. At this point I was interested in connecting and getting feedback on what we had to ensure that our methods of modeling their problem using engineering was working accurately.

ben message edited.jpg
Messaging a stakeholder

Strength: Strong and Clear Communicator:

When it comes to communicating with my team, I take initiative to be clear and to the point. I focus on getting information to them efficiently and in a way they can understand. I communicated with my team this semester using a group chat.

This first image is me offering information that I had uncovered for the benefit of my team. I shared the information as soon as i found it, with the intent of letting my team move as quickly as possible.

Inkedgroupchat pic 1_LI.jpg

This next one is me bringing up some potential issues for an upcoming mid-project presentation, called “Beta.”

groupchat pic 2.JPG

I also make a suggestion to my group mate. This spurs on his own ideas and he requests a skype call so we can discuss ideas before he met with a researcher tomorrow. That call in turn allowed him to gather a great deal of very important information from that researcher which heavily shaped the rest of the project.

This is why I make such an effort to communicate information with my team, it supports progress.

Choosing a Device: Evidence of My Process

My Process Performing some Selection Style Design

The following exemplifies one instance of myself doing design work and following my ‘Develop Requirements process’ (Or my DRP) . In this case, I was individually tasked to find some suitable touchscreen devices that can be used by dementia patients to interact with a software-based solution my design class team was developing. We had discussed and intentionally chose to have me do a selection style design, rather than pick a device. The main reason was time, since it was only going to be doing this selection and this was also only a small portion of a larger design project.

To start, I used the somewhat hastily constructed requirements my team had already created for the solution as a whole, (meaning for software and the physical device(s).

The first step was taking the high level objectives and ideas about detailed objectives and taking them down into concrete metrics that I could use in my search for a device.

I started with High Level objectives that had driven our design concept in general:


  1. Design a solution that will positively impact as many patients as possible.
  2. Design a versatile and accessible solution.
  3. Design for personalized/individualized care


As per Stage 1 in my DRP, I took these and reworked them to make sense for the selection of a physical digital device, but still maintained their “essence.” The result was the following:


Objectives of device

  1. Design a solution that will positively impact as many patients as possible.
  2. Design a versatile and accessible solution.
  3. Have a device that allows/facilitates individualized care to take place on it.


Next I took a step towards getting more concrete. At this point, the only requirements my team had already developed beyond these high level objectives were a collection of detailed objectives and thoughts on how those might be measured.

Here is one of these which I will show as a sample. For the rest of my process I will follow this sample through as a model of how I developed all the detailed objectives:


Detailed objectives → More concrete functions

C. Personalization of Stimulation → ability to distinguish individuals, staff time and energy


I took the ‘more concrete functions’ on the right that we as a team had previously created and ‘abstracted down,’ working towards getting concrete measurable metrics. This is now Stage 2 of my DRP, as I had to go conduct research and take preliminary looks at devices, or imagine tablets that I have used in the past and consider these devices used in a care home for dementia patients (as was per design project). I used knowledge that my team had gathered, and my own experience and imagination to conceptualize elderly people using technology, and how staff would have to help them.

I’d like to make a note on this way of thinking: in the phraseology of my design course, it was an exercise in balancing ‘system 1’ and ‘system 2.’ System 1 is a way of describing our gut feeling or emotional way of thinking, and system 2 is a label assigned to a more rigorous scientific way of thinking. I put these in balance by using my intuition and ‘feelings’ about what I thought about tablets and the elderly interacting with them. I also used the knowledge from all the research myself and my team had conducted at this point, including speaking with a researcher in the subject. This made it easy to come up with the need to track battery life and to be aware of the complexity of setting up the device. My analysis of ‘biometric sensors’ was much more system 2, simply pulling knowledge I had previously on the subject

The result of all this was the following:


Functions list that leads to…:
→ More concrete measures (metrics)

6. Staff time required per unit time of patient engagement

  1. Battery needs to charged by a staffer, ie plug/unplug?
    1. If staff takes 10min every 10 hours to plug in for charging.
      1. Longer battery life prefered
  2. Time to set up/make it ready for patients
    1. Complexity of set up
      1. Number of tasks that need to be done (by staff) to make it ready for patient use,
      2. Number tasks to put it away (ie, unplug, fold down, wheel away, return to case)

7. Ability to distinguish between individuals

  1. Biometrics sensors are one method
    1. Facial recognition
      1. Presence of a sufficent rez front facing camera
    2. Fingerprint reader
      1. Large, reliable enough for people with old age.
    3. Voice recognition ⇒ microphone presence!
      1. More detail than the existence of a microphone is too detailed


By now, I had taken the important objectives down to something very concrete, and I was ready to assemble metrics to measure these categories. This resembles stage 3 of my DRP, as I accept the changes I have been making and ready them for use.


Metrics List (DO => metric)

-Presence is a yes/no response

  • 6=>Battery life in hours (more is prefered)
  • 6=>Number of foreseeable steps to set up/ pack up device for a patient, which will be done on near daily basis (fewer = better)
  • 6=> number of plugs that need to be connected, i.e complexity of set up (less is better)
  • 7=>Presence of a microphone
  • 7=>Presence of a front facing camera
  • 7=> Presence fingerprint reader


I then reorganized these by category to ease the kind of data I would be looking for in my search of devices:


Metrics by category

  1. Sensors
    1. (These are other metrics not part of the sample I am following)
    2. 1=> presence of a gyroscope
    3. 7=>Presence of a microphone
    4. 7=>Presence of a front facing camera
    5. 7=> Presence fingerprint reader
  2. Physical components/accessories
    1. 6=>Number of foreseeable steps to set up/ pack up device for a patient, which will be done on near daily basis (fewer = better)
    2. 6=> number of plugs that need to be connected, i.e complexity of set up (less is better)


With this final representation in place, I had essentially completed Stage 4 of my DRP and was ready to proceed with selecting my device using my design process proper. This selection most takes place inside the ‘iterative design phase,’ and does not involve any team discussion or hard thought deliberation because I chosen to leave it as a simple, individual task. This type of selection design changes the meaning of the “pursue concept” bubble to really be “add concept to final list of designs” by the nature of this selection-style design.

To be able to easily compare the devices I uncovered in my search, I created a Data table (similar to a pugh chart) to track all the data for each metric I had for each design I was going to be looking into:


This is partial image of the table of metrics I created.


Note: row 6 has been blacked out:

This is because the metric in this row became obsolete as I realized every design I was considering had it, and it was therefore not helpful to have it there for comparison. It wasn’t deleted from my metrics list though, because it wasn’t completely obsolete, but it was not helpful to check in my search.

Note the ‘Midrange’ device and the far right column are missing values for many metrics:

After I filled in my first 2 designs that I had already decided to look at, which were the iPad Air 2 and the Senior tablet, I realized I was more looking for something that fit well into the chart without actually entering its values into the table and using the table to make comparisons.

Indeed, I found it was a lot faster to make some key decisions in my head about what would fit best with these metrics rather than forcing myself to fill out many fields in the table.

It allowed me to move a lot faster as I had to sift through large numbers of potential designs. There are lots of modern tablet devices out there. To ease my workload, I leveraged sites like Wire Cutter that offered to do comparisons of tablets for me. I would explore their different recommendations. I found it particularly helpful to use sites that claimed to be able to recommend the best tablet for seniors.

One final thing of note that occurred during this process is the following:

I made the upfront assumption that I would be picking just one case for each device I settled on. I planned on finding a case for my devices that optimized the ability for people with dementia to use it. This turned out to be an incredible challenge and threatened to take up a lot of my time. There were 3 problems:

  1. I struggled to find any official source that could tell me what size and shape of tablet case would be best for an elderly person.
  2. There were many many cases, and choosing the best one would require a whole other comparison table and breakdown.
  3. I was running out of time before delivery.

I decided to use my intuition ( engaging ‘system 1’), discussed with my team briefly and save some time.

I looked for 2 cases for every device, one that was made of toughness and one that would be easy to handle and hold. With no resource I could find in the short time frame, I looked at cases made for young children that were made of thick foam and featured a large handle. This was immediate to me as to what would help the most elderly people.

Since it was acceptable by my team, I saved time by adding the needed detail that the designs I had selected were only recommendations, and not concrete must-buys. Saving me the need to scientifically justify why I had chosen the one particular case over any others.

This was an extremely helpful thing to be able to recognize when I took a step back from my process and understood this small chunk of work in the context of the larger whole of the project. It demonstrates my ability to keep the bigger picture in mind when doing more detailed and specific work.

In conclusion, this task pushed me to proceed intelligently at all the steps in order to keep all results valid without exceeding the time and other limitations I had. Doing this process also allowed me to create a the well represented DRP that I have, and understand it’s place in design very well.


All the documents I have been referring to can be found at public links here, including the final data sheet version:


Engineering Science Education Conference – ESEC

An Extension on Lecture by Prof. Baher Abdulhai

On January 20th, 2017, Professor Baher Abdulhai gave a guest lecture entitled “Can Artificial Intelligence Win the Traffic Game?” The key concept presented: the means to manage traffic flow better.

There were 2 strategies the professor has been researching to optimize traffic flow.  One was to use an intelligent, self teaching, system. Hence the use of ‘Artificial intelligence’ in his lecture title.

The other approach, is the one I intend to focus on. It is the analysis of current traffic flow and congestion levels, used to control roadway tolls on expressways to match levels of traffic on the road. This would mean highest tolls at peak hours, and progressively lower tools as traffic becomes progressively less busy. This spreads the usage of the road by discouraging drivers from using it during peak hours, distributing that traffic volume to the road at other times.

Professor Abdulhai then talked about how this method impacts the time drivers choose to leave and where they choose to travel. He mentioned how it will cause people to change their schedules. In defense of this point Professor Abdulhai, stated that the options were to either expand infrastructure or improve what already exists. Unfortunately, there is very little space left to expand into in terms of Toronto and the Gardiner Expressway. His point: To optimize infrastructure so closely tied with the daily lives of people, we indeed must impact the daily lives of people.

I became curious: is the impact on people from this infrastructure optimization justified?  Is the cost to society, the financial cost to individual drivers, and the political controversy [1], outweighed by the benefits of reduced congestion?

I did some investigation to answer my query and I have found that its more complicated than a yes or no answer.

In an article on a report by a McMaster researcher Matthias Sweet, my question has been almost directly addressed. The article makes the key statement, “sometimes the cost of alleviating congestion is higher than the cost of the congestion itself. […] Until congestion reaches Sweet’s tipping point, it’s economically inefficient to spend resources trying to fix it” [2] The tipping point mentioned is a threshold of “about 35 to 37 hours of delay per commuter per year (or about four-and-a-half minutes per one-way trip, relative to free-flowing traffic).”

The findings of this study provide just the kind of insight I was trying to get at with my question; going beyond Professor Abdulhai’s innovations and essentially asking if we even should implement what he is proposing. What this study suggests to me about the situation on the Gardiner Expressway is that an investigation needs to be conducted to check if it is worthwhile to do what Professor Abdulhai suggests. This is all rooted in the need to address the subtle leap in logic made at the presentations debut, that congestion should be fixed. While counter intuitive, it’s a jump that could be erroneous, as this study suggests for certain cases.


  1. James Royerson, “”Wynne Listened To The ‘Vocal, Selfish, Short-Sighted’ In Blocking Toronto Road Tolls: James”.,” The Star, 2017. [Online]. [Accessed 9 02 2017].
  2. E. Badger, “CityLab,” Atlantic Media, 22 October 2013. [Online]. Available: [Accessed 19 Feburary 2017].


The PDF version of this here.

More about ESEC here.

More about the speakers at ESEC here.

More on the specific lecture  I discuss, found here.