Low fidelity design: A guide to making your design process inclusive - Daniel Sauble (Config 2021)
Summary
TLDRThe 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
đ 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.
đš 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.
đ€ 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.
đ 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.
đ ïž 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.
Mindmap
Keywords
đĄLow Fidelity Design
đĄInclusivity
đĄOpinionated Stakeholder
đĄPrototype
đĄUsability Test
đĄCognitive Dissonance
đĄLead Developer
đĄFeasibility
đĄSacrificial Concept
đĄFuzzy Matching
đĄMVP (Minimum Viable Product)
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.
Voir Plus de Vidéos Connexes
Paper Prototyping 101
Wireframes & Prototyping Explained in Hindi | UX/UI Design Fundamentals | Figma in Hindi
What Is Wireframing? (A UI Design Tutorial)
Human centered design
Sole Survivor: How Fidelity Investments reduced Jira customizations by 99% | Team '23 | Atlassian
Can UX Designers make assumptions?
5.0 / 5 (0 votes)