Prática de Shadowing: How to organize and present your design explorations for feedback - Aprenda a falar inglês com vídeo

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!

📺 Mesmo canal

How to generate more UX design ideas with Crazy Eights

Business EnglishUniversity StudentsWorking Adults

✨ Vídeo recomendado

90 frases

Sobre Esta Lição

Nesta lição, você irá praticar habilidades de apresentação e comunicação em inglês, fundamentais para transmitir suas ideias de maneira clara e eficaz. Através do vídeo "Como organizar e apresentar suas explorações de design para feedback", você aprenderá a estruturar suas explorações e a contextualizar suas ideias para receber um retorno construtivo. Isso é especialmente útil para aqueles que desejam melhorar suas habilidades de apresentação e argumentação em inglês.

Vocabulário e Frases Chave

Explorações - Refere-se à exploração de diferentes ideias e conceitos durante o processo de design.
Contexto - Informações relevantes que ajudam os revisores a entenderem o que está sendo apresentado.
Raciocínio - Justificativas que explicam o porquê de determinadas decisões de design.
Solução Preferida - A proposta que o apresentador acredita ser a mais adequada após as explorações.
Revisão de Design - Uma apresentação onde as explorações são mostradas e o feedback é solicitado.
Proposta - Uma ideia ou conceito que está sendo considerado para desenvolvimento.
Feedback - O retorno dado sobre as propostas apresentadas, essencial para o aprimoramento das ideias.

Dicas de Prática

Para aproveitar ao máximo o vídeo e aprimorar suas habilidades em shadow speak e shadowing em inglês, siga estas dicas:

Escute com Atenção: Ouça o vídeo, prestando atenção à entonação e ritmo do falante. Tente imitar a maneira como ele apresenta os conceitos.
Pratique o Shadowing: Pause o vídeo em partes estratégicas e repita o que foi dito, tentando não apenas repetir as palavras, mas também capturar o tom e a fluência.
Contextualize suas Ideias: Ao apresentar suas próprias explorações, lembre-se de dar contexto às suas ideias, assim como no vídeo. Isso ajudará a tornar sua comunicação mais eficiente.
Documente seu Raciocínio: Pratique não apenas falar, mas também articular seu raciocínio de forma estruturada. Ao compartilhar suas ideias, explique o porquê por trás de cada uma.
Participe de Feedbacks: Convide amigos ou colegas para assistir às suas apresentações e solicite feedback. Isso simulando uma revisão de design e permitindo que você receba críticas construtivas.

Ao adotar essas estratégias, você poderá aprimorar seu inglês de forma eficaz, desejando assim se destacar na comunicação, seja em reuniões de design ou em qualquer outra situação que exija clareza e coerência. Não se esqueça de aplicar estes métodos em suas práticas de shadow speak e compartilhar suas experiências!

Gramática neste vídeo

As estruturas que o falante mais usa, com as palavras exatas do vídeo:

Estrutura	No vídeo
Present perfect have/has + particípio passado — uma ação passada que ainda importa agora	I've laid · I've communicated · has evolved
Voz passiva be + particípio passado — o foco está no que acontece, não em quem faz	be provided · is focused · been put

O que é a Técnica de Shadowing?

Shadowing é uma técnica de aprendizado de idiomas com base científica, originalmente desenvolvida para o treinamento de intérpretes profissionais. O método é simples, mas poderoso: você ouve áudio em inglês nativo e repete imediatamente em voz alta — como uma sombra seguindo o falante com 1-2 segundos de atraso. Pesquisas mostram melhora significativa na precisão da pronúncia, entonação, ritmo, sons conectados, compreensão auditiva e fluência na fala.

Técnica de shadowing: leia o guia completo passo a passo →

Prática de Shadowing: How to organize and present your design explorations for feedback - Aprenda a falar inglês com vídeo

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)

Sobre Esta Lição

Vocabulário e Frases Chave

Dicas de Prática

Gramática neste vídeo

O que é a Técnica de Shadowing?