シャドーイング練習: 2026-05-05 Tufts Capstone project presentation - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

470 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

Hey everyone, thank you for joining us.

This is a presentation by the Tufts students who have been

working with a group of us on their capstone project for this year.

For a little bit of context, these are students who are working in,

I believe it's human computer psychology is the name of the course of study.

and they're doing a Capstone project where they're basically doing some user research and some UX design.

So they've been working really hard on this since January when their semester started, and they are excited to share all of this with everyone.

So they're going to walk us through their project presentation, and then we'll have a Q &A.

I have a notes doc.

I'm going to try to take notes as well as I can, but if questions come up for you, please drop them in the questions section,

and then we can get to hopefully all of them at the end of the presentation.

So with that, I'll turn it over to Ivy.

Are you able to share your screen?

Do I need to do anything?

I think you should be okay.

Yeah, I'll be sharing the presentation.

Cool.

Can you guys all see the slides?

Yes.

Perfect.

All right.

We'll get started then.

Thank you guys so much for joining.

So this is the Tufts and GitLab Capstone project presentation.

And this is the overview of Agenda for today. And I'm Ivy.

I'm the UX designer on the team.

Hi, everyone.

I'm Rihanna.

I'm one of the UX researchers.

Hi, guys.

I'm Chelsea, and I'm also a UX designer.

Hi, I'm Jack and I was also one of the UX researchers.

Cool.

Just to give some background on the timeline of our project, so we started our research process early in January and

that kind of carried over until February where we properly defined the problem for this project.

And then moving on to March, we ideated and and designed our design solutions as well as prototyping mid -five prototypes for user testing.

In April, we started our user testing.

So we did a round of concept testing, a second round of usability testing, and then finally we had a mock handoff session with GitLab engineers.

Lastly, so in May, it's our final deliverables and we have hi -fi prototypes and also presentations.

So just to get started on some of the prior research, when a new user gets invited to an organization instance GitLab,

there's no currently onboarding process that walks them through the platform's navigation.

Prior research from GitLab highlighted that the interface can be overwhelming for a first -time user

because it contains so many different functions.

Between the nested menus, hierarchical folder systems, and platform -specific terminology, navigation may not be very intuitive for all users,

especially if they're transitioning from a competitor with different information architecture.

So, to validate the problems from prior research, we ran a round of initial user interviews.

On the methodology side, we used a screener specifically to find people who are not already GitLab users

because we didn't want people who are already adapted to the interface.

So from there we built a structured interview script

and ran each participant through a mix of free exploration and guided task analysis inside a simulated GitLab environment.

That combination let us observe natural behavior while also probing specific scenarios.

Going into these interviews, we had three goals in mind.

First, we wanted to understand how first -time users actually onboard while observing their mental model.

Second, we wanted to understand pain points directly from observing their behavior while they navigated through the interface.

And third, we wanted to validate whether the terminology and hierarchy confusion we'd hypothesized before, specifically around the terminology with group and project,

was a common pain point and not just an edge case.

From doing these interviews, we took away first

that users had a hard time finding the issues assigned to them there's no obvious direct path

and as one participant stated in one of the interviews there's going to be some scrolling around

or you're going to have to search

and filter by a sign to me you have to fiddle around trying to find

that and that was a direct direct quote from one of them secondly participants felt

that a lot of important information was hidden behind submenus the information is there except

it's just not where people expect it to be Third, this one came up many times.

There's a mental model mismatch with GitLab.

There was a diverse spread of what the word project meant to each participant, while GitLab uses project to mean repository.

For example, one specific participant uses the word project to mean a task or initiative.

And more broadly, users coming from other tools found GitLab's terminology and interface unfamiliar.

A user that came from GitHub mentioned

that this is a drastically different user interface and it's something that you haven't explicitly taught me,

so I never would have been able to see it.

So that we developed our user persona.

This is Sasha, who is a staff software engineer focused on front end development.

Her main goals for onboarding to GitLab is to quickly understand how the platform is structured.

So to quickly understand the news platform development workflow and access the assigned repositories to start development.

Her main pain points are hidden or confusing navigation and a lack of onboarding guidance.

Sasha represents the larger GitLab software engineer user group.

Then we also conducted a competitor analysis to further understand tools

that users might transfer to GitLab from and their previous mental models.

Yeah, so in order to scope our problem down, we organized our initial takeaways into these four clusters of pain points.

The first cluster is the lack of discoverability.

The second cluster is unclear hierarchy.

Third cluster is navigation efficiency.

And the fourth cluster is mental model clash.

In terms of lack of discoverability, we found that a lot of the participants ran into issues around being able to easily locate different features

and also the issues assigned to them.

Around unclear hierarchy, participants had trouble understanding what it meant by group and project specifically and how that related to each other.

Around navigation efficiency, there were a lot of click depth throughout the interface

and they generally just wished for a better way of going back and forth between pages.

Lastly, in terms of mental model clash, when participants have prior experience in another platform

they run into issues recognizing these equivalences in gitlab specifically around different terminologies

so we moved forward with two areas of pain points specifically unclear hierarchy

and navigation and efficiency we prioritize these usability issues based on impact

and severity notably hierarchy issues are experienced by seven out of seven participants

and we also thought that solving problems around navigation would help issues around discoverability

and hence we proceeded on we proceeded on to these how might we statements

um finally we arrived at this problem statement

i am a software developer who has recently been invited to my organization's gitlab instance

i need to quickly get up to speed on my team's project

100

and begin completing tasks

101

but confusions around the platform's hierarchical structure make it difficult to understand where I am and how different levels relate, reducing my efficiency and confidence.

102

Moving into the ideation and testing phase,

103

the first thing that we did was create rapid wireframes based off of key pain points and our problem statement.

104

So each of us came up with eight wireframes and we compared the designs together.

105

The two design concepts that we decided to move forward with as a result of the crazy exercise were number one,

106

the breadcrumb drop down and number two, the sidebar swap.

107

So this is a little video showing what the breadcrumb drop down does.

108

Essentially, we wanted to address the hierarchical structure confusion by providing additional context

109

when users are exploring so that they can see how different levels relate.

110

It also helps clarify where they are in the structure

111

because icons in the breadcrumb and in the left navbar give visual anchoring.

112

This is design concept number two, the sidebar swap.

113

Similarly, it also provides additional textual information when swapping projects about siblings to explain how different levels relate when they're navigating.

114

It also helps to clarify where they are.

115

We've decided to keep the icons in the breadcrumb and also in the left navbar to provide visual anchoring as well.

116

So with those two designs, we decided to go ahead and do some user testing.

117

We conducted six moderated interviews with these mid -phi prototypes with the goal of increasing user confidence with navigating,

118

increasing effectiveness in understanding information hierarchy and just determining whether users found the navigation bar changes so our breadcrumb and sidebar swap

119

were familiar and aligned with their expectations

120

sorry um so we found

121

that four out of six of our participants preferred concept number two in general they found

122

that the second design is more easy to understand and it gives more information about related projects.

123

They also felt that the titles sibling projects and sibling groups provided clarity, so having that textual reference.

124

And then finally, another participant noted

125

that it's just more intuitive for them to click on project there and find their sibling projects within that structure.

126

So based off of those user interviews, we decided to move forward and make a couple of changes to our design.

127

A few of our participants noted

128

that their first instinct was not to click on the side swap menu to see if they can find siblings.

129

So in order to address that, we decided to add a tool tip that makes discoverability easier.

130

Second, we found that there was a little bit of UI confusion.

131

We had an icon on the first iteration that had like an upwards and a downwards arrow.

132

In our second design, we decided to swap it so that the arrow changes based on interaction state.

133

We also found that there was a bit of conflicting logic.

134

So there's a backslash here that we included in the side swap menu

135

and that conflicted with logic that they were applying based off of the breadcrumb that they normally saw in the original interface.

136

And so as a result of that,

137

we decided to just get rid of the backslash tulip or parent group and simplify it down to just sibling projects.

138

Then we also addressed edge cases.

139

So one of the participants noted that if you have a lot of projects, this side swap menu might cover up the entire left navigation bar.

140

So we decided to make a fixed size that only shows a max number of projects.

141

And we added a scroll feature and a view, sorry, we added a scroll feature and also a search projects tab for

142

if there's a lot of projects in the side swap.

143

So based on all of these findings, we moved on to a second round of user testing.

144

Going into this round, we had a few different goals in mind.

145

For example, because last round was just comparing different design concepts, because we decided to go with that sidebar swap.

146

We wanted to really compare it to the original GitLab interface.

147

So we did usability tests between our design and then that original GitLab interface.

148

This took course over five moderated interviews, where we also used different measures to compare them.

149

For example, task success rate, number of use errors, and also SEQ scores.

150

In addition to the goals that I just mentioned, there were a few other things we wanted to accomplish with this round.

151

The first was to test the addition of icons across the interface to see if that helped the users in any way.

152

Additionally, we wanted to test more of the user confidence while navigating, as well as the effectiveness in understanding the information hierarchy,

153

which we collected through qualitative metrics.

154

So based on those rounds of testings, we had a few positive outcomes.

155

The first was through efficiency.

156

We found that participants found the sidebar to be another way to navigate, and it was also more efficient in that it was less clicks

157

so that they were able to quickly get there rather than having to navigate through the breadcrumbs.

158

It seems like our design pretty aligned with user expectations.

159

For example, the tooltip was an indicator for them what they were supposed to do.

160

The navigation solely through the breadcrumbs didn't feel completely natural.

161

And they also were able to identify where they were in the hierarchy based on the naming conventions we use.

162

So for example, sibling projects.

163

And then also compared to the original interface, They talked about how the iconography we used made it more identifiable where they were.

164

And absent that, they were relying on things like the breadcrumbs or just the structure, which wasn't entirely intuitive.

165

So we did experience those positives in our second round.

166

Additionally, going into kind of those metrics I mentioned earlier,

167

for task completion rate, we did experience a 100 % task completion rate with minor error compared to the original interface.

168

With our design, there was only about one use error and

169

that was because the user initially relied on the previous navigation method so they had unfamiliar.

170

unfamiliarity with the drop down, which would improve with use.

171

In contrast, the original interface had a few more misclicks.

172

I think it was around three.

173

And the participants found that the breadcrumb was a little bit confusing

174

and they had to navigate through multiple levels in order to find the project they were looking for,

175

rather than just through clicking once to find their destination.

176

On the Likert scale rating, participants reported an average score of 4 .805,

177

which was much higher than compared to the original interface

178

and helped indicate that there was an improvement in efficiency and confidence in understanding their location within the structure.

179

And then for SEQ scores, our concept averaged 6 .47 out of 7 compared to 6 .13 out of 7 for the original interface.

180

So once again, this indicates that the participants found tasks easier when using our design,

181

and there was also an improvement in perceived task ease and overall usability.

182

Right, so then we arrived at our final design solution.

183

It's the Sideswap sibling navigator that clearly indicates the relationship between projects and groups to the user.

184

The drop down is activated on click as shown and users can scroll or search for the sibling item.

185

The tooltip also you saw appeared on hover so it explains the functionality of the drop down.

186

And in addition we kept those project and group icons in the breadcrumb

187

and on the left nav bar to highlight hierarchical information to users once more.

188

Cool.

189

So although our second round of testing validated our designs, there remained some challenges.

190

First of all, removing the parent page and returning only sibling projects

191

or groups as the drop -down heading sort of eliminated the visible parent -child relationship in the sidebar.

192

So users reported that they could only understand their position in the broader hierarchy, team, mostly through looking through the breadcrumbs.

193

And so we thought that maybe this was not the correct design move.

194

And even though the backslash wasn't the most correct logically, there still needs to be an indication of the parent group within that heading.

195

Secondly, so searching within a single level among siblings felt unintuitive for some participants.

196

And because it's a scope search, it's less natural than using the primary search bar in the main interface participants commented

197

that the search bar felt also cramped within the limited space of the interface.

198

Lastly, some participants expected a limited file tree in the sidebar navigator based on their prior experience with version control tools,

199

so that would allow them to understand the hierarchy at a glance rather than relying solely on lateral navigation across sibling items.

200

And after a mock handoff with engineers, we learned that the infinite scroll behavior in the site swap menu could create scalability concerns.

201

For projects with a large number of sibling items, the menu may require loading too much project data at once,

202

making the interaction more technically complex and potentially less efficient.

203

In order to address this new potential issue, we should consider other options in the side menu,

204

such as a C -more link or pagination to reduce initial loading.

205

Engineers also brought up potential confusion around where the ViewMy project leads.

206

users within the drop down so whether that leads to view all their sibling projects or view all of their project

207

yeah so based on of our based on our second round of user testing

208

and also the mock engineering handoff session

209

there are a few areas of clarity for our future direction obviously based on the timeline uh

210

we weren't able to like iterate further but these are just some ideas of where we would potentially take this project?

211

How do we have more time and resources?

212

So the first would be to test the scope search bar within the drop -down menu with a larger number of items.

213

It would be really important for us to understand whether users would still find it useful for locating items

214

or whether they would default back to the main global search bar.

215

Additionally, we would also evaluate different methods of sorting an organization within the drop -down.

216

So some of these options might take the form of frequently accessed

217

or recently searched or pin projects that may help users quickly switch between frequently used items as the list grows.

218

This is also something we did receive feedback for from our user testing.

219

Different users had different ideas of what they would want to see there, so that would be an area of further research.

220

Additionally, we would want to do more research in the expansion of functionality.

221

Currently, we are working within kind of that limited file tree hierarchy design,

222

but we would want to investigate whether expanding the structure and to include, for example, like.

223

one level above parent or one level below child would improve users understanding of the overall hierarchy.

224

It was also one of the key questions is determining kind of that optimal number of like visible hierarchy levels,

225

because we do want to maintain a balance of clarity with also simplicity so that the users are not overwhelmed.

226

To reflect on the semester as a whole, we got to experience the full design cycle on a real world problem from start to finish.

227

It's one thing to learn about research, ideation, and prototyping through classes or lecture, but to be hands -on,

228

it really gives you the full learning experience and that's what we got from this.

229

We gained a lot of experience in the research design area.

230

We wrote screeners, moderated live sessions, and translated user feedback into actionable items.

231

And lastly, the engineering session pushed us to think about our design in a different light.

232

We got to hear different perspectives, test our prototype against the design system, and confront technical feasibility, and that just improved our design that much better.

233

Overall, this project made us all better researchers, designers, and collaborators.

234

And lastly, we want to thank our sponsors

235

Chad, Katie, Bindu, Lorena, and Erhan for their support throughout the entire process.

236

Well, thank you.

237

So any any questions, Robert?

238

I see you're typing something.

239

Would you like to verbalize it and I can I can type it out?

240

I was just complimenting them that they did a great job on the project and the presentation. So congratulations.

241

Thank you.

242

Yeah.

243

Valerie, same question to you.

244

I see you're right.

245

Yeah, if you can help me type, I'd appreciate it.

246

Agree, great presentation.

247

This is one of our biggest problems.

248

We hear pretty consistently that our customers have a really hard time understanding our product hierarchy.

249

This is just a massive problem.

250

Really appreciate you digging into it and exploring those UI variations.

251

I'm curious, when you were doing the first and second round of testing, I might have missed it,

252

but were you able to,

253

were some of the questions that were asked to confirm that there was better understanding between groups and projects,

254

or were the studies mostly focused on the UI itself?

255

Yeah, so we asked follow -up questions in both round of testings, and they were based on Likert scale ratings.

256

And obviously, as we mentioned, a lot of it was around confidence,

257

but we had a specific question on whether one design helped them learn the differences between project slash group. So, yes.

258

Great.

259

That's really my question, because that's been one of the things

260

that we've been trying to figure out we go through this pattern where we change the UI

261

and at some point there's a root cause.

262

And so I didn't know if you also did.

263

I guess my next question is, were there any explorations that were tied to root cause versus,

264

okay, we know that this is going to be the product hierarchy, so how are we going to help people within the product?

265

You mean like the differentiation between a root cause?

266

Sorry, could you just clarify that again?

267

I didn't ask it well.

268

So were there any explorations into root cause?

269

Meaning if the initial research showed there's confusion.

270

So for example, customers coming from GitHub or other products coming into GitLab.

271

And because GitLab terminology is different, because we use groups and projects and we use them differently than any other tool,

272

a root cause could be that our hierarchy needs to change.

273

So instead of 100 % focusing on how can the UI change to help them understand the difference between that,

274

was there any exploration that was tied to, hey, maybe we should revisit our actual product hierarchy.

275

So that's the question.

276

Were there any explorations around addressing, like maybe we should change our product hierarchy?

277

Yeah, I think that that is less probably in the scope of our project and

278

um i guess instead of looking into the root cause we were focusing more on validating this problem initially

279

and i think throughout the interviews that it was kind of apparent to us

280

that people were able to understand it but it's mostly the lack of ux

281

that made them made

282

it harder for them to understand instead of the structure itself being super confusing to start with okay thank you Thanks.

283

Any other questions, comments?

284

I'll keep going.

285

Sure.

286

Good for you.

287

So one of the things that was mentioned earlier in the presentation was onboarding.

288

Were there any other aspects that you all explored to improve the onboarding process?

289

One aspect that we didn't really end up digging into was like the sign up flow.

290

Our first round of like initial interviews explored like the full onboarding process.

291

So what does it look like when a user just gets invited into an organization's instance?

292

And then, yeah, what does it look like from their side?

293

I think one of the small things that we got out of

294

that was there was a little bit of confusion about when you select the role.

295

Like, are you a software engineer or are you a project manager?

296

A few comments were made about like, what does that change for the interface?

297

Like what impact does role selection actually have on their experience?

298

But we decided to like pivot and center our project on more of the interface itself rather than the signup flow.

299

yeah and I guess on top of

300

that we were looking into like onboarded uh onboarding like tutorials initially as well

301

because like I guess the most obvious problem on the surface is

302

that there is not a walkthrough of things for example there is no like a guided tour

303

that some of our interviewees actually like explicitly stated

304

that it would be helpful for them

305

but I think we ended up trying to solve a different problem than providing just a simple like guided tour.

306

Yeah, it makes sense.

307

Thank you.

308

Thanks.

309

Any other questions, comments that aren't in the agenda?

310

I'll ask a question just from the perspective of you kind

311

of like each one of you kind of took a role within the team of like a UX researcher,

312

designer, I missed the other two, but now

313

that you've gone through the whole process of going through this

314

project getting some real world experience do you still hold true to those roles

315

that you kind of played out in this scenario or

316

there are new interests that might have developed over the course of this project?

317

I think that to begin with, we all sort of wore many hats for this project.

318

So although like

319

Ivy and I had were like defined roles as UX designer, I think that we also definitely had a hand in research.

320

And the same really goes for our UX researchers, like all of us were doing that crazy exercise where we were creating wireframes.

321

So I think that our roles bled into each other a little bit

322

and I was personally able to find like all of it quite interesting.

323

I think I would be excited to do more work in either design or research as well in the future.

324

I think our group did a good job of being really collaborative and working well with each other.

325

So we bounced a lot of ideas off of each other.

326

So like, yeah, like Chelsea said, our roles as researcher designer wasn't very concrete.

327

I wouldn't say I have the most high Figma experience, but I got to watch Chelsea and Ivy design.

328

So I learned a few things doing that as well.

329

I would say for me personally, like, I kind of knew what I was interested in kind of like in the industry going into it,

330

which was the research part and I think doing this project kind of validated that for me.

331

There are a few areas

332

that like I think are outside of the scope of the project that I would be interested in.

333

For example, I am a pre -law student

334

so perhaps some of like the legal side of things

335

or like patent could be potentially interesting

336

but I think within this project I definitely got to explore kind of the areas that already interested me personally.

337

Yeah, I would say I came into the project thinking that I inclined more towards design,

338

but I'm like realizing how much design and research tie into each other and play hand in hand.

339

So I think it's important for a designer to have a very solid research basis

340

and supporting their design using just like data to be able to justify design decisions.

341

So I really think that like being able to do both research

342

and design work is something that I want to be able to do in the future.

343

Danica, would you like me to type out as you'd replies?

344

Sure.

345

I'm curious if there was anything that surprised you about working with GitLab, whether it was the product itself or maybe our team as well.

346

Yeah.

347

I think in terms of the product, like definitely it was a challenge to work with a product

348

that has so many different functionalities to start with

349

and a very highly technical product like all four of us

350

came into the project not having any sort of background in development

351

and software engineering

352

so it was definitely a challenge just to get familiar with the tool to start off with I think

353

it's probably the most important to be able to understand the product before you do any research and design around it.

354

So that was probably like the biggest surprise or challenge, at least for me.

355

I think we're all a little surprised about kind of the structure of the GitLab team.

356

I mean, everyone's so like spread out that like when we were figuring out our meeting,

357

we were actually quite impressed with kind of like everyone's perspective and where everyone was coming from.

358

I think we also were quite humbled by like the fact

359

that so many people were coming to our weekly meetings every week.

360

I mean, to us, it's our little capstone project.

361

So we're quite thankful

362

that we have the support of the GitLab team who are

363

constantly zooming in from all parts of the world to like share their feedback.

364

So that was really, we really appreciated that.

365

I was also very impressed about like how on time, time efficient you guys were,

366

because we would have like our script for our interviews ready

367

or like an idea of what we wanted to interview

368

and then the next week you guys would have like seven participants ready for us

369

and so I think

370

that allowed us to stay on task of the research process

371

rather than get distracted with like trying to recruit a bunch of participants

372

so I'm very grateful that that was like something we didn't have to do.

373

And if I can interject, huge shout out to Kate on the experience research team.

374

She is the one who did all of that hard work to get us participants for those.

375

She was really crucial in this.

376

Sorry, this is a question to you all.

377

Any other questions or feedback?

378

Well, I'd like to say I think you did an excellent job.

379

This is one of our toughest challenges and a recurring hot topic, shall we say.

380

I think part of the reason that it's in the state that it is, is not just because it's difficult at a user experience level.

381

It's also a challenge simply from the technical side of things.

382

It's one where it goes beyond logic

383

and ends up being fraught with a whole other thing that you don't have to experience,

384

which is politics and it may seem silly from the outside, which it also seems silly from the inside,

385

that that even becomes a factor.

386

But as you work your way into the industry, you'll discover that logic isn't always the thing that makes the decisions,

387

but the way that you position yourself, your team, and how others position theirs,

388

oftentimes is what dictates the roadmap or the priorities of what eventually ends up in the product.

389

And those decisions end up having ripple effects for years.

390

And so that's one of the waves

391

that you got to ride during the course of this project and something that we're still,

392

as you can tell, rowing against and trying to reel ourselves back in.

393

So you got to see one of the very, very toughest real -world challenges.

394

And you weathered that storm perfectly and came up with excellent recommendations.

395

So congratulations on that.

396

Thank you so much.

397

I have a follow -up on that actually.

398

I'm curious in GitLab, how does a design lifecycle look like?

399

How long does it take for something to get pushed through and actually be implemented?

400

Val?

401

I knew you were going to toss it over here.

402

It varies.

403

I'm going to give the worst answer.

404

It depends.

405

It depends on scope.

406

And then it also depends on our individual skill set.

407

So I'm very blessed to have a team of designers who can also code.

408

And we work at a company who encourages us, or who, I guess, GitLab is not a person.

409

But anyway, we are encouraged to ship code.

410

And so we can create an MR and make a change in the product directly.

411

Now, our capabilities are going to be limited to what it is that we feel comfortable and safe to make changes with.

412

But so if it's smaller, copy change, maybe you swap out a button, we participate in migration, component migration days, things like that.

413

So we can make the changes ourselves or if they're much larger and they'll require like backend support and things like that,

414

then it's going to take a little bit longer because we need to engage our cross -functional peers.

415

And then it gets into that,

416

what Jonah was mentioning, the prioritization and justifying the changes and then actually getting the work through.

417

So I would say from a couple of hours to weeks,

418

months, sometimes years, depending on the political aspect.

419

Yeah, it's where the change or the need is coming from.

420

So the idea of not invented here very much comes into play.

421

If it's an engineer's idea, it may already actually be built and just look terrible,

422

in which case we get to do the lipstick on the pig, which is the least glamorous job that you can possibly have

423

and you can argue against it all you want but it's a reality

424

and then there are you know great ideas

425

that can be had outside of that that could you know be readily accepted

426

and go straight into production because it's the best idea in the world

427

and it is just simply hit a lucky streak

428

and you ship it and everybody celebrates and you're the greatest thing

429

and the greatest thing that ever lived or it can be a fantastic idea

430

and somebody just doesn't like the way you presented it.

431

And it can languish.

432

So your mileage may vary.

433

So the way that you present, the way that you come across to people, the way that you present,

434

you think through the arguments that you may get, you think about the rude cues,

435

is the way that we phrase it, is very important.

436

I will approach things as if I am presenting a legal case as much as anything else.

437

So that type of mindset kind of comes along with the territory as you work your way up in the design world.

438

It's what precedents are out there that I can establish?

439

How can I bring as much logic to this as possible?

440

The psychology angle, if that's, you know, I think that's part of the classes that you're in.

441

That is one of the better ones to be able to

442

walk in the door with is the quantifiable proof of the psychology

443

that you are that you're bringing into that conversation

444

because that's an area

445

that you will most likely not have have thrown back at you right

446

there probably isn't somebody else in the room who has

447

that same background so that'll give you an upper hand in the way that you conduct your negotiations.

448

Yeah, so much of design is sales, right?

449

So if you got an idea and you put together the solution, then you have to be the biggest advocate for it.

450

And you're doing it on behalf of a great cause, which is the end user.

451

And so there's something really rewarding in that.

452

But it is up to you as a designer or a researcher or a combination to carry it forward.

453

And that's the hardest part.

454

That's the slowest part is because sometimes not everybody is going to get

455

that you have this really good idea and you have this data

456

that supports that it's going to solve things like real customer problems.

457

And you have to overcome that.

458

Thank you guys for sharing.

459

all right thank you everyone um unless we have any other questions or comments, we can wrap it up.

460

I would also like to thank the mentors who were with the students this semester.

461

Bindu, Aaron, Katie, Lorena.

462

Kate, as I said, was a huge help on the experience research side.

463

And our engineers as well who helped us out, Buck and Kushal and Constantine.

464

It takes a village kind of thing and I appreciate that you all came to support the students in this work.

465

and also thanks to all of you as Jack mentioned we're all over the place in the globe

466

and we are busy with a lot of work to do

467

so I appreciate you taking some time to hear these students out give them your feedback on all of this

468

so thanks so much everybody

469

and I'll share this recording as well awesome thank you thank you see y 'all thank you thanks everybody thanks everyone

470

Thank you.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

このレッスンの語彙とスピーキングのポイント

このスピーキングレッスンは、動画「2026-05-05 Tufts Capstone project presentation」を教材にしています。繰り返し出てくる語は次のとおりです：project, user, design。この動画には、シャドーイング用の文が470文、単語が6082語あります。音声の長さは40:33です。話す速さは1分あたり約150語で、日常会話に近い自然なペースです。単語の83%は英語の頻出3,000語に含まれます。残りは練習の前に確認しておきましょう。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
participant 名詞	/pɑːɹˈtɪsəpənt/	参加者, 関与者
interface 名詞	/ˈɪn(t)ɚˌfeɪs/	インターフェース
hierarchy 名詞	/ˈhaɪ.ə.ɹɑː(ɹ).ki/	階層, 序列
sibling 名詞	/ˈsɪb.lɪŋ/	兄弟兄弟姉妹, 同胞
navigation 名詞	/nævɪˈɡeɪʃən/	ナビゲーション, 航法
swap 動詞	/ˈswɑp/	取り替える, 交換する
designer 名詞	/dɪˈzaɪnɚ/	デザイナー, 設計士
presentation 名詞	/ˌpɹɛzn̩ˈteɪʃn̩/	贈呈
menu 名詞	/ˈmɛn.juː/	メニュー, お品書き
researcher 名詞	/ˈɹiˌsɝ.t͡ʃɚ/	研究員, 研究者
efficiency 名詞	/ɪˈfɪʃ.ən.si/	効率性, 効率
confusion 名詞	/kənˈfjuːʒən/	混乱
feedback 名詞	/ˈfiːdˌbæk/	フィードバック, 反応
explore 動詞	/ɪkˈsploɹ/	探検する
exploration 名詞	/ˌɛkspləˈɹeɪʃən/	探検, 探査

動画に出てくる句動詞

単語	発音	意味
bring up 動詞		育てる
come up 動詞		上がる, 登る
go ahead 動詞	/ˌɡoʊ əˈhɛd/	どうぞお先に
go back 動詞		戻る, 帰る

繰り返し練習したい文

動画に出てくる短く完結した文です。日常会話でそのまま使えます。

Are you able to share your screen?
Do I need to do anything?
Can you guys all see the slides?
How do we have more time and resources?
You mean like the differentiation between a root cause?

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
現在完了進行形 have/has been + -ing — 以前に始まり今も続いている動作	they've been working · we've been trying
条件文 if + 節, will/would + 動詞 — 条件とその結果	if you can help me type, I'd appreciate · if they're much larger and they'll require
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	are already adapted · was hidden · is structured
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	have been · haven't explicitly taught · has recently been invited

注意したい発音

話し手はI'm, you're, didn'tなど、短縮形や弱形を67回使っています。聞こえたとおりの短い形で発音しましょう。

「sh」と「zh」の音: navigation /nævɪˈɡeɪʃən/, presentation /ˌpɹɛzn̩ˈteɪʃn̩/, efficiency /ɪˈfɪʃ.ən.si/, confusion /kənˈfjuːʒən/, exploration /ˌɛkspləˈɹeɪʃən/
長い単語（アクセントの位置に注意）: participant /pɑːɹˈtɪsəpənt/, hierarchy /ˈhaɪ.ə.ɹɑː(ɹ).ki/, navigation /nævɪˈɡeɪʃən/, efficiency /ɪˈfɪʃ.ən.si/, exploration /ˌɛkspləˈɹeɪʃən/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: explore /ɪkˈsploɹ/, exploration /ˌɛkspləˈɹeɪʃən/, scroll /skɹoʊl/, relate /ɹɪˈleɪt/, clarity /ˈklæɹ.ɪ.ti/
/v/ — /b/ にならないように、上の歯を下唇に当てる: navigation /nævɪˈɡeɪʃən/, navigate /ˈnæv.ɪ.ɡeɪt/, intuitive /ɪnˈtjuːɪtɪv/, solve /sɒlv/, visible /ˈvɪzɪb(ə)l/
/f/ — 「フ」ではなく、上の歯と下唇で出す: interface /ˈɪn(t)ɚˌfeɪs/, efficiency /ɪˈfɪʃ.ən.si/, confusion /kənˈfjuːʒən/, feedback /ˈfiːdˌbæk/, efficient /ɪˈfɪʃənt/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。participant, interface, hierarchyなどの単語に特に注意しましょう。

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

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: 2026-05-05 Tufts Capstone project presentation - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Sec Growth DataScience staff meeting Sep 14 2022

2022-07-25 Analytics Section Meeting

[REC] Key Meeting - Engineering (Public Stream)

Product Marketing Meeting (weekly) 2021-06-28

おすすめ動画

LTEC 782: Design-Based Research in Education (Session 01)

How We Incorporate Patient Priorities Care into Our Clinical Pharmacy Practices

The UX Psychology Behind Apps People Can’t Stop Using

We Let $200 GPT-Pro Think for 7 Days on Unsolved Math

My script presentation

Is AI Killing Human Fashion Design? Who Will Shape the Future of Design? Fashion Tea #6

Listening Test 1. Part 3: Jess and Tom art project.

Architectural Design Process Explained

Trust the Process: How to Design Teams That Actually Work

How Anthropic uses Claude in Product Management

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

MIT Introduction to Deep Learning | 6.S191

このレッスンの語彙とスピーキングのポイント

この動画の重要語彙

動画に出てくる句動詞

繰り返し練習したい文

この動画の文法

注意したい発音

この動画での練習方法

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