9 Integrated Design Project

Integrated design project cycle

An integrated design project connects research, problem framing, concept development, prototyping, and evaluation into one learning cycle. The team does not necessarily complete each activity once and move on: evidence from evaluation may send it back to research, prompt a new concept, or lead to a changed prototype.

Frameworks such as Stanford d.school’s design-thinking modes and the Design Council’s Double Diamond can help organize the work. They are guides, not rigid, one-way recipes.

Frame the challenge

Start by agreeing on the intended outcome, the people affected, the project constraints, and what the team needs to learn. Turn assumptions into questions that can be investigated. Frame a challenge around a real user need while leaving room for different solutions.

For example, a campus team might ask, “How might we help students find and reserve a suitable study space?” Clarify the project scope, such as whether it covers finding a space alone or also booking and arrival. Note constraints such as time, budget, privacy, and accessibility.

Research user needs and context

Conduct User research into the current experience before settling on a solution. Choose methods that answer specific questions: interviews can reveal goals and frustrations, observation can show what people actually do, and existing records or service data can reveal recurring patterns. Include a range of affected people, including people who may face barriers, and consider staff or others who deliver or support the service.

For the study-space example, the team might observe students looking for rooms, interview students who study at different times, and talk with facilities staff. It might find that the main problem is not finding a room but knowing whether a listed room is actually available or accessible.

Turn evidence into a focused need

Synthesize evidence by grouping observations into themes and distinguishing what was observed from the team’s interpretation. Use the findings to identify important user needs and write a clear Problem statement. For example: “Students arriving between classes need a reliable way to find an available, accessible study space quickly.” A “How might we…” question can then open the challenge to multiple possible solutions without presuming one.

Generate and select concepts

Ideation means exploring several possible responses before committing to one. Individuals can sketch ideas first, then share, combine, and develop them together. Encourage varied concepts and defer early judgment. Afterward, compare ideas against user evidence, feasibility, accessibility, project constraints, and likely impact.

The study-space team might consider a live availability map, clearer signs, a room-status display, or a staffed help point. A Concept-selection matrix can make trade-offs visible, but a score does not replace discussion. Record why the team selected a concept and which assumptions still need testing.

Prototype the riskiest assumptions

A Prototype is a deliberately incomplete representation of an idea, made to learn something. Choose its form according to the question: a paper sketch can test layout and labels, a clickable screen sequence can test navigation, and a role-play or service walkthrough can test handoffs and timing. Build only enough detail to make the important interaction understandable. Early prototypes are usually quicker to change than finished products.

A paper map with sample room-status cards, for example, could test whether students understand availability labels before a team builds a digital map. Make clear to participants what is simulated. A polished appearance is not proof that the underlying service will work.

Make visual hierarchy serve the task

Visual hierarchy helps people notice what matters first and understand how information is organized. Use size, position, spacing, contrast, grouping, and consistent labels to distinguish primary actions from supporting details. In the study-space prototype, current availability might be more prominent than room amenities, while a clear label explains what “available” means.

Hierarchy must remain understandable to people who do not perceive color or layout in the same way. Do not communicate status through color alone; use text or symbols as well, and check text contrast. For web content, semantic headings should express the information structure rather than relying on visual styling alone.

Evaluate, learn, and iterate

Before a test, state what the team wants to learn and what evidence would change its decisions. Ask participants to attempt realistic tasks with the prototype. Observe where they hesitate, misunderstand, or fail, and invite them to explain their expectations. The purpose is to investigate the design, not to grade participants. Combine observed behavior with participant comments and relate findings to the original user needs.

For example, the team could ask students to find a quiet accessible room within a short time. If students mistake “reserved” for “available,” that is evidence to revise the labels or status system. After each round, decide what to keep, change, investigate further, or abandon. A revised prototype should address a finding or test a stated assumption rather than change arbitrarily. Update research plans and questions as the team learns.

Interpret test evidence carefully

Evaluation should consider both usability and outcomes. Possible measures include whether people complete the task, how long it takes, where errors occur, and whether the solution meets the identified need. A successful test with a small group can reveal problems and guide iteration, but it does not by itself establish how common a problem is across a wider population. Choose further research appropriate to that question.

Collaborate and carry the design forward

Integrated projects benefit from people with different expertise. Researchers help plan inquiry and interpret evidence; designers turn needs into concepts and prototypes; engineers assess technical feasibility; content specialists clarify instructions; and operations or domain experts reveal real-world constraints. Users and stakeholders contribute knowledge the team cannot supply from inside its own assumptions. Share findings and involve collaborators in making and evaluating prototypes so that decisions remain connected to evidence.

Before implementation or handoff, document the user need, research findings, chosen concept, prototype decisions, evaluation results, unresolved risks, and next steps. Continue evaluating the solution in context because users, conditions, and service needs may change after launch.