Chapter 13: Interaction Design in Practice

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replace the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome to the deep dive.

So if you've ever studied interaction design theory, you know it paints this really idealized picture of solving user problems.

A perfect world where you have all the time and resources you need.

Exactly, but then that theory just crashes head on into commercial reality.

And by reality we're talking about restricted time, limited resources, and just the relentless speed of software development today.

And everything changes.

It becomes less about that pristine theory and more about survival.

There's a great quote from

that a good designer's skills work like expanding foam.

I love that image.

Yeah, it's this idea that you're constantly adapting, finding new ways to inject quality into these really high pressure situations.

Okay, so that's our mission for this deep dive.

We're going to explore how interaction design actually works in that commercial pressure cooker.

And we're going to do that by looking at the key structures that practitioners who, you know, we mostly call user experience designers or UX designers these days, what they rely on to get the job done.

And you've broken these support systems down into four

main pillars for us.

That's right.

So first we have Ajay UX, which is all about adapting to those rapid software cycles.

Okay.

Second is design patterns, basically reusing successful design blueprints so you're not reinventing the wheel.

Makes sense.

Third, open source resources.

Think of these as free reusable code components and huge libraries.

Then finally, of course, the tools themselves, everything from prototyping software to development environments.

All right, let's start right where that pressure begins with the organizational reality.

It's easy to imagine a designer starting with a blank canvas.

Yeah, but that's almost never the case.

In reality, you're often dealing with inherited problems and specifically something we call debt.

Not financial debt.

No, no.

This idea comes from a term coined back in the 90s by Ward Cunningham, technical debt.

Okay.

So what's that?

It's basically the long -term cost you pay for making a quick, short -term technical compromise.

You save time now, but you create complexity that's going to cost you way more to fix later.

And UX debt is the design version of that.

Exactly.

It's created through those little functional trade -offs you make for expediency.

And if you don't go back and refactor that design meaning, clean it up and streamline it, the cost to fix it later can become massive.

And the source material points to two big situations that pretty much guarantee you'll build up a lot of this costly UX debt.

The first one is just simple organizational history.

You see this a lot with internal systems or maybe legacy products where, frankly, the company never really cared about good UX.

Okay, because they didn't have to.

There was no market competition forcing their hand.

Precisely.

And the other situation is really common in big companies.

Product proliferation.

An organization grows.

Maybe it acquires other companies.

Right.

And suddenly you've got this huge portfolio of products that were all developed independently.

And it's just a sprawling, confusing mess of different designs.

That makes it so clear why designers can't just work in a bubble.

You need these really adaptive, fast support systems.

Which takes us straight into our first pillar,

Agile UX.

Okay.

So Agile software development really shook things up for the design world.

It completely reshaped it.

I mean, Agile focuses on iteration and user involvement, which sounds a lot like UX design.

It does.

But actually merging the two disciplines requires some serious reorganization.

Yeah.

And that's where Agile UX comes from.

The core conflict seems pretty huge.

You have the traditional plan -driven waterfall model, which needs all the requirements locked down up front.

And then you have Agile, which is all about specifying requirements just in time or just enough.

And you might re -prioritize everything every two weeks.

That must require a huge mindset shift for designers.

It's a critical one.

For a UX designer, there are beautiful design artifacts.

Those polished wireframes, the detailed sketches.

Ah, that careful work.

It now has to be seen as consumable.

It's a disposable document that has to evolve super rapidly because the only thing that really matters is the final working product.

Let's use the group travel organizer example to see this in practice.

Say the product has four big goals or epics.

Right.

So epic one is choosing a vacation.

Epic two, arranging visas.

Three is checking vaccinations and four is supporting the travel agent.

You can't do them all at once.

And you shouldn't waste time designing things that might get cut.

Exactly.

Agile forces you to be ruthless.

So the main goal, choosing a vacation and the features that let the travel agent keep the data clean, those get prioritized.

And the other stuff like managing visas or vaccinations.

They might get postponed,

or if they don't deliver enough business value, once the core product is up and running, they just get dropped completely.

It sounds efficient, but the sources say integrating Agile and UX still have its struggles.

There are three dimensions of understanding needed.

Yeah, De Silva and his colleagues pointed this out.

Process and practice is mostly understood.

People and social, that's nearly there.

But technology and artifacts still needs a lot of work.

Why is that third one such a stumbling block?

I think it's where the rubber meets the road.

Designers think in sketches and abstract concepts.

Developers need concrete, codified artifacts.

They need code libraries, style guides,

CSS.

So the handoff is tricky.

It can feel like you're just throwing ideas over a wall instead of sharing a coherent implementable thing.

UX has to be seen as a discipline, a mindset, not just a role that makes documents.

Which brings up a really core tension.

How do you do proper user research when your time boxes, your sprints, are only two weeks long?

You can't run a full ethnographic study in a fortnight.

Right.

It's a huge challenge.

And there are basically two main organizational solutions.

The first is called iteration zero or cycle zero.

Okay.

What's that?

It's a dedicated period before the iterative development starts.

You use that time for all the necessary upfront research and to lay down the basic software architecture.

But getting a cycle zero must be a tough sell.

You're asking the business to delay the start of coding.

It is a tough sell.

Absolutely.

Which is why the alternative is to set up ongoing programs of user research.

So it's continuous.

Exactly.

Imagine a big company like Microsoft running a permanent user recruitment program.

They're constantly refining their understanding of users over a long time span.

Totally independent of any single two week sprint.

Now there's an even faster approach called lean UX.

Oh yeah.

This is an innovative, really lightning fast approach built right on top of agile.

The engine behind it is the build, measure, learn loop.

And the key idea is shifting focus from outputs to outcomes.

Precisely.

So you're not focused on just finishing an app.

That's the output.

You're focused on achieving a measurable increase in commercial activity.

That's the outcome.

And you test your ideas with a minimum viable product or MVP.

Which is the smallest, fastest thing you can possibly launch to test your core assumption.

The example in the book is great.

A company wants a monthly newsletter, but instead of building the whole thing.

Right.

Which could take months.

They just spent half a day building a simple signup form.

That form was the MVP.

Yes.

They collect signups.

They confirm there's an appetite for it.

And then they use that data to learn what the newsletter should actually be.

It's the fastest way to see if an idea has legs.

This speed brings us to another key practice.

Aligning the work itself.

The old idea of big design upfront, designing everything in detail before coding,

just doesn't work with agile.

It's totally incompatible.

The solution that works is the parallel tracks approach.

So how does that work?

It means the UX design work is always done exactly one iteration ahead of development.

You're doing the design and research for cycle N plus one while the developers are building cycle N.

That sounds like an intense juggling act for the UX designer.

It's described as a three -part rhythm.

It is.

In any given cycle, you are basically looking backward, inward, and forward all at the same time.

So what are those three things?

One, you're evaluating the implementation from the previous cycle.

Two, you're producing the detailed designs for the next cycle.

And three, you're answering quick questions from developers about the design they're implementing in the current cycle.

Wow.

That sounds exhausting.

Is creative burnout a real risk there?

It can be, but the alias team, for example, found huge advantages.

It's very efficient.

You can combine activities like doing usability testing and a contextual inquiry on the same customer visit.

And you get feedback faster.

That's the most important part.

Design time isn't wasted on features that get dropped because you find out quickly if something isn't working or isn't a priority.

This all leads to a couple of big organizational dilemmas.

First, to co -locate or not, where do you actually put your designers?

Right.

Do you put them with the Agile team for tight communication?

Or do you keep them in a separate group for discipline coherence to protect their creativity from all the noise of software construction?

And the second dilemma is more philosophical.

Quick, quick, slow.

Yeah.

The relentless speed of Agile is great for momentum, but good, deep, reflective design takes time.

And this is where the idea of slow design comes in.

What's that about?

It's about designing products that are sustainable and long -lived.

It really emphasizes the need to take time to reflect and think, not just rush every decision.

It's a balancing act.

That balance also seems to dictate how you handle documentation.

UX designers traditionally live by their detailed sketches and wireframes.

Yes, that was their main deliverable.

But Agile pushes for minimal documentation.

It prefers collaboration over paperwork.

So how do you know how much is enough?

You have to ask yourself some practical questions, like Radcliffe and McNeil suggested.

How much time are you spending on it?

Who is actually going to use it?

What's the absolute minimum the customer needs to see?

And the visual example in the chapter really drives this home.

You have the lo -fi user journey, just sticky notes and string made by the whole team in maybe an hour.

Compared to the high fidelity, super polished user journey that took a designer hours and hours.

Time that could have been spent designing the actual product.

Exactly.

The goal is efficiency and shared understanding, not a pretty document.

Right.

Let's move on to our second pillar.

How designers can leverage past successes, starting with design patterns.

So a design pattern is basically a solution to a problem in a context.

It captures design experience.

So it describes the problem, the solution, and crucially, why that solution has worked before.

Yes.

And they're what we call generative, which means you can instantiate them or apply them in many different ways.

And this idea didn't even start in software, right?

No, it comes from an architect, Christopher Alexander.

He was trying to capture that quality without a name you find in great architecture.

In UX, when patterns link together, they can form a pattern language, but mostly what you see are pattern collections.

And the big advantage is that users are often already familiar with them.

Exactly.

It's a shortcut to usability.

Let's talk through a classic mobile pattern, Swiss Army Knife Navigation.

This is a perfect example.

The problem is obvious.

You have very little screen space on a phone and you want to keep the user focused on the content.

So what's the solution?

The off canvas or side drawer navigation.

It's that menu that slides in from the side when you tap an icon and then slides back out of view.

It saves a ton of real estate.

But you're saying patterns aren't forever.

They can evolve or become deprecated.

Right.

And there's one that's particularly controversial,

the carousel.

Oh, the horizontal slider.

People have strong opinions on that one.

They really do.

The usability data often shows that users only ever look at the first image, maybe the second.

So why do people still use it?

Because it's just so good at saving screen space.

So the lesson is don't just blindly reuse a pattern.

You have to measure if it's actually working in your specific context.

And then there are patterns that are actively bad for UX, like anti -patterns.

Right.

These are just examples of poor practice.

A classic one is just shrinking a big desktop website down to a phone screen without redesigning it.

And suddenly you have a phone number and a pop -up that's impossible to tap.

And then we get to the really insidious ones, dark patterns.

Yes.

These aren't necessarily poor design from a technical standpoint.

They're designs that are deliberately used to trick people.

Prioritizing the company's value over the user's value.

Exactly.

Gray and his colleagues identified five strategies, like nagging, obstruction, sneaking.

Let's take one of those interface interference.

What's a real -world example of that?

Interface interference is when you manipulate the interface to make the thing the user wants to do really hard and the thing the business wants them to do really easy.

Like trying to cancel a subscription.

The classic example.

The cancel button is tiny, gray, and buried five clicks deep, while the upgrade now button is huge, green, and right in your face.

It's designed to make you give up.

That really brings the ethics of design into sharp focus.

Okay, moving to our third pillar.

How do designers speed things up using open -source resources?

So open -source just means the software source code is freely available for anyone to reuse and modify.

It's a huge community effort.

And for UX, this means you can get pre -written code for design patterns or even entire systems.

Exactly.

A great example is the Bootstrap framework.

It's an open -source toolkit for web development.

It gives you reusable code snippets, layout grids that work on different screen sizes, ready -made buttons, tabs.

It gives you speed and consistency.

A designer can go from a simple wireframe to something that looks and feels coherent almost instantly.

Yes.

And all these massive resources are managed in repositories like GitHub, which uses something called Git version control.

GitHub is huge.

We know it has over 30 million users.

What's the practical benefit for the UX designer working on a team?

It allows massive communities to collaborate on code and track every single change.

This many -eyes approach means bugs and security holes get spotted way faster.

For a designer and developer working together, it's the system that ensures you're both looking at the exact same, most up -to -date version of everything.

Finally, let's talk about the fourth pillar, the tools designers use every day.

This landscape is always changing.

There are tools for every part of the process, from brainstorming to checking for consistency.

You've got things like Visio, Sketch, and so on.

We've definitely moved beyond just drawing on paper.

Well, because paper can't support user -driven interaction, you can't test a flow on a piece of paper.

So now we rely on commercial tools like Balsamiq, Acture, and Sketch to quickly build interactive wireframes and mockups.

And it's all about that fidelity progression, right?

Moving from simple to more detailed.

That's the common workflow.

You might start with a low -fidelity interactive wireframe in Balsamiq, and then you can jump to a much higher -fidelity prototype just by pulling in a pattern library like Bootstrap.

You get a coherent look and feel instantly.

But for really complex products, that's not always enough.

No.

For something like a business intelligence tool at a company like SAP,

where performance is everything,

simple mockups won't cut it.

The UX designer has to work with the developer to actually prototype parts of it in code, maybe in Java, so they can test the performance, not just the interaction.

And the source notes that the best tools, like mockups, have this blend of ease of use.

They feel like normal graphic software, but with really precise controls, like rulers for perfect positioning.

That mix of speed and precision is exactly what professional practice needs.

So we've covered a lot of ground.

It seems like the big takeaway is that interaction design in the real world is less about being an isolated genius.

And much more about effective integration, collaboration, and just leveraging all this existing knowledge.

We've gone through the adaptations needed for Agile UX, the time -saving power of design patterns, the accessibility of open source code, and the speed you get from modern digital tools.

These four pillars are really what allow designers to deliver quality work when they're under that relentless commercial pressure.

So if we bring this all back to the philosophical challenges you mentioned earlier, we end up back at that quick,

slow dilemma.

We do.

We've talked about how to execute quickly, how to work in these tight time boxes.

So the critical question that we want to leave for you, the listener, to think about is this.

In that race to get a product to market,

how do you make sure that the incredible momentum of Agile development doesn't end up sacrificing the time needed for deep reflective design?

How do you make sure your products are not just fast, but sustainable and truly built to last?

That's the challenge.

A fascinating one to think about.

Thank you so much for joining us for this deep dive.

We'll catch you next time.