Shadowing Practice: How to organize and present your design explorations for feedback - Learn English Speaking with Video

If you're like me, chances are you have a section

or page in your Figma file for you to go rogue and explore different ideas and concepts.

For me, usually I have either like a sandbox or a playground page just dedicated for me, my personal space to explore different ideas.

A quick shout out to Superfair for being a sponsor of my channel.

Without them, this channel wouldn't be as great as it is today.

I run my whole community through Superpeer.

We do live events, multiple live events every month.

You can also book one -on -one mentoring sessions with me there.

So go and check out my Superpeer profile to book time with me or to join my community.

Ideation and exploration is an important part of the design process and usually comes in the first part of the double diamond.

And if you're not sure what I mean when I'm talking about the double diamond, go and check out this video I made here all about the double diamond process.

Now imagine you're a product manager or an engineer

and you're coming in to the Figma file to review different explorations and ideas that you're proposing asynchronously.

I can imagine for them it's probably pretty overwhelming to come into someone's Figma file

and might be difficult for them to figure out what the latest is, the different explorations you're trying to share, and what your rationale and thoughts are behind those different explorations.

Or let's consider a design review, where the purpose of the review is for you to present different explorations, get some feedback from your reviewers.

Walking reviewers through your design explorations, whether it's asynchronously or in a design review, does require some skill.

And I do think that there are ways

that you can set yourself up for success here to make sure

that you're getting the most effective kind of feedback that you need to move forward.

So to do this, you'll need to provide context, show your concepts, have rationale for those different concepts,

and lastly, have a recommendation or a preferred solution that you would like to move forward with.

Context can either be provided in advance of the review through like a pre -read that you share out asynchronously, or you could provide it in the review itself.

And this is what I usually do where I have a

couple of slides at the beginning of my presentation to kind of set the context

and let folks know where we're at in the project.

So I usually share where we're in the design process, any key dates or milestones coming up, the problem statement and what we're trying to solve

and maybe something around sort of the product requirements or like exactly what this review is focused on.

Then I dive into presenting the different concepts and ideas that I have.

I might talk about the pros and cons for each of those concepts

and make sure I'm really touching on the rationale behind my decisions.

on how to do that confidently, clearly and concisely.

Rationale is important because it's going to help you get more buy -in

and convince your stakeholders of the direction you want to move forward with.

It's no help showing concepts without giving any rationale behind the decisions you're making and why you believe in this concept.

So it's worth putting the extra effort into documenting that

and presenting it so your reviewers know the thought that's been put in behind your decisions.

So rather than talking about how to do this, I actually want to jump on over into Figma

and walk you through some real examples from my past projects of kind of how I've laid out different explorations,

how I've communicated and articulated rationale in reviews and in sort of one -on -one jams with my PM.

It's not perfect and I didn't sort of touch up or tidy anything in advance of doing this video.

I want to show you the raw real kind of behind -the -scenes work of some of my projects.

And I feel like my process for this has evolved over time

and kind of adapts and changes based on who I'm trying to get feedback from, project is in so I would probably put a lot more effort into having really concise

and clear articulated documented rationale

if I was presenting to a senior stakeholder versus just trying to jam on a few ideas with my PM.

You'll see in what I'm about to show you that the fidelity differs quite a lot also.

I have some really low fidelity wireframe -y type stuff to some more high fidelity flows

so I don't think there is a particular rule as to what the fidelity should be regardless of

those different explorations and ideas that you have.

Hopefully you can get some inspiration from this.

Let's go.

Okay, so here we are in Figma.

And as promised, this is messy and not necessarily beautiful high fidelity designs.

But this was a project I was working on back at Uber Eats, where we were bringing stories into Uber Eats.

And so here you can see I had three different ideas laid out, very low fidelity here, like we're just focusing on the entry point.

And then I kind of explained each one and some of the questions I had.

So in this exploration, for example, view the updates

and like I had sort of a pro here like works well as a permanent entry point

but I also had maybe not necessarily cons

but like questions you know like things we need to think about

if we were to take this approach

so here's just a look at sort of

that button exploration this was exploring like having the entry point be within the profile picture of the merchant

and you can see here I added preferred solution so really pointing out what my recommendation is and then

that would tell you like there is a new update.

So that's how I laid those out.

And then another part of this project was also kind of diving into what the updates would look like.

And I kind of had two different explorations.

One was like a newsfeed style and the other one was like a full screen story style.

Again, you can see which one I'm recommending.

But another interesting thing that I did here was kind of breaking this out into MVP and like future or like vision.

was going to creep beyond the scope that we had for this project, I kind of like laid out, okay, well, ideally we could get to this in the future,

but today for MVP, you know, it would be something a little bit more basic.

And I found that this was really helpful because I found that if I only show the like MVP version, sometimes I can get asked a lot of questions around like, well, why not this?

Or what about that?

And it's like, okay, yeah, those are all great ideas.

I would love to do helpful to show the future vision to let people know I've thought about that.

These are things that I have been considering and I think would be great in a future version.

So I don't know, that was like something I learned as I went, as I was presenting and sharing my ideas a lot of the time that it was just helpful to show like, okay, here's realistically what we can do now.

And here's what we can do in the future.

And last note on that, I also find showing the future one can be helpful in terms of like, if you know, that's where you want to go, let's choose an MVP version

there in the future so for example if we were aligned

that say our future vision would be this like full screen

story style let's not do this as an mvp even though it may be easier for now

because that's only going to create like design and tech debt

and it's going to take us longer to get to

that future vision so yeah that's why i broke it out

that way the next one is for the same project

but in this case i broke it down by user stories so i can't remember where

user stories kind of written out in this case i've just taken one example

which is this user story here and then i broke out the explorations for

that particular user story

so here we can see an exploration for entry point here

we can see an exploration for having the message be more

embedded on the screen i know i'm not providing full context

of the project just kind of try to focus on like

how i'm presenting the information here's like another exploration where i did more of a teaser

approach supporting this user story and again having that clear recommendation.

100

Okay next one, next one.

101

Moving on to another project.

102

So this project, I was kind of exploring both the placement and the visual design of something.

103

And you can see here that I didn't include like any sort of written down context or rationale.

104

This was because I was jamming on this directly with my product manager.

105

So we would have like one -on -one weekly jams.

106

And like this was enough for us to have discussion, right?

107

Like we just wanted to have conversations around what would work.

108

And for that purpose, he's the PM on the project.

109

I didn't feel like I needed to provide like all that background context and really break out the pros and cons.

110

But what I like about this approach is

111

that like first I was just exploring the placement of the like let's call it a widget.

112

I was basically adding a widget to the screen which is this like gray box of audience size.

113

And so I have these different explorations here on like where

114

that could go on the screen like what the different placement could be.

115

And so again like really low fidelity this is like just to have a conversation with my PM right

116

start those conversations like what might it feel like

117

if it's down here or like over up here

118

and then the next sort of section was around like what the visual of

119

that widget would be and so I had like inspiration on the left

120

and then like the uber style of it on the right using sort of our design system

121

and things like that and

122

so again like I don't have a lot of written down rationale here

123

but this was like great just to have those conversations and discussions

124

and then the last one was kind of like placing those widgets actually onto the screen in the placement

125

that we were kind towards which you can see is this placement with it here on the right hand side.

126

I think you can kind of adapt how you present and show these explorations based on your audience.

127

So in my case, this was just a jam with my PM.

128

I didn't have to go and create that like perfectly organized, all of the context rationale written down kind of version of this work.

129

This was enough for us to have the conversation for us to make a decision together.

130

And then I would have done

131

that for like the next step of sort of getting stakeholder alignment or like a design review.

132

This one is a early concept exploration.

133

So again, quite low infidelity.

134

If I zoom in here for a second, you'll see that this is kind of like super wireframey.

135

And I basically had four different concepts on how to sort of like approach the problem we were

136

For each really I would kind of like label that concept

137

so give it a name which I think is really helpful

138

when you're in a discussion and you want to refer to a particular concept.

139

So in this one, this case it's called intent capture.

140

That was the name of the concept.

141

And then I sort of had like the user stories

142

and kind of like the persona

143

or like who we're kind of designing for just to kind

144

of like back up a little bit this sort of concept and this exploration.

145

For this one in particular I had like three different ideas within that concept.

146

And so I kind of labeled them like this down the side.

147

For the others, I kind of just had one.

148

Actually for this one, like I never actually ended up designing it.

149

I think sort of similar to what I was talking about with the other one.

150

Sometimes you can keep things like really high level and you don't need to design out, you know, full perfect flows and wireframes.

151

In this case, like we had this sort of shared language internally, everyone knew what I meant when I was talking about wallet first.

152

And so I didn't need to go and provide all of that extra like visual to support it.

153

This was enough, again, just to have that conversation

154

which out of these four concepts is sort of the direction we want to go in.

155

And so just keeping the fidelity to that level just to support that conversation, rather than like over designing it.

156

And you can see here in this case, I've also added some annotations underneath some of these screens.

157

We have these created at WellSimple as components.

158

I highly recommend creating some of those and having them really available to use in your design system.

159

It's going to make your workflow for this so much faster.

160

And so, yeah, this is like another look at how I've presented some different ideas.

161

For this last one, it's a little bit different.

162

It's less about sort of showing different explorations, but more around how I kind of show flows rather than like,

163

you know, one off screens with different ideas.

164

So in this case, I had some flows for this project and I kind of laid these out alongside the requirements.

165

So I find having product requirements really, really helpful as a designer because it kind of tells me exactly what the design is supposed to support.

166

I think this is a good example, actually, where we have this general requirement and then like within that is a few different priorities.

167

P0 means like we absolutely have to support this and we have to build this.

168

have any p1s but p1s and p2s are like nice to have

169

or like fast follows so i would have like the requirements

170

and then i would have the corresponding designs like as a flow next to it

171

and i found this really helpful particularly for people coming in

172

and like looking in my figma file on their own

173

because it would give them the context of like oh okay these are the things

174

that this flow is supporting and as you're looking at these flows like think to yourself is it meeting these

175

that's just a look at like how I've kind of laid out more flows rather than like individual screen explorations.

176

So as promised, as you just saw, that was a very messy, raw look at how I've sort of presented different explorations through different projects at two different companies.

177

And you can see that my process is not like fixed.

178

So as sort of mentioned in the beginning of this video, it really evolves and changes and adapts based on who the audience is,

179

based on level of confidence I have in my decisions and in my explorations.

180

some inspiration for how to try this with your projects and your team.

181

Have a wonderful week and I will see you next time.

182

Bye friend!

📺 Zelfde Kanaal

How to generate more UX design ideas with Crazy Eights

Business EnglishUniversity StudentsWorking Adults

✨ Aanbevolen Video

90 zinnen

Woordenschat en spreektips bij deze les

Deze spreekles op niveau B2 is gebaseerd op de video “How to organize and present your design explorations for feedback”. Deze woorden komen het vaakst terug: exploration, concept, project, design, ideas. Deze video bevat 182 zinnen en 2666 woorden om na te spreken. Het gesproken deel duurt 13:46. De spreker praat snel, ongeveer 194 woorden per minuut, dus reken op verbonden en ingeslikte klanken. 85% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden; de rest kun je beter vooraf bekijken.

Belangrijke woorden in deze video

De 15 moeilijkste woorden uit de video, met uitspraak en betekenis:

Woord	Uitspraak	Betekenis
exploration zelfstandig naamwoord	/ˌɛkspləˈɹeɪʃən/	verkenning, exploratie
rationale zelfstandig naamwoord	/ˌɹæʃ.əˈnæl/	ratio
widget zelfstandig naamwoord	/ˈwɪd͡ʒ.ɪt/	dingetje, prul
reviewer zelfstandig naamwoord		recensent
stakeholder zelfstandig naamwoord	/ˈsteɪkˌhəʊl.də/	belanghebbende
adapt werkwoord	/əˈdæpt/	aanpassen
recommendation zelfstandig naamwoord	/ˌɹɛkəmɛnˈdeɪʃən/	aanbeveling, recommandatie
jam zelfstandig naamwoord	/ˈd͡ʒæm/	confituur, jam
articulate werkwoord	/ɑːɹˈtɪk.jə.leɪt/	uitleggen
evolve werkwoord	/ɪˈvɑlv/	ontwikkelen
messy bijvoeglijk naamwoord	/ˈmɛsi/	wanordelijk, chaotisch
dive werkwoord	/daɪv/	duiken, onderwaterzwemmen
concise bijvoeglijk naamwoord	/kənˈsaɪs/	beknopt, bondig
infidelity zelfstandig naamwoord	/ˌɪnfɪˈdɛlɪti/	ontrouw
overwhelm werkwoord	/ˌoʊ.vɚˈwɛlm/	overweldigen, overmannen

Phrasal verbs die je zult horen

Woord	Uitspraak	Betekenis
write down werkwoord		opschrijven, neerschrijven
check out werkwoord		onderzoeken
back up werkwoord		teruggaan
end up werkwoord		belanden, terechtkomen
figure out werkwoord		uitvogelen, er achter komen
point out werkwoord		aanwijzen, aanduiden
touch up werkwoord	/ˈtʌt͡ʃ ʌp/	retoucheren

Grammatica in deze video

De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:

Structuur	In de video
Present perfect have/has + voltooid deelwoord — iets uit het verleden dat nu nog telt	I've laid · I've communicated · has evolved
Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet	be provided · is focused · been put

Uitspraak om op te letten

De spreker gebruikt 44 samentrekkingen en verkorte vormen, zoals you're, I've, I'm. Spreek ze kort uit, zoals je ze hoort.

De klanken “sh” en “zh”: exploration /ˌɛkspləˈɹeɪʃən/, rationale /ˌɹæʃ.əˈnæl/, recommendation /ˌɹɛkəmɛnˈdeɪʃən/, annotation /ˌæn.əˈteɪ.ʃən/, ideation /ˌaɪ.diˈeɪ.ʃən/
Lange woorden — let op de klemtoon: exploration /ˌɛkspləˈɹeɪʃən/, recommendation /ˌɹɛkəmɛnˈdeɪʃən/, articulate /ɑːɹˈtɪk.jə.leɪt/, annotation /ˌæn.əˈteɪ.ʃən/, confidently /ˈkɑnfɪdəntli/

Klanken die Nederlandstaligen lastig vinden:

Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: evolve /ɪˈvɑlv/, dive /daɪv/, correspond /ˌkoɹəˈspɑnd/, playground /ˈpleɪɡɹaʊnd/, rogue /ˈɹoʊɡ/
/æ/ — opener dan de Nederlandse “e”: rationale /ˌɹæʃ.əˈnæl/, adapt /əˈdæpt/, jam /ˈd͡ʒæm/, annotation /ˌæn.əˈteɪ.ʃən/, sandbox /ˈsæn(d).bɑks/
/g/ — een harde plofklank, geen Nederlandse “g”: playground /ˈpleɪɡɹaʊnd/, rogue /ˈɹoʊɡ/, organize /ˈɔɹɡənaɪz/

Zo oefen je met deze video

Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als exploration, rationale, widget.

Wat is de Shadowing-techniek?

Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.

Shadowing-techniek: lees de volledige stap-voor-stap-gids →

Shadowing Practice: How to organize and present your design explorations for feedback - Learn English Speaking with Video

How to generate more UX design ideas with Crazy Eights

If you’re an aspiring product designer, watch this (roadmap included)

How I Learned to Speak With More CLARITY - 7 Tips for Clear, Concise Speech

How to actually make eye-catching 3D Scenes | After Effects

Simon Sinek: Golden Circle Speech - TED Talk

Walk Me Through Your Resume: How to Answer

Figma Finally Launches Folders! + More New Updates

If I started a YouTube channel from scratch, I’d do this

How I Consistently Study with a Full Time Job: My Scheduling Formula

Dot Plots: How to Actually See What Your Users Are Doing

Design with Claude Code: The Designer’s Guide

DFM And DFA Explained

UI UX Interview Questions ( Part 1)