쉐도잉 연습: How to organize and present your design explorations for feedback - 영상으로 영어 말하기 배우기

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!

📺 같은 채널

How to generate more UX design ideas with Crazy Eights

Business EnglishUniversity StudentsWorking Adults

✨ 추천 영상

90 문장

How to Start a Professional Presentation in English | Real Business Meeting Listening & Speaking

Business EnglishInterview EnglishUniversity Students

236 문장

Human Design 2/5 Profile Explained (Hermit / Heretic)

Business EnglishUniversity StudentsWorking Adults

18 문장

UI UX Interview Questions ( Part 1)

Business EnglishInterview EnglishUniversity Students

236 문장

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

Business EnglishUniversity StudentsWorking Adults

이 수업에 대하여

이 영상에서는 디자인 탐색을 정리하고 피드백을 받기 위해 효과적으로 발표하는 방법을 다룹니다. 영어를 배우는 학생들은 다양한 디자인 개념과 아이디어를 제시하는 상황에서 필요한 언어와 표현을 익히게 됩니다. 특히 비즈니스 커뮤니케이션에서 중요한 발표 능력을 기를 수 있으며, 이를 통해 영어 발음 교정에도 도움을 줄 수 있습니다. 이 영상의 내용을 통해 적절한 문맥을 제공하고, 개념을 명확히 전달하는 연습할 수 있을 것입니다.

주요 어휘 및 구문

exploration - 탐색
context - 맥락
rationale - 근거
concept - 개념
feedback - 피드백
design review - 디자인 리뷰
milestones - 이정표
stakeholders - 이해관계자

연습 팁

영상의 내용을 따라 연습할 때, shadow speak 기법을 활용해 보세요. 각 문장을 들으며 따라 하는 동안, 발음과 억양에 집중하고 shadowspeaks 방식으로 연습합니다. 이 과정에서는 특히 발음의 세기나 감정 표현을 주의 깊게 살펴보세요. 당신의 발음이 자연스러워질 때까지 반복하시고, 각 문장을 여러 번 듣고 따라 하면서 IELTS 스피킹 시험에서도 자신감을 가질 수 있습니다. 마지막으로, 필요한 경우 메모를 작성하여 각 표현의 의미와 사용법을 요약해보세요. 이렇게 하면 비즈니스 및 디자인 피드백 상황에서도 적절한 어휘를 사용할 수 있게 됩니다.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	I've laid · I've communicated · has evolved
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	be provided · is focused · been put

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: How to organize and present your design explorations for feedback - 영상으로 영어 말하기 배우기

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

Want To Make Your Ideas Stick? Make It Into A Meme!

How To Edit Videos Viewers Will Watch To The END.

How to Find Your Voice as a Fashion Designer

Walk Me Through Your Resume: How to Answer

Claude Design just got MASSIVE Upgrades (2.0 Update)

DFM And DFA Explained

How to Start a Professional Presentation in English | Real Business Meeting Listening & Speaking

Human Design 2/5 Profile Explained (Hermit / Heretic)

UI UX Interview Questions ( Part 1)

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

이 수업에 대하여

주요 어휘 및 구문

연습 팁

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법