跟读练习: 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 句

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

Business EnglishInterview EnglishUniversity Students

155 句

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

Business EnglishUniversity StudentsWorking Adults

148 句

Mastering Meetings and Presentations: A Comprehensive Guide to Effective Communication

Business EnglishUniversity StudentsWorking Adults

112 句

为什么用这个视频练习口语？

在进行设计探索和获取反馈的过程中，有效的沟通能力显得尤为重要。如果你希望提升自己的英语口语水平，并能够自信地分享你的想法，这个视频是一个很好的练习材料。通过模仿视频中的演讲者，你不仅能提高口语流利度，还能学习如何明确地表达自己的设计思路和逻辑。这样的实践能帮助你更好地适应真实的沟通环境，尤其是在设计评审或者团队讨论时，使用shadowspeak的技巧，可以让你的表达更加自然与专业。

语法与表达在上下文中的运用

使用条件句: 演讲者提到“如果你像我一样...”，这种句型用于条件状况的表达，帮助听众理解特定语境下的想法。
展示因果关系: 如“因为……所以……”的表达，强调设计决策的理由，帮助听众理解背后的逻辑。
列举和对比: 使用“我可能会谈论……以及……”的句式，展示不同概念的优缺点，增加了表达的丰富性和层次感。
时间表达: “在设计过程的第一部分”，精准的时间表达有助于定位讨论的阶段，增强沟通的有效性。

常见的发音陷阱

在视频中，有些单词和短语可能会让英语学习者感到困惑，特别是在快速对话中。例如，“concepts”和“rationale”的发音，有时会因为音节的重音问题而导致误解。在练习时，可以借助shadow speech的方式，逐字逐句跟读演讲者的发音，帮助纠正自己的发音习惯。同时，对一些具有不同口音的单词进行反复练习，可以提升你的听力和理解能力，增强口语表达的流利度。

视频中的语法

说话人最常用的结构，并附上视频中的原话：

结构	视频中的用法
现在完成时 have/has + 过去分词 — 过去发生但与现在仍有关联的事	I've laid · I've communicated · has evolved
被动语态 be + 过去分词 — 强调发生了什么，而不是谁做的	be provided · is focused · been put

什么是跟读法？

跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。

影子跟读法: 阅读完整分步指南 →

跟读练习: 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)

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

Mastering Meetings and Presentations: A Comprehensive Guide to Effective Communication

How To Edit Videos Viewers Will Watch To The END.

Googleyness and Leadership Interview Question

What do Design Managers do?

Claude Design is Insanely Easy (even for beginners)

DFM And DFA Explained

UI UX Interview Questions ( Part 1)

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

Learn UX Storyboarding in 5 Minutes: w/ Steps and Examples | UXtweak

Research Foundations: How to Turn Business Problems into Actionable Data

为什么用这个视频练习口语？

语法与表达在上下文中的运用

常见的发音陷阱

视频中的语法

什么是跟读法？