シャドーイング練習: 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 文

コンテキストと背景

この動画では、デザインのアイデアやコンセプトを効果的に整理し、フィードバックを受ける方法について説明しています。話者は、自分のFigmaファイル内に個人的なスペースを設け、新しいアイデアを探索しています。このプロセスは、デザインの初期段階で特に重要であり、製品マネージャーやエンジニアが異なるアイデアをレビューする際に、どのように整理された状態で情報を提供するかが鍵となります。

日常コミュニケーションのためのトップ5フレーズ

アイデアの探索: "私はアイデアの探索を行います。" - 新しいアイデアを模索する姿勢を示します。
状況設定: "プロジェクトの現状を説明します。" - 参加者に状況を明確に伝える重要性を強調します。
評価と推奨: "各コンセプトの利点と欠点について説明します。" - 各アイデアの評価を行うことが求められます。
ラショナル: "私の決定の背景を示します。" - 決定の理由を説明することで理解を深めます。
フィードバックの重要性: "フィードバックを通じて成長します。" - フィードバックの重要性を強調します。

ステップバイステップシャドーイングガイド

この動画で紹介された内容は、英語学習者がスピーキングスキルを向上させるための具体的な手法を提供しています。この内容を使って、shadow speakやshadow speechのテクニックを練習することができます。以下のステップを参考にしてください。

背景情報を確認する: 動画を観る前に、プロジェクトのコンセプトや目的を理解しておきましょう。
フレーズをシャドーイングする: 上記のフレーズを繰り返し、発音やリズムをマスターすることを目指します。
フィードバックを受ける: 他の学習者と一緒に練習し、互いにフィードバックを行いましょう。
コンセプトを整理する: 自分のアイデアを整理し、プレゼンテーションを実践してみます。
定期的に実践する: 継続的にこのプロセスを繰り返し、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

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

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

コンテキストと背景

日常コミュニケーションのためのトップ5フレーズ

ステップバイステップシャドーイングガイド

この動画の文法

シャドーイングとは？英語上達に効果的な理由