Low fidelity design: A guide to making your design process inclusive - Daniel Sauble (Config 2021)

Summary

The speaker emphasizes the importance of low fidelity design in fostering inclusivity within the design process. They discuss challenges like opinionated stakeholders and the difficulty of obtaining genuine user feedback, and demonstrate how low fidelity prototypes can engage non-designers, facilitate clearer communication, and encourage unfiltered feedback. The talk also highlights the benefits of involving developers early to explore feasibility and make the design process more collaborative and efficient.

Takeaways

• 🔍 Low fidelity design is a tool for inclusivity in the design process, allowing non-designers to participate more easily.
• 🗣️ Stakeholders often have ideas they want to contribute, but struggle to engage with the design process effectively.
• 🤝 Involving stakeholders early by visualizing their ideas can lead to better communication and alignment on the problem to be solved.
• 👥 Users may provide overly polite feedback on high-fidelity prototypes, but low-fidelity designs can encourage more honest critique.
• 🛠️ Developers can be more engaged in the design process if they are included in feasibility discussions using low-fidelity sketches.
• 📈 Low fidelity designs can help in exploring multiple solutions to a problem, which is beneficial for both ideation and validation.
• 🔧 It's crucial to discuss with developers early in the process to understand the feasibility and effort required for implementation.
• 📊 Creating sacrificial concepts (intentionally flawed ideas) can encourage more candid feedback from users, improving other concepts.
• ✂️ Low fidelity allows for flexibility and iteration in design, signaling to users and developers that the design is still in flux.
• 🎯 The goal of using low fidelity in design is to create an environment conducive to diverse perspectives and unfiltered feedback, leading to better product outcomes.

Q & A

What is the main focus of the talk on low fidelity design?

The main focus of the talk is on how low fidelity design can promote inclusivity in the design process by involving non-designers and ensuring diverse perspectives are considered.

What is an 'opinionated stakeholder' as mentioned in the script?

An 'opinionated stakeholder' refers to a person in a project kickoff meeting who often has a specific idea for a solution they want to be implemented quickly, which can potentially bypass the designer's preferred problem-first approach.

Why is it challenging for designers when users give overly positive feedback during usability tests?

Designers find it challenging when users give overly positive feedback during usability tests because it does not provide the unfiltered, critical feedback needed to improve the design effectively.

What does the speaker suggest as a method to engage stakeholders more effectively in the design process?

The speaker suggests visualizing stakeholders' ideas, such as through sketches or diagrams, as a method to engage them more effectively and align their ideas with the design process.

How does the speaker propose to handle the scenario where developers invest significant effort into a design that may not align with the designer's vision?

The speaker proposes having early conversations with developers using low fidelity sketches to explore feasibility and different paths, preventing them from investing too much effort down an incorrect path.

What is the significance of using low fidelity in the design process according to the speaker?

Using low fidelity in the design process is significant because it encourages participation and feedback from stakeholders, users, and developers by signaling that the design is still in a mutable and early stage, allowing for more inclusive collaboration.

Why does the speaker believe that low fidelity design can lead to more authentic user feedback?

The speaker believes that low fidelity design can lead to more authentic user feedback because it does not intimidate users with a finished look, making them more likely to provide honest and unfiltered opinions.

What is the 'sacrificial concept' mentioned in the script and why is it used?

The 'sacrificial concept' is an intentionally imperfect idea used to encourage unfiltered feedback from users. It serves as a contrast to better ideas, making it easier to gather honest opinions on the more viable concepts.

How does the speaker suggest using low fidelity sketches to involve developers in the design process?

The speaker suggests using low fidelity sketches to start a conversation with developers about the feasibility and effort required for different design paths, allowing for adjustments before the design moves to a higher fidelity stage.

What are the two schools of thought regarding the release of features mentioned in the script?

The two schools of thought regarding the release of features are the MVP (Minimum Viable Product) camp, which advocates for shipping value in small increments, and the comprehensive delight approach, which aims to solve user problems thoroughly in larger releases.

How does the speaker recommend deciding between an MVP release and a more comprehensive feature release?

The speaker recommends discussing with developers at a low fidelity stage to understand the feasibility and effort required for different features. This information can guide the decision on whether to release an MVP or a more comprehensive feature set.

Outlines

00:00

🔍 Inclusivity in Design Process

The speaker introduces the concept of low fidelity design with a focus on inclusivity, aiming to involve non-designers in the design process. They discuss common challenges such as opinionated stakeholders, overly polite users, and the difficulty of integrating developer feedback. The speaker emphasizes the importance of starting with a problem and working towards solutions, and suggests that low fidelity design can help break down barriers and include diverse perspectives.

05:00

🎨 Visualizing Ideas with Low Fidelity

The speaker shares an experience where they used low fidelity sketches to engage stakeholders and users effectively. By visualizing ideas through simple diagrams and concepts, they facilitated better communication and received more genuine feedback. The speaker also explains how low fidelity prototypes can be used to explore multiple solutions and engage developers in early feasibility discussions, leading to more efficient and collaborative design processes.

10:01

🤝 Collaborative Design with Stakeholders

In this section, the speaker describes a scenario where they actively involve a stakeholder in the design process by visualizing their idea of a sortable table. They then use low fidelity sketches to storyboard different solutions, including sorting and filtering, to address the problem of finding a person in a list. The speaker also introduces the concept of a 'sacrificial concept' to encourage honest feedback from users, which helps refine the other, more viable concepts.

15:05

📊 User Feedback and Concept Validation

The speaker discusses the importance of getting unfiltered feedback from users and how low fidelity prototypes can facilitate this. They present three concepts to users and explain how the feedback helps in validating the ideas. The speaker also touches on the concept of MVP (Minimum Viable Product) and the balance between shipping small increments of value and creating a comprehensive, delightful experience for users.

20:05

🛠️ Feasibility Discussion with Developers

The speaker emphasizes the value of early conversations with developers regarding the feasibility of design concepts. They explain how discussing low fidelity prototypes can inform decisions about the scope of a release, whether to ship an MVP or a more comprehensive solution. The speaker suggests that involving developers in the early stages can prevent inefficiencies and ensure that the design solutions are not only user-centered but also feasible from a technical standpoint.

🌟 Encouraging Inclusive Design Practices

In the concluding part, the speaker reflects on the benefits of using low fidelity in design for inclusivity, effective communication, and collaboration. They encourage the audience to explore the use of low fidelity in their own design processes to enhance inclusivity and create better design outcomes. The speaker expresses gratitude for the opportunity to share insights on low fidelity design and hopes to inspire the audience to improve their design practices.

Keywords

💡Low Fidelity Design

Low Fidelity Design refers to the use of simple, basic, and often hand-drawn sketches or wireframes to represent the layout and functionality of a product or feature. It is an approach that focuses on the core ideas and user experience rather than the detailed aesthetics. In the video, the speaker emphasizes how low fidelity designs can be a tool for inclusivity, allowing non-designers to engage in the design process without being intimidated by high-fidelity prototypes. The speaker uses the example of creating a visual taxonomy and workflow diagram to illustrate how low fidelity can facilitate communication and collaboration.

💡Inclusivity

Inclusivity in the context of the video refers to the practice of involving a diverse range of stakeholders, including non-designers, in the design process. It's about creating an environment where everyone feels comfortable contributing their ideas and perspectives. The speaker discusses how low fidelity design can break down barriers and encourage more inclusive collaboration, as it reduces the pressure associated with finalizing designs early in the process.

💡Opinionated Stakeholder

An 'Opinionated Stakeholder' is a term used in the video to describe individuals who have strong, often unsolicited, ideas about the design or direction of a project. These stakeholders may want to push their solutions quickly without going through the standard design process. The speaker suggests using low fidelity sketches to engage these stakeholders by visually representing their ideas and integrating them into the broader design conversation.

💡Prototype

A prototype, as mentioned in the video, is an early model of a product used to test concepts and gather user feedback. The speaker contrasts high-fidelity prototypes, which can be complex and detailed, with low-fidelity prototypes that are simpler and more open to change. The video argues for the use of low-fidelity prototypes to encourage user feedback and iterative design.

💡Usability Test

A usability test is a method for evaluating a product by testing it with users to find out how easy it is to use. In the video, the speaker describes a scenario where a high-fidelity prototype is tested, leading to users giving overly polite feedback that doesn't reflect the true usability issues. The speaker suggests that low-fidelity prototypes can elicit more honest and useful feedback due to their preliminary and mutable appearance.

💡Cognitive Dissonance

Cognitive dissonance is a psychological term referring to the discomfort people feel when they hold two contradictory beliefs or when their behavior contradicts their beliefs. In the video, the speaker uses this term to describe the situation where users give positive feedback on a prototype despite experiencing difficulties, creating a dissonance between their true feelings and their expressed feedback.

💡Lead Developer

The 'Lead Developer' mentioned in the video is the person responsible for overseeing the technical development of a product. The speaker discusses the challenges of communicating design visions to lead developers and how low-fidelity designs can facilitate better understanding and collaboration by allowing for early discussions about feasibility and implementation.

💡Feasibility

Feasibility in the video refers to the practicality of implementing a design solution, considering factors like time, cost, and technical constraints. The speaker emphasizes the importance of discussing feasibility with developers using low-fidelity designs to ensure that the design solutions are not only creative but also practical to build.

💡Sacrificial Concept

A 'Sacrificial Concept' is a deliberate, often intentionally flawed, idea used to encourage honest feedback from users. The speaker introduces this concept in the video as a way to get unfiltered reactions and to make users more comfortable providing critical feedback, which can then be used to improve the other, more viable, design concepts.

💡Fuzzy Matching

Fuzzy matching, as discussed in the video, is a technique used in search functions to allow for flexible and approximate string matching, which can be useful when users make typos or are uncertain about their search terms. The speaker uses fuzzy matching as an example of an idea that can be explored and tested using low-fidelity prototypes.

💡MVP (Minimum Viable Product)

MVP stands for Minimum Viable Product, a product with just enough features to satisfy early customers and provide feedback for future development. The video discusses the balance between shipping an MVP to get value to users quickly and waiting to include more comprehensive features for a more delightful user experience. The speaker uses low fidelity designs to explore this balance with developers and make informed decisions.

Highlights

Emphasizing inclusivity in design processes through low fidelity methods.

Engaging non-designers by utilizing low fidelity designs in the early stages.

Addressing the challenge of opinionated stakeholders in design meetings.

The importance of starting with a problem statement rather than jumping to solutions.

Managing the feedback from overly polite users during usability tests.

The dilemma of receiving positive feedback on prototypes that have usability issues.

The struggle of designers to receive unfiltered feedback for improvement.

The issue of lead developers taking long to implement designs and potential misalignments.

The need for designers to be involved in the implementation phase to ensure feasibility.

Introducing small changes in the design process to encourage stakeholder involvement.

Visualizing stakeholder ideas to create a shared understanding and open dialogue.

Creating multiple concept variants to stimulate diverse user feedback.

The benefit of low fidelity designs in facilitating honest and unfiltered user feedback.

Initiating conversations with developers using low fidelity sketches to discuss feasibility.

Using low fidelity designs to explore multiple solution paths with developers.

The concept of sacrificial concepts to encourage honest feedback from users.

The value of storyboarding ideas to visualize and communicate stakeholder visions.

Discussing the balance between shipping minimal viable products and comprehensive solutions.

The role of low fidelity designs in making the design process more inclusive and collaborative.

Encouraging designers to experiment with low fidelity methods to enhance their design universe.

Transcripts

Hello.

I'm super excited to talk to all of you

about low fidelity design.

The lens I'd like to take today is, actually,

focused on inclusivity, and how we can make sure

that, by using low fidelity, we're

pulling in non-designers into our design process.

So before we dig into low fidelity,

I want to talk about a few scenarios that might

sound familiar to some of you.

So one of these I deem the opinionated stakeholder.

So if you're like me, you're in a lot

of project kickoff meetings.

And one of the things that I often see in a kickoff meeting

is that you'll have some stakeholders present,

and, inevitably, at some point in the presentation,

they'll raise their hand and say, hey,

I have this idea for a solution.

I think we should build a very specific thing,

and we should build it, as quickly as possible.

And then we should deliver this value to customers and profit.

Are we done?

And as a designer, obviously, I have strong feelings

about this.

I believe very strongly in starting with a problem

and then working forwards to solutions.

But at the same, time I think the stakeholder often

wants the same thing that we as designers want.

They want to deliver something that solves the user's problem.

And they're just not always sure how to engage with our design

process.

But there's other scenarios much like this.

This one I call the overly polite user.

So often you'll get into your design process,

and you'll come up with a prototype.

And you'll show this prototype to some users.

You'll do a usability test.

And you'll give them some scenarios,

and watch them try and use your prototype

to solve their problem.

And sometimes, they'll have a lot

of issues using your prototype.

And it's painful to sit there and watch them, and see

things going off the rails.

And so you'll get to the end and you probably

have a pit in your stomach.

And you're asking them, OK, well how did it go?

How do you feel like this would solve your problem?

And to your utter shock and dismay

they tell you, well there were a few things I stumbled on,

but overall the product seems great.

I'm giving it 10 out of 10.

Ship it.

And so once again, as a designer this is hard to hear,

because part of a great design process

is this idea that you want to pair up with your users

and get that unfiltered feedback that you need,

so importantly, to make the best possible product that you can.

Well there's more scenarios like this.

Let's say that you're at the very end of your design

process, and you're now ready to, actually, build the thing.

So you meet up with your lead developer.

And you show them this wonderful set

of mocks that describe your vision to the last pixel.

And they look at it.

They nod sagely a few times.

And then they say, yep we're going

to go off and try and build this.

And they disappear.

And three days later, you're waking up

one morning, you think, wow it's been a while since I

heard from those developers.

I should probably check in and see how things are going.

So you reach out on Slack, and say, how's it going

with a design implementation?

And they get back to you and they say, well it's going OK.

It's taken us 20 hours of effort so far.

And we're kind of converging on your vision,

but it's not quite right, yet.

But you're the expert, and we know

that your vision is the right thing

to solve the user's problem.

So we're going to keep going.

And this raises all sorts of alarm bells for me.

Because, again, as a designer, part of the design process,

it doesn't end at the point in which you hand off mocks.

It continues into implementation,

and you want to be sensitive to the effort required

to build things.

So one of the things that, as a designer,

I want to figure out how I can pull

the developer into my process and explore feasibility

before they get down the wrong road, too far.

So, obviously, there's this wall.

And this wall is what prevents our design process from being

as inclusive, as it could be.

What we want is for this wall to be gone,

and for people to be able to engage with us,

as designers, so that we get as many different people

in the room, as possible, with as many different perspectives,

as possible, to deliver the best possible product that we can.

So what do we do about this?

So I was asking myself this very question at work.

I'm at New Relic.

And one of the things that I was realizing

is maybe there's small changes I can introduce into the process

to nudge people towards being involved in the design process.

Because I was realizing that it wasn't

enough to have these other people in the room

with you, if they're still too hesitant to engage.

So we're in a kick-off meeting, and I

decided I was going to do things a little bit differently.

So the stakeholder gets their hand raised up,

and they say, you know I had this idea for a solution.

And instead of reacting to that, I

said, OK, let's write down your idea.

Let's express it visually.

And we ended up creating this cool taxonomy slash workflow

diagram that helped us have a single visual artifact we could

use to talk about the thing that we were trying to deliver.

And we had a great conversation.

And so afterwards, I was thinking

it might be cool to conceptualize what

a solution might look like.

And so I started sketching out some concepts.

And then the researcher I was working

with reached out and said, you know,

I think these concepts are great,

but I think it be also great to have some variants, so

that when we show these to users,

they have multiple different things to look at and react to.

So then I went ahead and created multiple variants

on each of those concepts.

So we show this to users and it was amazing.

We got feedback that, as they were looking at it,

we saw that they were struggling with various concepts

in the comments.

And then when we asked them about it, the feedback

they gave us didn't have that same level

of cognitive dissonance that I noticed before.

And so once again, things were going a little bit

better this time.

And so after we got all the feedback, the next thing we did

was talk to developers.

And we show them these sketchy concepts.

And what that did is it sparked a conversation.

And instead of them going off and trying to build the thing,

we had a conversation about feasibility,

and different possible paths they could take,

and how hard those different paths might be.

So this whole process was going, surprisingly, well.

And afterwards I did a bit of a retrospective

to think about what was going so well

and what the common factor was.

And I think this low fidelity idea, actually,

is one of the keys to inclusively in your design

process.

And I think one of the reasons why low fidelity is so great

is that it gets people into a mode where

they're designing without realizing they're designing.

When you show something that's very high

fidelity and pixel perfect, it's kind of intimidating.

It kind of looks like something that you're well on your way

to building.

And if they were to give you feedback,

it probably wouldn't be well incorporated,

or you're not going to have time to adjust.

Whereas, when you show something low fidelity, all of a sudden

they see that you're early in your process.

And if they give you feedback, there it's

time to get it incorporated, as you move to high fidelity.

So let's go back to those original scenarios

that I was talking about.

And let's see how low fidelity might change the narrative

a little bit.

So for a stakeholder, every stakeholder I've ever known

has a lot of interesting ideas in their brain.

And the chief challenge that a lot of them

have is getting those ideas expressed

in a way that gets them and their team on the same page.

And as designers, visualizing ideas

it's kind of our superpower.

And the way that we do this doesn't matter so much

as the fact that we do this.

So you can use user stories.

We can do storyboards, wire frames, workflows.

These are all ways of getting ideas expressed.

So we can take that stakeholders idea, and we can express it.

And then we can ask them, we can probe, and say,

what's the problem that you're trying

to solve with the solution that we've now expressed visually,

and that you agree is reflective of what you're thinking?

And so if we can extract a problem statement

from the stakeholder, then we can run the problem statement

through our design process and come up

with more ideas that can sit alongside that stakeholder's

idea.

And this is all stuff that low fidelity really, really shines

at.

What about users?

So there's an analogy I like to use,

which is that if I'm thinking about climbing a mountain,

there is a lot of details that don't really matter.

As someone climbing a mountain, the thing

I primarily care about is whether it's

safe to climb a particular mountain.

So knowing that the mountain is erupting

is really important information.

And the thing is you don't need high fidelity

to express that important concept.

In fact, low fidelity is often better,

because you can strip out the things that you

don't want to distract people by and don't want their feedback

on.

And so low fidelity is a way of helping

users stay very much focused on the concepts of the details.

And as I mentioned earlier, the other great thing

about low fidelity is that it signals to people where

you are in your design process.

If they see something low fidelity,

it looks very mutable.

It looks like you can reach out and make changes easily.

And so, you're not only telling people

that the design is open for change,

but you're actually showing them through the medium

that you're using that is open for change.

What about developers?

I think with developers, it's first it's very similar.

Low fidelity is wonderful for exploring multiple paths.

And you can take those multiple paths, and talk to a developer,

and explore the feasibility of each path.

So you might go to a user, show them concepts,

and get their feedback on the concepts.

And then realize, Oh, there's these three ideas

that each are fairly well-positioned to solve

the user's problem.

But without knowing how difficult they are to build,

it's really hard to know which one to settle on.

And so having a conversation with the developer

lets you explore that.

And because it's low fidelity, they can't just

go off and build it, right?

And so you can have a conversation

in low fidelity with a developer that helps you

as a designer figure out where to go as you move things

to high fidelity in your design process.

So let's do something a little bit different.

And let's try this live.

And we're just going to take 10 minutes.

And we're going to go through a fictional project, where

we go through an entire project and see

what it's like to use low fidelity to make your design

process a little bit more inclusive

than maybe it was before.

So if you're following along at home,

or you want to try this afterwards,

you're going to need some materials.

I'm a big fan of pen and paper, but also a stylus and a tablet

is excellent, as well.

I've, actually, used both of these

for this particular presentation.

But the idea is that you need a medium that

helps you express your ideas in low fidelity,

and do so in a way that's highly collaborative.

So let's imagine a fictional project.

Let's say that we're in a kick-off meeting,

involving a new feature that has a table in it.

And this table lists different people.

And so we're in this kick-off meeting

talking about this project.

And the stakeholder raises their hand and they say,

I think we should make this table sortable.

OK, so the first thing we should do

is we should express their idea and make sure

that we're articulating what they're talking about,

accurately.

But then we should push back and ask, OK,

so what problem are you trying to solve with this?

And the stakeholder might have an offer in a second

and then say, Oh, well imagine if someone

comes into this feature, they're going to be looking

for a particular person.

And if the table's not sorted, it's

going to be really difficult for them to find

the person they're looking for.

So that's why I think we should make this table sortable.

So this is great, right?

Because we have a solution that the stakeholder has given us.

And now we have a problem that we

can run through our design process

and come up with more ideas.

So what we're going to do now is switch over

to a video, where we show this process of storyboarding

different ideas.

So here I've got my favorite pen and pencil, or pen to paper.

And we're going to storyboard the stakeholders idea.

So the stakeholder has told us that they think

this table should be sortable.

So let's create this the storyboard.

So we're going to start with just a simple table that

has a couple of columns.

We'll give it maybe a first name column, and a last name column.

And we're going to go ahead and click on,

they put a little virtual cursor next to this first column, just

indicate this is where we're going to go

to initiate the sorting action.

And then just to complete this example,

we'll add a few names to our table,

just so that we have some data to work with.

Great, so this is just a simple example

to see if we're articulating stakeholders'

vision accurately.

And so in the second cell, we're going

to show what happens after I've clicked this column.

So now we're going to have this table be sorted by first name.

So we'll add a little carrot there.

It's the first name.

And then we're going to put our data in the table,

as we did before.

But this time we're going to sort it.

So what this lets us do is it lets

us show the stakeholder that we understand their idea before we

back up and start rolling forward from the problems

statement, again.

So now let's have some fun with this.

Let's think about another way we can

solve this problem of finding a particular user in this table.

And let's do something that involves filtering.

So in our filtering solution, we're

going to put a filter box right on top of our table.

And so we'll create a filter box.

And we'll put a virtual cursor in the filter box,

so we can see that this is what we're clicking

to initiate this filter action.

And then below our filter, we'll go ahead and put in the table,

as we did before, with all of our names.

And then once we put this together, in the next cell

we're going to show what happens if we search for something.

So we're going to go ahead and search for Adam.

And because people might have a typo

or maybe they're not entirely sure what they're looking for,

we'll make this flexible by using fuzzy matching.

So if they search for Adam, maybe we

can return some names that have Adam in them, but maybe

with two Ds instead of just one.

So Let's just illustrate this one really quick.

So this is great, because this gives us a second solution that

could sit alongside that stakeholders' original idea

and it can be on the same playing field.

But now, let's add a third idea.

And let's do something a little bit different.

Let's create something that is called the sacrificial concept.

And the idea behind a sacrificial concept

is that you're exploring ideas that

are almost certainly not good.

So why do this?

So the reason you do this is because, when

you're showing concepts to users,

you want unfiltered feedback.

And it's much easier to get unfiltered feedback

on something that looks imperfect.

And so for this idea, we're going

to create a grouping concept.

So in our table, we're going to have all the names grouped

by first letter.

And so if I want to see all names beginning with A,

have to click this A group to expand the A group.

So this is objectively a bad idea.

But what it does is it's going to get people

into a mode, where they're giving us the kind of feedback

that we need to make the other concepts as good as they

can be.

So once we finish illustrating this last cell,

we'll have three concepts that we can now

validate with our users, while also incorporating

that original stakeholder idea that precipitated

this whole exercise.

Perfect.

So now we have these three concepts.

And we have to figure out which concepts are going to be good

and which ones are going to be bad.

So we could pull the view back to the slides.

Perfect.

So we're going to show this user.

So we have these three concepts, A, B, and C.

And so we're going to show this to users.

And they might look at the first one,

and be like sorting makes sense for me,

because often when come here, I don't know

exactly who I'm looking for.

And I just want to be able to scan until I

find what I'm looking for.

And then they might look at the middle concept

and say, this also makes sense to me,

because sometimes I know exactly who I'm looking for

and I just want to see that person in the list.

So I want to be able to type them in or copy and paste

the name from a spreadsheet.

But then they might look at the third concept and say,

you know, I'm not entirely sure what you're trying to do here.

This isn't the pattern I've seen in other products I use,

I'm really confused.

I think this one's a miss.

And you're getting that raw unfiltered feedback

that you're looking for.

So this is great.

So we've explored three concepts.

We've validated them with users.

We've learned that our sacrificial concept is not

good, which we knew already.

And we've gotten some authentic feedback on the other two

concepts that we're exploring.

So now we need to talk to our developers

and explore feasibility.

And so as designers, there's kind

of two schools of thought related to when you release

and how much stuff you bundled together when you release it.

One school of thought is the MVP camp.

And this is the idea that you need to ship value

in tiny increments.

The reason you want to do this is

because you don't want to leave value on the shelf,

getting stale over time.

You just want to have a continual stream

of stuff being shipped out.

The problem with this is that those tiny increments often

aren't very delightful.

They often don't solve the user's problem comprehensively,

and they can be a bit of a letdown.

On the other end of the spectrum,

you have this idea that you want to be

as delightful, as possible.

You want to solve things as comprehensively, as possible.

And you want to surprise people by solving their problem more

thoroughly than they could have imagined themselves.

And this, obviously, entails shipping things

in larger bundles than you might otherwise.

Now we probably don't want to be on either extreme,

but we don't know, necessarily, where we

need to sit on this spectrum.

And so if we talk to our developers about these concepts

that we've been validating, they might

look at the sorting concept and say,

this isn't that difficult to implement,

because our table already supports the ability to sort.

So far, so good.

Then we might show them the filtering concept,

and they might say, you know this also

is not that difficult to implement,

because our table supports the ability to filter,

and then adding an input field on top of the table that

lets us input the filter query is also not difficult.

So this is useful information for us as designers,

because it means that we could go either route

and either one is going to be efficient to build.

But what this doesn't tell us is where we fall on the spectrum

of should I ship a very minimal MVP,

or should I ship all the stuff at once

to make this a delightful experience.

So the other thing that we might hear from our developers

is that it's not only easy to do each of these, individually,

but it's also easy to do them together.

In fact, because they're already into the same code,

it's probably more efficient to make both of these changes

at once rather than making these changes individually.

And so just like that, by having this conversation

with our developers, while we're still at this conceptual phase,

they're able to inform us as to how comprehensive

and delightful we can get away with in this release,

without running the risk of having a bunch of values

sitting on the shelf for months on end.

So really you have to talk to developers early

if you're going to understand from the feasibility

perspective how much delight you can chip at once.

So now it's not your turn.

We've talked a lot about a lot of really interesting ideas.

We've talked about how to use low fidelity to pull out ideas

from your stakeholder and get them expressed,

so that the stakeholder is able to build

a common understanding with the team about what

their vision is.

While also then being able to back up, and have a problem

statement, and then run forward, and generate more solutions

that can sit alongside the stakeholders original idea.

And low fidelity is great for this.

The other thing we've talked about

is the importance of really trying

to extract as much unfiltered feedback from users, as

possible.

And how low fidelity, again, is really great here.

Because when you show someone high fidelity mock,

it looks as though you're very far along

in your design process.

And if they were to give you feedback,

it would be very difficult for you

to apply that feedback into the design,

before you go to implementation.

And even if that perception is not true,

the fact that there can be a perception

means that it's good to strive to make the medium look very

mutable and able to change and reflect

the feedback that you're given.

So this is where low fidelity and concept testing

can work together to create that environment that's

very, very much conducive to unfiltered feedback.

And then the final thing we talked

about is this importance of talking to developers

and exploring this question of feasibility.

I think it is very easy to be comfortable with the developer

who really wants to make things look great,

and they want to respect your vision as a designer.

But when you find these people, it's

often that they can take it too far.

And go all the way to trying to build something that is just

not as efficient as it could be, while also solving

the problem efficiently.

So having these conversations with a developer

in low fidelity can help you explore

the feasibility of different ideas

before you take them to the next level.

So I'd like to turn this back to you

and encourage you to explore how low fidelity could

be used to make your design process a little bit more

inclusive.

So thank you so much for your time.

I loved speaking to all of you about low fidelity today.

And I just hope that all of you can take what you're learning

and use it to make your corner of the design universe

just a little bit more awesome.

Thank you.