What is Praxis?
The short answer: a course about forming your definition of what is good

Undoubtedly the most polarizing course in the foundational years of Engineering Science at UofT, many people either get it or think it's a waste of time. I dedicate this page to tips and examples on making the most out of what I considered the most defining course of the first two years.

Seriously, this is the course, and earning marks in this course is about both demonstrating your knowledge of quantifying quality, and applying it to your own work.

• Foster's sense of humour
• Competent teammates
• Requirement tables
• Google Scholar
• Documenting your work

1. Treat every project as a real life project rather than a school assignment
2. To help with point 1, put all your assignments onto your portfolio to pressure yourself to strive for quality
3. Have opinions and make decisions, but always justify them with reasoning and research
4. Consider tradeoffs - decisions are almost never optimal, but are often optimal in specific use cases
5. Iterate through drafts; don't try to perfect the first draft

You just had your first day of class in what seems to be an auditorium. The room is filled (mostly) with freshmen excited for their first time in a classroom with over 300 bodies. Everyone scrambles for the seats in the mid-front, and listens attentively with their blue engineering clipboard, freshly received from frosh, out and ready for notes.

Unfortunately, the scene I just described only lasts for the first handful of classes. Weekly CIV102 problem sets and quizzes can be demoralizing (don't worry too much about failing the first quiz), but I think the largest reason why Praxis' attendance drops so much is that people can't see its purpose.

It's the one course that actually asks you (directly or indirectly): why bother with this course? Compared to your other courses where knowledge is imperatively transcribed to you as if you're loading a computer program, Praxis will require you to write the program as you experience classes.

Think about the ways you do things. Some reasons must explain why you do things certain ways, such as how do you handwrite letters: do you strikethrough your 'z' and '0'? Describing the reasons in terms of a measurable quantity - a metric - is an essential skill Praxis encourages you to develop.

This midterm is a timed essay about the design decisions embodied by a consumer product (the artifact). The exact question changes from year to year, but the preparation should be:

• Consider what objectives the designers were aiming for
• Create metrics for each of those objectives
• Measure the metrics for the artifact and similar products (make a table)
• Find the artifact's key features that accomplish those objectives

If you've prepared the list above, you will comfortably achieve 90%+ regardless of your language capabilities and what this year's exact question is.

For an example, see my online writeup on the hand mixer, which is basically a transcription of my essay. (you can refer to figures that you bring)

The first part of Product Design is to come up with a problem simple enough that engineering students can solve. This should be some kind of daily annoyance that is mechanical in nature - attempting anything electrical will result in failure...

This assignment requires an initial amount of thought to come up with a good question, but afterwards it is just research justifying the significance of the problem.

I recommend keeping the question of "how can our lives be slightly improved" in the back of your mind to discover problems when you least expect it in life. After this assignment, it'll become a habit and help you as a problem solver for the rest of your life.

This is the Praxis I part that requires the most thinking, and arguably the most fun part. Out of the design briefs teams present, a few will be selected based on appropriateness and the quality of the pitch for the rest to tackle. Do not assume you'll solve the problem your team presented!

The key to this part is to fully analyze the cause of the problem and consider who would be interested in solutions (stakeholders). This includes the people affected by it, potential producers of the solution, companies that profit from the problem, and so on. Mechanical problems are much easier to analyze than electrical ones for most first years, so be sure you can fully explain the cause of any problem you think of. Analysis is detective work involving steps of simulation, actual testing, surveys, and deduction - use any tool you can think of to explore why the problem exists.

Try to decompose the problem into as many independent subproblems as possible and come up with good solutions for those subproblems. This should be much easier than solving a complicated problem since you do not have to worry as much about tradeoffs. The subsolutions do not have to be optimal, since when you finally combine them together, an optimal combination can be composed from suboptimal parts.

Be sure to document your entire design process, which makes it much easier to defend your design during the design critique at the end.

For an example, see my team's conceptual design in solving binder misalignment.

This is a spin-off of the conceptual design above and you'll be recommending a design decision for another group's conceptual design. The other group will only give you a rough objective and some safety metrics to follow, and the thinking for this part will be in thinking up of additional metrics that would be appropriate for their product.

Much like what I recommended above for conceptual design in analyzing the cause of the problem, you have "delve deep" into their problem and find out what objectives and metrics would help solve their problem. You can push back on the requirements given to you if you can justify better ones.

For an example, see my material selection for an aerator to prevent hot water splashing.

This was the design portfolio for 1T7, but adjusted to "RoPE" for 1T8. Document your entire Praxis experience to make this part much easier than it was for some people. If you have an eidetic memory or a good work habit, this is simply organizing your reflection on engineering design into a user-friendly form.

In this case you're the designer of the presentation format, and you should consider your objectives and audience.

A pretty standard multi-part essay-style final exam. It will test 2 things:

1. You can justify a design decision when given candidate solutions and metrics
2. You developed your own sense of what's good in the form of objectives and metrics

Prepare while building your portfolio/RoPE.

This is a slower verison of Praxis I that culminates in a high fidelity (close to actual product) prototype which can sometimes go into the hatchery program and spawn startups.

Classes lack some of the wow-factor present in Praxis I, but are still informative and entertaining. Many periods are given to you to work with your group on the design - it is very easy to waste them!

Similar to the Design Brief of Praxis I, the pitch is where students come up with "problems". However, this is more important than the Design Brief because it also decides your team. There is a voting system where everyone must order each other person in their studio in order of team preference. It is crucial to make a good impression on your classmates if you haven't done so already!

Another difference is that you are pitching a community rather than a minor annoyance.

Consider the community's size, identification with each other, living condition, ease of contact and collaboration (more important than you might think), and neediness.

You've formed your team, now you need to choose the community to tackle. This does not have to be one your team pitched, but choosing so would give you a head start on research.

Engage directly with the community as soon as possible and scope out potential problems. Start by listing their daily activities and objects they interact with in order by the amount of time per day spent.

Once you have your problem, now you need to consider what objectives and metrics a good solution would match. I highly recommend creating a requirements table rather than an unorganized list.

In terms of marks, choosing a good problem decides about 30%, presenting the community about 10%, and the requirements decide 50% (presentation and others make up the rest). Designing relevant requirements and researching constraints will be the best use of time.

Pay attention to how your TA responds when you describe your problem in studio. A good one will make them excited and they'll tell you it's good. If you're lucky, your TA is honest and will tell you if it's bad.

For an example, see my team's RFP on the discomfort of wearing headsets and glasses for police communication officers.

After your group submits its RFP, hope for the best but prepare for it not being selected. A high mark does not guarentee its selection (honestly it's bizarre how they select RFPs; some terrible ones get through).

At this point, starting early and pacing is important to developing a high fidelity prototype on time, as there is no on-paper deliverable that forces you to structure the process. I would still recommend that you create a conceptual design report and detailed design reports as they really can help you make good decisions.

The rest depends on teamwork, commitment, and level of engagement with community. Several prototypes will have to be made, in increasing fidelity. Put all you've learned in Praxis into the final prototype, don't neglect polish, and get a good night's sleep before showcase.

For an example, see my team's design for meat refrigeration without electricity.