Introduction to Engineering & Design

Engineering is the practice of using scientific knowledge, mathematics, and creativity to design solutions to real problems under real limits. A useful one-line definition is that engineering is design under constraint. A scientist asks "how does the world work?" An engineer asks "given how the world works, what can I build that people need, and how do I build it within my budget, schedule, and safety limits?"

Science versus engineering

The two fields are partners, not rivals. Science discovers and explains; its output is reliable knowledge. Engineering applies that knowledge to create useful artifacts and systems; its output is a working product, structure, process, or device. A physicist explains why a beam bends; a civil engineer uses that explanation to size a bridge girder so it will not bend too much under traffic. Engineers also routinely work at the edges of what science has fully explained, using tested rules, safety factors, and experience to move forward anyway.

Constraints are the heart of the job

What makes a solution an engineering solution is that it must satisfy many competing demands at once. Common constraints include:

• Cost - materials, manufacturing, and lifetime operating expense.
• Time - the schedule and deadline for delivery.
• Safety - it must not harm users, workers, or the public.
• Performance - it has to actually do the job well enough.
• Manufacturability - it can be built with available tools and skills.
• Sustainability and regulation - environmental impact and the law.

Because these pull in different directions, engineering is fundamentally about trade-offs. A lighter material may cost more. A stronger part may be heavier. A faster schedule may raise risk. Good engineers make these trade-offs deliberately and can explain why they chose one balance over another.

A worked way of thinking

Suppose you are asked to design a water bottle. A scientist might study how plastics behave at different temperatures. As an engineer, you would weigh cost against durability, choose a material that is food-safe and recyclable, make sure the shape can be molded in a factory, keep the weight low enough to carry comfortably, and price it so people will actually buy it. No single answer is "correct"; there is a space of good designs, and your job is to find one and justify it. That shift - from a single right answer to a defensible best choice among many - is the core of the engineering mindset.

Engineering is a wide family of related fields. Most branch from a handful of classic disciplines. Knowing roughly what each one does helps you find your interests and understand who does what on a real project.

The classic branches

Discipline	Focuses on	Example project
Civil	Buildings, bridges, roads, water systems	A highway overpass
Mechanical	Machines, engines, moving parts, heat	A car transmission
Electrical	Circuits, power, signals, electronics	A phone's power system
Chemical	Reactions, materials, processes at scale	A water-treatment plant
Computer / Software	Hardware logic and programs	An operating system
Aerospace	Aircraft and spacecraft	A satellite
Biomedical	Health and medical devices	A prosthetic limb
Industrial	Systems, efficiency, and workflows	A factory assembly line
Environmental	Pollution control and sustainability	An air-quality system

Newer and cross-cutting fields

Many modern specialties combine classic branches: mechatronics blends mechanical and electrical and software; materials engineering designs the substances products are made from; robotics pulls from mechanical, electrical, computer, and control fields. The boundaries are useful labels, not walls.

Real projects are interdisciplinary

Consider an electric car. A mechanical engineer designs the chassis and suspension; an electrical engineer designs the battery and motor drive; a chemical or materials engineer improves the battery cells; a software engineer writes the control code; an industrial engineer plans the factory that builds it; and a civil engineer may design the charging-station foundations. No single discipline can deliver a modern product alone. That is why teamwork, covered later in this course, is a core engineering skill and not an optional extra. When you choose a major, you are choosing a primary lens, not a cage - engineers move across boundaries constantly throughout their careers.

Engineers do not just start building. They follow a design process, a repeatable sequence of steps that turns a fuzzy need into a working, tested solution. Many versions exist, but almost all share the same backbone. A common seven-stage version is:

1. Define the problem - understand the real need and who has it.
2. Gather information and requirements - research and write down what a solution must do.
3. Brainstorm ideas - generate many possible concepts.
4. Select a concept - compare ideas against the requirements and choose.
5. Model and develop - sketch, calculate, and design the chosen concept.
6. Build a prototype - make a testable version.
7. Test and evaluate - see if it meets the requirements, then improve.

It is a loop, not a line

The single most important idea is that the design process is iterative. You rarely go straight through once. Testing usually reveals a flaw, sending you back to redesign, rebuild, and retest. Each trip around the loop is an iteration, and each one makes the design better. Failing a test is not a disaster; it is information. Engineers often say they "fail fast" on cheap early prototypes so that the final product succeeds.

The diagram below shows the cycle, with the arrow from Test looping back to earlier stages.

The rest of this module walks through the stages in more detail. Keep the loop in mind: every stage feeds the next, and every test can send you back to make the design better.

The most common cause of a failed project is solving the wrong problem. Great engineering starts by defining the problem carefully, before any building begins. A strong problem statement says who has the problem, what the need is, and why it matters, without yet naming a solution.

Needs versus solutions

Beginners often jump to a solution and hide it inside the problem. "We need an app" is a solution in disguise. The underlying need might be "commuters cannot tell when the next bus will arrive." Stating the need, not the solution, keeps your options open. A good format is: "[User] needs a way to [do something] because [reason]." For example: "Elderly residents need a way to open medication bottles easily because current caps are too stiff for arthritic hands."

From needs to requirements

A requirement is a specific, testable statement of what the solution must do or be. Requirements come in two kinds:

• Functional requirements - what it must do. "The cap must open with no more than 10 newtons of force."
• Constraints - limits it must respect. "It must cost under 2 dollars to make" or "it must be child-resistant."

The gold standard is that every requirement is measurable, so you can later test whether you met it. Compare these:

Weak (vague)	Strong (measurable)
The bottle should be light.	The bottle must weigh under 150 grams when empty.
It should be easy to open.	It must open with 10 N of force or less.
It should be cheap.	It must cost under 2 dollars per unit to manufacture.

Distinguishing three things

Keep these separate in your mind: a need is the human problem; a requirement is a measurable target the solution must hit; and a solution is a specific design you might build. Many different solutions can satisfy the same set of requirements, which is exactly why you write requirements first and brainstorm solutions second. Well-written requirements become your scoreboard: at the end you test the product against each one and can say, precisely, whether you succeeded.

Once you know the requirements, it is time to generate ideas. Brainstorming is the deliberate creation of many possible concepts before judging any of them. The biggest beginner mistake is settling on the first idea. Research and practice both show that quantity leads to quality: the more concepts you generate, the more likely a great one is among them.

Rules that make brainstorming work

• Defer judgment. Separate generating ideas from evaluating them. Criticism early kills good ideas before they grow.
• Go for quantity. Aim for many ideas, even silly ones. Wild ideas often spark practical ones.
• Build on others' ideas. Combine and extend; "yes, and" beats "no, but."
• Stay focused on the problem. Keep the requirements visible so ideas stay relevant.

Sketching ideas as you go, and writing each on its own card or sticky note, helps a team see and combine them.

Choosing a concept objectively

After generating many ideas, you must choose. Doing this by gut feeling invites bias, so engineers use a decision matrix (also called a Pugh chart). You list the important criteria from your requirements, give each a weight for how much it matters, score each concept on every criterion, then multiply and add to get a total.

Here is a worked decision matrix for choosing a bottle-cap concept. Scores are 1 (poor) to 5 (excellent).

Criterion	Weight	Concept A	Concept B
Easy to open	5	4	3
Low cost	3	2	5
Child-resistant	4	5	2
Weighted total		46	38

Concept A total: (5 x 4) + (3 x 2) + (4 x 5) = 20 + 6 + 20 = 46. Concept B total: (5 x 3) + (3 x 5) + (4 x 2) = 15 + 15 + 8 = 38. Concept A wins, and the matrix shows exactly why: it scores well on the two highest-weighted criteria, ease of opening and child resistance. The matrix does not make the decision for you, but it makes your reasoning visible and honest, which is invaluable when you must justify a choice to a team or a client.

A chosen concept lives only in your head until you make it visible and testable. Engineers do this with sketches, models, and prototypes, moving from cheap-and-rough to detailed-and-real as confidence grows.

Sketching and modeling

A sketch is a quick drawing that captures an idea's shape and key features. It does not need to be pretty; it needs to be clear. Adding notes, dimensions, and arrows turns a doodle into a communication tool a whole team can discuss. As the design firms up, engineers create more precise models. A model is any representation of the design used to study or predict its behavior. Three common kinds are:

• Physical models - a scaled or full-size object you can hold and test, such as a foam mock-up or a 3D-printed part.
• Mathematical models - equations that predict behavior, such as a formula for how far a beam will bend under load.
• Computer models - CAD drawings and simulations that let you test a design virtually before building it.

Prototyping

A prototype is a working, testable version of the design. Early prototypes are often "low-fidelity" - cardboard, tape, and glue - built to answer one question cheaply, like "does this shape fit the hand?" Later prototypes are "high-fidelity," closer to the real materials and function. The rule is to spend the least effort needed to learn the next important thing.

Designing a fair test

Testing is how you learn whether the design meets its requirements. A good test is a fair test: you change one thing at a time and hold everything else constant, so you know what caused any difference. A test should also connect directly to a measurable requirement. If the requirement is "opens with 10 N or less," the test is to measure the actual opening force with a spring scale and compare. Record the result, decide pass or fail, and if it fails, use what you learned to iterate. Tests that are vague ("it felt fine") teach you little; tests tied to numbers ("required 8 N, under the 10 N limit, so it passes") drive real improvement. This closes the design loop and sends you, better informed, back toward a finished product.

A number without a unit is usually meaningless in engineering. "The beam is 5 long" tells you nothing; "5 meters" tells you everything. A unit is the agreed standard amount a measurement is counted in. Getting units right is not busywork - a famous spacecraft was lost because one team used metric units and another used imperial units. Careful unit handling is a mark of a professional.

The SI system

Engineers worldwide use the SI system (the International System of Units). Its base units include the meter (m) for length, kilogram (kg) for mass, second (s) for time, ampere (A) for electric current, and kelvin (K) for temperature. Other units are built from these; for example, the unit of force, the newton (N), equals 1 kg·m/s².

SI uses prefixes to scale units by powers of ten, which saves writing long numbers:

Prefix	Symbol	Multiplier
kilo	k	1,000
centi	c	0.01
milli	m	0.001
mega	M	1,000,000

So 1 kilometer is 1,000 meters, and 1 millimeter is 0.001 meters.

Converting units with conversion factors

The safe way to convert units is to multiply by a conversion factor, a fraction equal to 1 that has the unit you want on top and the unit you have on the bottom. Because the fraction equals 1, it changes the units without changing the actual quantity. The trick is to arrange it so the unwanted unit cancels.

Worked example. Convert 5 kilometers to meters. Use the fact that 1 km = 1000 m.

5 km × (1000 m / 1 km) = 5000 m. The "km" on top and bottom cancel, leaving meters.

Worked example with two steps. A car travels 90 kilometers per hour. What is that in meters per second? Convert kilometers to meters, then hours to seconds:

90 km/h × (1000 m / 1 km) × (1 h / 3600 s)

Multiply the numbers: 90 × 1000 / 3600 = 90000 / 3600 = 25. So 90 km/h = 25 m/s. Notice how "km" and "h" both cancel, leaving m/s, which is a strong sign the setup was right. Always let the units guide you: if the leftover units are not what you wanted, your factors are arranged wrong.

Beyond converting units, engineers use dimensional analysis to check whether an equation even makes sense. Every physical quantity has a dimension, an abstract description of its nature, independent of the unit chosen. The main mechanical dimensions are length [L], mass [M], and time [T]. For example, area has dimension [L]² whether you measure it in square meters or square feet, and speed has dimension [L]/[T], that is length per time.

The principle of dimensional homogeneity

A correct physical equation must be dimensionally consistent: both sides must have the same dimensions, and you can only add or subtract quantities that share dimensions. You would never add a length to a time, just as you would not add meters to seconds. This single rule catches a surprising number of mistakes.

Worked example: checking a formula

Consider the equation for distance traveled under constant acceleration: d = ½ a t², where d is distance, a is acceleration, and t is time. Let us check its dimensions.

• Left side, distance d, has dimension [L].
• Acceleration a has dimension [L]/[T]² (speed per time).
• Time squared, t², has dimension [T]².
• Right side: [L]/[T]² × [T]² = [L]. The [T]² cancels.

Both sides come out to [L], so the equation is dimensionally consistent. The factor of one-half has no dimensions and does not affect the check. Dimensional analysis cannot confirm those dimensionless numbers are correct, but it will immediately expose a formula that is fundamentally wrong.

Catching an error

Suppose a student wrote d = ½ a t by mistake, dropping the square. The right side would be [L]/[T]² × [T] = [L]/[T], which is a speed, not a distance. The two sides do not match, so the equation must be wrong - and you caught it without plugging in a single number. Professional engineers run this check habitually, because it is far cheaper to catch an error in the algebra than after building the wrong thing.

Engineers constantly make fast approximate calculations called estimates. Before spending hours on an exact answer, a good engineer asks "roughly, what should the answer be?" This guards against blunders: if your careful calculation says a car weighs 20 kilograms, your estimate instantly tells you something is wrong.

Order-of-magnitude thinking

An order-of-magnitude estimate aims to get the answer right to the nearest power of ten - is it about 10, 100, or 1000? You round every number to something easy, multiply, and accept that the result is approximate. Problems solved this way are sometimes called Fermi problems, after the physicist known for them. The skill is breaking a big unknown into smaller things you can guess.

Worked example. Estimate how many liters of water a person drinks in a year. Guess about 2 liters per day. There are about 365 days, which we round to 400 for easy math. Then 2 × 400 = 800 liters, so roughly 800 liters per year. The true figure is near 700, so our estimate landed in the right ballpark, which is exactly the goal.

Estimates as a safety net

Always compare an exact result against a quick estimate. If they disagree wildly, one of them is wrong, and it is usually worth finding out which before proceeding. This habit has saved countless projects from expensive mistakes.

Significant figures: honesty in numbers

Significant figures are the digits in a number that carry real meaning. If you measure a length with a ruler marked in millimeters, reporting "3.14159 meters" is dishonest - your ruler cannot know that many digits. You should report only as many digits as your measurement supports, perhaps "3.142 meters." A simple guideline: when you multiply or divide, the answer should have no more significant figures than the least-precise input. Reporting too many digits fakes a precision you do not have; reporting too few throws away information you earned. Estimation and significant figures together keep engineers honest about how much they really know.

Every physical product is made of something, and choosing that something is one of an engineer's most consequential decisions. Materials are grouped into families that share broad behaviors.

The four main families

• Metals (steel, aluminum, copper). Generally strong, stiff, and able to bend without breaking, and they conduct heat and electricity well. Used for structures, tools, and wiring. Downsides include weight and, for many, corrosion.
• Polymers (plastics, rubber). Lightweight, cheap, easy to shape, and often corrosion-proof, but usually weaker and less heat-tolerant than metals. Used for packaging, housings, and countless everyday goods.
• Ceramics (glass, brick, porcelain). Very hard, stiff, and heat-resistant, and they resist wear and chemicals. But they are brittle, meaning they crack rather than bend. Used for tiles, cutting tools, and high-temperature parts.
• Composites (fiberglass, carbon fiber). Made by combining two materials to get the best of both, such as strong fibers held in a light polymer. Used where a high strength-to-weight ratio matters, as in aircraft and sports gear.

There is no single best material

Each family shines in different situations, so "which material is best?" always depends on the job. A bridge cable needs the tensile strength of steel. A drink bottle needs the low cost and light weight of a polymer. An oven door window needs the heat resistance of a ceramic glass. A racing bicycle frame needs the strength-to-weight ratio of carbon-fiber composite. The engineer's task is to match the material's properties to the requirements, while weighing cost, weight, availability, and how the part will be manufactured. The next lesson defines the specific properties that make these matches possible.

To choose materials wisely, engineers describe them with measurable mechanical properties. The two most fundamental ideas are stress and strain.

Stress and strain

Stress is the internal force spread over an area, defined as force divided by area: stress = F / A. Its SI unit is the pascal (Pa), equal to one newton per square meter. Stress tells you how hard the material inside a part is being pushed or pulled, regardless of the part's overall size. Strain is how much the material stretches relative to its original length: strain = change in length / original length. Strain is a ratio, so it has no units.

Worked example. A steel rod with a cross-sectional area of 0.0004 m² (that is 4 square centimeters) carries a pulling force of 8000 N. The stress is 8000 N / 0.0004 m² = 20,000,000 Pa, or 20 megapascals (MPa). Because stress uses area, a thicker rod under the same force would experience less stress, which is exactly why load-bearing parts are made thicker.

Three properties people often confuse

• Strength is the maximum stress a material can take before it fails. High strength resists breaking.
• Stiffness is how much a material resists being stretched or bent; a stiff material barely deforms under load. It is measured by the material's elastic modulus.
• Ductility is how much a material can deform permanently before it breaks. Ductile materials (like copper) can be drawn into wire; brittle ones cannot.

A material can be strong but not stiff, or stiff but brittle. Rubber is flexible (not stiff) yet can be quite tough; glass is stiff yet brittle. These are independent ideas.

Elastic versus plastic

When a small load stretches a material and it springs back to its original shape after the load is removed, the behavior is elastic. Push past a certain point, the yield point, and the material stays permanently deformed even after unloading; this is plastic behavior. Engineers usually design parts to stay in the elastic region under normal loads, so they return to shape and do not slowly bend out of true. Understanding where elastic behavior ends and plastic behavior begins is central to designing parts that last.

Statics is the branch of engineering mechanics that studies forces on objects that are not accelerating - objects at rest or moving steadily. It is the foundation for designing anything that must hold still under load, from a shelf bracket to a skyscraper.

Force is a vector

A force is a push or a pull, measured in newtons (N). A force is a vector, meaning it has both a magnitude (how strong) and a direction (which way). We draw a force as an arrow: the arrow's length shows the magnitude and the way it points shows the direction. This is why "10 N" is incomplete for a force; you must also say which way it acts.

Common forces to look for

• Weight - the pull of gravity, always straight down, equal to mass times gravity (W = m g, with g about 9.8 m/s²).
• Normal force - the support a surface pushes back with, perpendicular to the surface.
• Tension - the pull carried by a rope, cable, or chain, along its length.
• Friction - a force resisting sliding, along the surface.
• Applied force - any push or pull you deliberately add.

The free-body diagram

The single most useful tool in statics is the free-body diagram (FBD). You isolate one object, draw it as a simple dot or box, and draw every force acting on it as an arrow pointing in the correct direction. You leave out everything else. A clear FBD turns a confusing physical situation into a solvable problem. The diagram below is the FBD of a box resting on a table: gravity pulls it down with weight W, and the table pushes up with normal force N.

Because the box sits still, these two forces must balance exactly. That balancing idea is the key to solving statics problems, and it is the subject of the next lesson. For now, practice spotting every force on an object and drawing it as an arrow in the right direction. A correct free-body diagram is more than half the work.

An object that is not accelerating is in equilibrium. For forces along a straight line, the condition is beautifully simple: the forces must balance, so the total force in any direction is zero. In symbols, the sum of the forces equals zero, often written as ΣF = 0 (the Greek letter sigma means "sum of"). This is the first step of Newton's laws applied to structures, and it lets us solve for unknown forces.

Setting up a force balance

Pick a direction as positive (say, up), then add every force with a plus sign if it points that way and a minus sign if it points the opposite way. Set the total to zero and solve. Working along one line at a time keeps things manageable.

Worked example: the box on the table

A box with a mass of 10 kg rests on a table. Find the normal force the table exerts. First find the weight: W = m g = 10 kg × 9.8 m/s² = 98 N, pointing down. Two vertical forces act: the normal force N (up) and the weight W (down). Taking up as positive, equilibrium requires:

N - W = 0, so N = W = 98 N.

The table pushes up with 98 N, exactly balancing the box's weight. This matches the free-body diagram from the previous lesson: the up and down arrows are equal in length because the object sits still.

Worked example: two people lifting

Two people lift a 300 N crate straight up by its handles, and it rises at a steady speed (so it is still in equilibrium). One person pulls up with 180 N. What force does the other provide? Taking up as positive, the two upward pulls must together cancel the 300 N weight:

F₁ + F₂ - 300 = 0. With F₁ = 180: 180 + F₂ - 300 = 0, so F₂ = 120 N.

The second person must pull with 120 N. Notice the two lifting forces (180 + 120 = 300 N) exactly match the weight, as equilibrium demands.

Reading the result

Always interpret your answer. A force balance does more than produce a number; it tells you how hard a support, cable, or person must work. If a computed cable tension exceeds the cable's strength, you have just discovered, on paper, that the design would fail - and you can fix it before anyone is at risk. That is the quiet power of statics: it lets engineers guarantee that things will stay standing.

Engineering is a profession, and professions carry responsibilities to the public, not just to employers. Because the things engineers build can hurt people when they fail, ethics and safety are core skills, as important as any calculation.

The engineer's first duty

Professional engineering codes of ethics around the world agree on one central principle: engineers must hold paramount the safety, health, and welfare of the public. "Paramount" means it comes first, above profit, above the schedule, and above the wishes of a boss or client. If a design is unsafe, the engineer's duty is to say so and to refuse to certify it, even under pressure. This principle exists because history includes tragedies - collapsed structures, failed vehicles - that careful, honest engineering could have prevented.

Common ethical dilemmas

Real dilemmas are rarely cartoonish. They look like:

• Being pressured to cut a safety margin to meet a deadline or budget.
• Discovering a defect after a product has shipped and deciding whether to disclose it.
• Facing a conflict of interest, where personal gain competes with honest judgment.
• Being asked to work outside your area of competence without saying so.

A useful approach is to be honest about facts and uncertainty, to consider who could be harmed, to follow the profession's codes, and to be willing to raise concerns even when it is uncomfortable. Engineers are also expected to be truthful in their claims and to give credit fairly.

Designing for safety and managing risk

Risk combines how likely a failure is with how bad its consequences would be. Engineers reduce risk in layered ways: using a safety factor so parts are stronger than the expected load; adding redundancy so a backup takes over if one part fails; designing fail-safe behavior so that if something breaks it fails into a safe state (an elevator's brakes grip when power is lost); and testing thoroughly before release. Safety is not a feature added at the end; it is designed in from the first requirement. Taking ethics and safety seriously is what earns engineering the public's trust.

Almost no real engineering is done alone. Projects are too large and too interdisciplinary for one person, so the ability to work in a team and to manage a project is as valuable as technical skill. Employers consistently rank communication and teamwork among the abilities they most want in engineers.

Why teams, and what makes them work

Teams bring together different disciplines and viewpoints, which produces better designs than any individual could alone - but only if the team functions well. Effective engineering teams tend to share a few habits:

• Clear roles. Everyone knows who is responsible for what, so nothing falls through the cracks.
• Good communication. Members share progress, problems, and decisions early and clearly, in writing when it matters.
• Respect and psychological safety. People feel free to raise concerns and admit mistakes, which is exactly when problems get caught.
• Shared goals. The whole team aims at the same requirements and deadline.

Planning with project-management tools

Project management is the practice of planning, organizing, and tracking work so a project finishes on time and on budget. A few simple tools do most of the work:

• A task list that breaks the project into concrete tasks, each with an owner and a due date.
• Milestones, key checkpoints marking major progress, such as "prototype complete."
• A Gantt chart, a bar chart along a timeline showing when each task happens and which tasks overlap.
• Awareness of dependencies, where one task cannot start until another finishes, so you order work sensibly.

Here is a tiny task plan for a class design project:

Task	Owner	Due
Write requirements	Sam	Week 1
Brainstorm & pick concept	Whole team	Week 2
Build prototype	Lee	Week 4
Test & report	Priya	Week 5

Notice the dependencies: you cannot build the prototype (Week 4) until the concept is chosen (Week 2). Good planning respects that order. With clear roles, honest communication, and a simple plan, a team turns the design process from this course into a finished project - which is exactly what engineering, in the end, is all about. Congratulations on completing the course.