Welcome to Last Minute Lecture.
This free chapter overview is designed to help students review and understand key concepts.
These summaries supplement not replaced the original textbook and may not be redistributed or resold.
For complete coverage, always consult the official text.
Welcome back to The Deep Dive.
Today we are finally moving beyond those abstract requirements and into the, well, the dirt under the fingernails reality of interaction design.
We have answered the who and the what.
Now it's about the how.
How do we take a conceptual idea and turn it into something users can actually hold or touch or interact with?
That's right.
We're focused squarely on the develop phase of the design process.
So you can think of this deep dive as a map really showing how you get from those initial, often pretty vague requirements all the way to a finished product.
And the secret weapon here isn't the final code.
No, not at all.
It's repeated cycle of design evaluation and then redesign.
That loop is the engine of the whole thing.
And the sources break this whole process down into two really essential and intertwined design categories.
Let's start with the conceptual side.
Absolutely.
So first you have conceptual design.
This is the philosophy.
It's the big idea.
It defines what the product will do, how it's going to be represented to the user, and the core concepts they need to understand how to interact with it.
The conceptual model.
The conceptual model.
It's the skeleton basically.
Okay.
And once we have that skeleton, we need the muscles and the skin, which brings us to the second category.
That's concrete design.
And this is all the granular detail, the visual appearance, what the icons look like, the menu layout, the typography, even the haptic feedback.
But they feed each other, right?
You need some concrete ideas to start prototyping.
But the prototyping itself helps you refine that conceptual model.
Exactly.
It's a feedback loop.
So if the conceptual model is the skeleton, then the prototype is, what, the laboratory where we test if the skeleton can walk.
That's a great way to put it.
At its most basic, a prototype is just a manifestation of a design.
It lets everyone involved, designers, users, stakeholders, interact with the idea and see if it works.
But the key insight here is that every prototype is also a filter.
A filter.
It is always limited.
It has to focus on certain things while, you know, intentionally ignoring or minimizing others.
And we have one of the most famous and maybe most bizarre examples of this in design history, Jeff Hawken with the palm pellet.
He didn't start with code.
He started with a chunk of wood.
Yes.
It's such a powerful story.
He literally carved a block of wood to the exact size and shape he imagined for the device.
And he carried that wooden lump around for weeks.
Pretending to use it.
Pretending to use it.
Pulling it out of his pocket, tapping on it to enter appointments.
The prototype filtered out all the technical complexity to focus purely on the physical experience, the size, the feel.
It was genius.
And today we've got tools like 3D printing that can do that almost instantly.
Right.
But fundamentally, why go through all this effort to filter?
Well, Donald Shone called it reflection in design.
Building prototypes forces you to think.
They're communication devices.
Wow.
And they answer very specific design questions.
Like, is this technically feasible?
Or how do we clarify this really vague requirement from a client?
Or most importantly, how do users actually react when you put it in front of them?
And the question you're asking really determines the prototype's fidelity.
We can look at that paper prototype designed for an autistic child.
That example shows perfect filtration.
It was just paper, markers, cardboard.
It visually showed the layout, the labels, the interaction sequence.
So it was just enough to test the function and the flow.
Right.
But it completely filtered out things like speed or sound quality or how robust it was.
You didn't need to test those things yet.
And we should also mention that a service prototype, say for a new airport check -in, often just uses role playing.
The people themselves are the prototype.
Okay.
That distinction brings us neatly to the rapid, cheap techniques.
Low -fidelity prototyping.
These are your early disposable drafts.
Simple, super quick to modify and just vital for exploring ideas fast.
We have four core techniques here.
First, storyboarding.
Right.
So storyboarding takes a scenario like that one of Christina using a mobile device to explore historical sites and turns it into sketches.
Yeah.
Step by step, showing her progress.
It captures the whole context of use.
Exactly.
Second is just plain old sketching.
And the source material is very clear on this.
This is about design, not about how well you can draw.
They mentioned developing a sketching vocabulary.
Yeah.
Simple boxes, arrows, stick figures.
It's about getting over that inhibition and just focusing on the idea, not making it pretty.
Okay.
Third technique,
index cards.
Simple three by five cards.
Each card represents a screen or an icon or a dialogue box.
You literally put them in front of a user and have them step through a task and you swap out the cards like they're navigating the interface.
And finally, the famous,
maybe slightly sneaky, Wizard of Oz technique.
Ah, yes.
So the user thinks they're interacting with a fully automated system, like an AI assistant.
But behind the scenes, there's a human pulling the levers, simulating the system's responses.
And this is used a lot in human robot interaction.
A ton.
And in studying autonomous vehicles too, it lets you understand how people will react to an AI before you've actually built the really complex AI.
Okay.
So moving up the scale of reality, we get to high fidelity prototyping.
Right.
These look much closer to the final product.
They often have more functionality and they usually evolve through different stages, getting more polished each time.
And they're more resource intensive, but sometimes you need them.
You do.
For instance, designers created fully working smartphone apps as hi -fi prototypes for an assembly line worker assistance system.
They needed that high fidelity to test usability in a real noisy time crunched factory.
A paper prototype just wouldn't cut it.
But every prototype higher lo -fi is a compromise.
The sources give us this sort of formal anatomy of prototyping.
They do.
The filtering dimensions are what you leave out.
Appearance, data, functionality, and interactivity.
And then the manifestation dimensions describe its physical form, material, resolution, and scope.
And this forces trade -offs, like horizontal versus vertical prototyping.
Exactly.
Horizontal means you show wide range of functions, but with very little detail, like a basic site map.
Vertical is the opposite.
You show deep functionality for just one or two key tasks, like a fully working payment system and nothing else.
And this all leads directly to something called the prototyping dilemma.
What happens when a high fidelity prototype is just too good?
It creates two huge risks.
First, the user might mistake it for the final product.
And then their feedback is all about the color of a button instead of a fundamental flaw in the concept.
And the second risk.
The design team gets lazy.
They might be tempted to just ship the prototype without doing the proper engineering or documentation, which is almost always a disaster.
So we have to distinguish between two approaches here.
Right.
Evolutionary prototyping, where the prototype is built well from the start and is meant to evolve into the final product.
And throwaway prototyping, where the prototypes are just for learning.
They're stepping stones that you discard before you start building the real thing.
Okay.
Let's switch gears back to that core idea.
Conceptual design.
Before we even draw a screen, how do we start generating that big idea?
You start by achieving empathy.
You have to immerse yourself in the user's world.
Things like contextual interviews are key, but you can also use mood boards.
Like for interior design.
Exactly like that.
A collection of images, textures, typography, just to capture the desired feel or emotion of the product for the design team.
Scenarios can explore the ethical side of that feel.
The text introduces plus and minus scenarios.
The dietmon example is perfect for this.
Researchers made video scenarios about a diet tracking product.
The plus scenario showed a guy happily showing the tech to his friends.
And the minus scenario.
It showed him tense, sneaking a pastry and throwing it away after the system warned him about his calorie intake.
It instantly shows you that the product isn't just a tool.
It's a potential source of guilt and social pressure.
And speaking of simulating experience, what about experience prototyping?
Like having designers wear the third age suit to simulate what it's like to be older.
Well, these are intended to generate insights, but the source material is really cautious about them.
Research shows these disability simulations often just generate pity or fear, not real empathy.
Because they ignore the coping strategies people develop.
Precisely.
They ignore the lived experience.
The consensus is that deep, genuine involvement with the actual users is a much more ethical and, frankly, more insightful way to go.
So once we have that empathy, we can start building the model.
And the first approach is through interface metaphors.
This is all about combining something the user already knows with the new system.
Tom Erickson laid out a three -step process.
Understand the system, figure out where users will struggle, and then generate metaphors to bridge that gap.
Let's use the group travel organizer example.
One metaphor they tried was the family restaurant.
A restaurant metaphor seems good at first.
You have menus, tables, you choose items, but it breaks down pretty quickly.
How so?
Well, it doesn't really map to things like remote participants.
And the payment process for a group trip is way more complicated than splitting a restaurant bill.
So the alternative was the travel consultant metaphor.
Right.
And this one appeals to users who want an expert system to do the hard work for them.
It gives the system a kind of authority.
Evaluating these metaphors early on forces you to make critical decisions before you've drawn a single screen.
Next up, we have the interaction types instructing, conversing, manipulating, and so on.
And a product rarely uses just one.
That travel organizer might use instructing for simple things like visa info, but then switch to a conversing style when you're trying to figure out a complex vacation package.
And the third piece of this is considering different interface types, shareable, tangible, virtual reality.
This is so important.
It helps designers avoid the default temptation to just design for a standard desktop interface.
We mentioned this with the index cards.
Right.
The risk of only thinking in terms of a wimp interface.
Wimpy, for anyone who needs a refresher, is windows, icons, menus, and pointer, the classic desktop metaphor.
Okay.
So once the core model is chosen, you expand it.
This involves task allocation.
Which is just deciding what the system does automatically and what the user has to do.
Does the travel app book the flight for you or does it always need your final confirmation?
That has huge implications.
You also map out function relationships and the data you need, often in early wireframes.
And with that, the conceptual blueprint is solid.
Now we can finally move to concrete design.
Yes.
And the focus shifts entirely to the visual aesthetics, the icons, the layout.
Two big considerations dominate this phase.
First,
accessibility and inclusiveness.
So accessibility is about making it usable by as many people as possible.
And inclusiveness is about making it fair and equal.
And the key here is flexibility.
Your interface has to work with different input and output modes, like screen readers or eye tracking.
And the source is pretty blunt here.
If your interface isn't accessible, it can lead to actual discrimination.
What's an example of that?
Think about a blind user who can't use an airline's website.
They're forced to call a booking center.
If that call center charges a higher fare than the website, that user is being penalized just because the interface wasn't built for them.
Okay.
And the second key consideration.
Designing for different cultures.
This is about language, sure, but also colors, symbols, metaphors.
You have to recognize this tension between universal design principles and the need to respect local and indigenous perspectives.
Now let's see how those ideas get turned into actual testable artifacts.
We go back to prototypes.
Generated directly from those requirements.
A scenario for the travel organizer, for instance, gets broken down into a storyboard.
And the real value isn't the final drawing.
It's the questions that the act of drawing forces you to ask.
Like what?
Like, how will the remote family member participate?
Are the others sitting around a table or standing up?
These simple logistical questions suddenly expose unresolved design issues.
And a use case like checking visa requirements can translate directly into card -based prototypes.
And in that visa example, this was critical.
When the team mocked it up on index cards, they realized their design was way too focused on that classic wimpy interface.
The cards helped them see they needed a totally different metaphor, maybe something map -based to make it simpler.
We should also mention experience maps or customer journey maps.
These are great visualization tools.
They track a user's entire path through an experience, not just the digital steps.
The source defines two main types.
The wheel representation.
Which you use when a whole phase, like waiting for a flight, is more important than a single interaction.
And the timeline, which is more linear, for something with a clear beginning and end, like buying a product.
Before we hit construction, we have to talk about participatory design, or PD.
Yes.
This came out of Scandinavian labor movements.
It's about genuine,
active participation of users throughout the entire design process.
It's more than just asking for feedback.
It's mutual learning.
And the big challenge today is scale.
It's scale.
How do you do PD for a whole city?
The deaf telephony case study in South Africa is a great example of community co -design.
It shows that when you're designing for highly disadvantaged users, you need long -term reciprocal involvement.
You can't just drop in for a few interviews.
Okay.
This holistic approach gets us to the final stage.
Construction.
The design is solid.
And now we assemble the final product.
And you rarely build from scratch anymore.
Right.
Our new sources here fall into two main categories.
First, physical computing kits.
This is about building physical things and giving them behaviors with code and electronics.
The sources highlight a few key kits, like Arduino.
Arduino was developed specifically so artists and designers could build and code physical prototypes really quickly, using a simple board and software.
And then you have more specialized kits, like LilyPad for eTextiles.
Or the BDC micro dot bit, which has built -in sensors and is great for teaching graphical programming.
But the most fun example has to be Matty McKee.
It's just ingenious.
It's a kit that uses alligator clips to turn almost any non -insulating object, the banana, a glass of water, whatever, into a computer key.
So you can play a piano on a bunch of bananas.
You absolutely can.
And the text notes how retired people used it to foster creative thinking, which is a perfect illustration of the whole maker movement, this DIY culture that's exploded thanks to low -cost tools and online sharing.
And the second category of construction resources is software development kits, or SDKs.
An SDK is a whole package of tools and documentation for a specific platform, like iOS or Android.
But there's a distinction here that people often confuse.
An SDK gives you the entire workshop, the tools, the instructions, the building blocks.
Whereas an API.
An API, or Application Programming Interface, is just the technical connection.
It's the channel that lets one pre -existing piece of software talk to another.
A perfect example is the Connect SDK.
Exactly.
It made this incredibly powerful gesture and depth recognition technology accessible to everyone for everything from elderly care to robot control.
So that completes the journey.
We've gone from the big idea in conceptual design to the visual details of concrete design, refined it all through iterative prototyping with low and hi -fi techniques, and finally moved into construction with physical kits and SDKs.
That's the whole map right there.
So what does this entire spectrum of activities tell us about the philosophy of design?
The chapter mentions the controversy around design thinking, which often gets boiled down to a simple five -stage process.
Empathize, define, ideate, prototype, test.
That linear process.
Given the deep focus on empathy, on metaphor, and the necessity of discarding prototypes that we've covered today, what boundary exists, in your opinion, between just following that prescribed linear process and engaging in the genuine messy iterative design that allows for true surprise and meaningful learning from your users?
Something to mull over as you begin applying these tools yourself.
Thank you for joining us for this deep dive into design, prototyping, and construction.
We will see you next time.