
Korean: 
안녕하세요, 전 크리스입니다
UX 디자인 기획을 맡고 있죠
전 프리티입니다
UX 연구자예요
오늘 저희는 여러분이 존재하는지도
몰랐을 한 팀에 대해 얘기할까 합니다
저희가 속한 팀은 
Android 개발자 UX팀인데
줄여서 ADUX라고 부르죠
귀여운 마스코트도 있습니다
저희 팀이 하는 일을 설명할 텐데
기능에 대한 이야기로
시작해 볼까 합니다
Android 스튜디오에 있는
모든 주요 기능은
우리가 '라이브 오브 기능'이라고
부르는 과정을 거칩니다
오늘은 Navigation Editor에 대해
간략하게 언급하면서
이 과정이 어떻게 
이루어지는지 말씀드리겠습니다
우선 이 과정은 다섯 단계로 나뉩니다
검색, 탐색, 정교화,
마무리, 제공 순이죠
소프트웨어 개발이 다 그렇듯
항상 이 순서대로 가는 건 아니지만
단계를 구분해 놓으면
주요 순간을 구체화하는 데 도움이 되죠

Spanish: 
Hola, me llamo Chris.
Soy director de diseño de UX.
Yo me llamo Preethi.
Soy investigadora de UX.
Estamos aquí
para hablarles de un equipo
que quizás no conozcan.
Integramos el equipo Android Developer UX,
o ADUX. Esta es nuestra adorable mascota.
Hoy les hablaremos de nuestro trabajo.
Creo que la mejor manera de hacerlo
es mediante la historia de una función.
Cada área de funciones
importante de Android Studio
pasa por lo que llamamos
el proceso de vida de una función.
Les contaremos una historia
sobre el editor de navegación
y cómo fue su proceso.
El proceso tiene cinco etapas:
descubrimiento, exploración,
perfeccionamiento, finalización y envío.
Como saben, en el desarrollo de software,
las etapas no son tan lineales,
pero ayudan a organizar
los momentos clave del proceso.
Para el editor de navegación,
estos fueron los momentos clave
de la producción de la función.

Japanese: 
[音楽]
こんにちは クリスです
UXデザインのリーダーをしています
プリティです
UXの研究者です
今日は皆さんにチームの
お話をするためにきました
私たちはAndroid開発者UXチームです
略してADUX 可愛いマスコットもいます
今日は私たちの仕事について話します
機能についてお話しする
素晴らしい機会です
Android Studioの
主要な機能分野は
機能のライフプロセスを経ます
今日はNavigation Editorに
ついてと
そのプロセスの仕組みについて
簡単に説明します
このプロセスには５つのフェーズがあります
発見 調査 改善 完成 出荷です
ご存知のようにソフトウェア開発では
物事は必ずしも直線的ではありません
しかしこれらのフェーズは行程の
重要な場面を整理するのに役立ちます
Navigation Editorにとって
機能の制作における重要な機会でした

English: 
[MUSIC PLAYING]
CHRIS SINCO: Hi, I'm Chris.
I'm a UX design lead.
PREETHI SRINIVAS:
And I'm Preethi.
I'm a UX researcher.
CHRIS SINCO: And
we're here today
to talk to you about a team
you may not know existed.
So we're from the
Android Developer UX
team, or ADUX for short
with our lovely mascot.
We're here today to
talk about what we do.
And I think this is best
told through a story
about a feature.
So every major feature
area in Android Studio
goes through what we call the
life of a feature process.
And today, we're
going to briefly share
a story about the
Navigation Editor
and how that process
worked with that.
So there are five
phases to this process--
discover, explore, refine,
finalize, and ship.
Of course, things
are not always linear
as you know with
software development,
but they do help organize the
key moments in the journey.
So for the Navigation
Editor, these
were kind of the key moments in
the production of the feature.

Indonesian: 
Hai, saya Chris.
Saya kepala bidang
desain UX.
Hari ini kami
akan membahas tim
yang tak banyak orang tahu.
Kami dari tim
Android Developer UX
atau ADUX, perkenalkan maskot kami.
Kami akan perkenalkan
pekerjaan kami.
Sepertinya lebih baik
dibahas lewat cerita
tentang sebuah fitur.
Setiap fitur utama
di Android Studio
melalui proses yang
disebut siklus fitur.
Kali ini, kami akan
membahas singkat
Navigation Editor
dan bagaimana proses
itu berjalan dengannya.
Ada lima langkah
dalam proses ini:
penemuan, pencarian, penyempurnaan,
penyelesaian, dan pengemasan.
Tidak selalu berurutan, sama seperti
pengembangan
software pada umumnya,
tapi semua langkah membantu 
mengatur tahap penting di setiap alurnya.
Di Navigation Editor,
semua ini merupakan
tahap penting dalam pembuatan fitur.

Portuguese: 
Olá, meu nome é Chris.
Sou líder de design de UX.
Meu nome é Preethi,
sou pesquisadora de UX.
Estamos aqui hoje
para falar sobre uma equipe
que talvez você não saiba que exista.
Somos da equipe de UX
de desenvolvedores Android,
ou ADUX,
e este é nosso adorável mascote.
Estamos aqui
para falar sobre o que fazemos.
Acho que a melhor forma de fazer isso
é contando a história de um recurso.
As principais áreas
de recursos do Android Studio
passam pelo processo
que chamamos de vida do recurso.
Hoje contaremos uma história
sobre o editor de navegação
e como ele passou por esse processo.
Há cinco fases nesse processo:
Descobrir, explorar,
refinar, finalizar e entregar.
Claro, nem tudo é sempre linear
no desenvolvimento de software,
como você sabe,
mas elas ajudam a organizar
os principais momentos da jornada.
No editor de navegação,

Chinese: 
[音乐]
大家好，我是Chris
现为用户体验设计主管
我是Preethi
现为用户体验研究员
今天，我们将向您讲述
一支您可能从未听说过的团队
我们来自Android开发者用户体验团队
简称为ADUX
这是我们可爱的吉祥物
我们今天想要谈谈我们的工作内容
我觉得通过功能故事来讲述
大家会更容易理解
Android Studio中的每一项主要功能
都会经历一个流程
我们称之为功能生命周期
今天，我们将简单分享
Navigation Editor的故事
以及流程是如何进行的
这一流程分为五个阶段
分别为发现、探索、改进、敲定和发布
当然，软件开发过程
并非总是呈线性发展
但这些阶段确实有助于
厘清这一过程中的关键时刻
对于Navigation Editor
这些阶段就是构建该功能的关键时刻

Indonesian: 
Kami akan membahasnya
lebih dalam satu per satu.
Pada tahap penemuan,
pertama-tama, kami harus
mengenali pengguna dan kebutuhannya.
Kuncinya adalah fokus
pada tujuan pengguna
dan tugas utama yang
dibutuhkan untuk mencapainya.
Salah satu metode kami
adalah membuat
cerita pengguna berisi
bagian-bagian kosong seperti berikut
"Sebagai developer, saya
ingin .... agar bisa .... ."
Dalam konteks Nav Editor,
kami bilang "Sebagai developer, saya
tak ingin terlalu banyak
mengurusi kode boilerplate
agar bisa fokus
ke alur aplikasi saya."
PREETHI SRINIVAS: Dan
kebetulan, kutipan ini
kami peroleh dari salah satu
studi pengguna kami.
CHRIS SINCO: Benar sekali.
Dalam waktu yang sama, kami
juga menilai alur kerja yang
saat ini sedang diterapkan
untuk lebih memahami
kelemahan dan peluang yang ada.
Dalam hal ini untuk
membuat navigasi aplikasi.
Setelah menentukan
kebutuhan pengguna dan
memenuhi sejumlah syarat,
kami harus mencari solusi tertentu.

English: 
And we'll walk through each of
these in a little more detail.
So for the discover
phase, we have
to first figure out who is the
user and what do they need.
And the key here is to really
focus more on the user's goals
and the high-level tasks needed
for them to achieve them.
So one of the great thinking
tools we use is to generate
user stories with this
fill-in-the-blank statement,
which is "as a developer, I want
to blank, so that I may blank."
In the context of Nav Editor,
we said, as a developer,
I want to write less
boilerplate code,
so I may focus on
the flows of my app.
PREETHI SRINIVAS: And
coincidentally, this
was actually one of
the quotes we heard
in one of the user studies.
CHRIS SINCO: Yep, exactly.
At the same time, we also
assess the current workflows
that people go through
to better understand
the gaps and opportunities.
And in this case, it was
for building app navigation.
So now that we've defined
user needs and gathered
some requirements, we need
to explore certain solutions.

Korean: 
Navigation Editor의 경우
프로덕션의 주요 지점들은 이랬습니다
하나씩 자세히 살펴보도록 하죠
'검색' 단계에서 먼저 하는 일은
사용자가 누구고
뭘 원하는지 파악하는 겁니다
여기서 중요한 건 사용자의 목표와
그 목표를 달성하는 데 필요한
높은 수준의 작업에 초점을 맞추는 거죠
우리가 아이디어를 얻기 위해
사용하는 방법 하나는
이러한 빈칸 채우기입니다
뭘 하고 싶고, 그걸 하면
뭘 할 수 있는지를 채워 넣는 식이죠
Navigation Editor의 경우
보일러플레이트 코드를 줄이고
싶었고 그렇게 되면 앱의 플로우에
집중할 수 있을 거라고 봤습니다
게다가 우연히도
사용자 연구 과정에서
실제로 이 문장을 듣기도 했습니다
맞습니다
또한 격차와 기회를
더 제대로 이해하기 위해
현재의 워크플로를 평가했습니다
이 경우에는 앱 내비게이션 
구축 워크플로였죠
사용자의 요구와 
조건을 파악했다면
이제 솔루션을 탐색해야 합니다

Portuguese: 
estes foram os principais momentos
na produção do recurso.
Veremos cada um deles em mais detalhes.
Na fase de descoberta,
precisamos entender quem são
os usuários e do que eles precisam.
O segredo é se concentrar
mais nos objetivos dos usuários
e nas tarefas de alto nível
para que eles possam alcançá-los.
Uma das ferramentas de reflexão
que usamos é gerar histórias de usuários
preenchendo os espaços
em branco desta afirmação:
"Como desenvolvedor,
quero ______ para poder _____".
No contexto do editor de navegação,
dissemos: "Como desenvolvedor,
quero escrever menos código padrão
para poder me concentrar
nos fluxos do app".
Por coincidência,
essa foi uma citação que ouvimos
em um dos estudos de usuário.
Sim, exatamente.
Ao mesmo tempo,
avaliamos os fluxos de trabalho atuais
das pessoas para entender melhor
as lacunas e oportunidades.
Nesse caso, para o desenvolvimento
de navegação no app.
Após definir as necessidades do usuário
e coletar requisitos,
precisamos explorar algumas soluções.

Japanese: 
それぞれのフェーズについて
もう少し詳しく説明していきましょう
まず発見フェーズです
ユーザーが誰で 何が必要かを
把握する必要があります
ここで重要なのは
ユーザーの目標と
その達成のために必要な
ハイレベルのタスクに注目することです
優れた思考ツールを使用しました
“開発者として〇〇するために〇〇したい”
という空欄を埋める形式で
ユーザーストーリーを作成したのです
Nav Editorのコンテキストでは
開発者として
アプリのフローに注力するために
定型コードの記述を削減したいとしました
偶然にもこれは
実際にユーザー調査で聞いた
引用の１つでした
そうでしたね
また ギャップや機会の
理解を深めるために
ユーザーが関わる現在のワークフローも
評価します
今回はアプリナビゲーションを
作成するケースです
ユーザーニーズを定義し
要件を集めてきたので
特定のソリューションを
検討する必要があります

Chinese: 
下面我们将详细介绍每一阶段
在发现阶段
我们首先要明确目标用户以及用户需求
这一阶段的关键就是要重点关注用户目标
以及用户实现这些目标所需执行的宏观任务
我们使用的其中一个实用思考工具
就是通过这个待填充的陈述句生成用户故事
即“作为一名开发者，我希望＿，以便＿“
对于Nav Editor
可以这样填充：作为一名开发者
我希望少写一些样板代码
以便将重点放在我的应用流
碰巧
这恰恰就是我们在其中一项用户调查中
真实听到的一句话
是的，没错
同时，我们还评估了
用户当前历经的工作流
以更好地了解
其中的不足和蕴藏的机会
这是一个构建应用导航的示例
在确定用户需求并收集一些要求之后
我们需要探索相应的解决方案

Spanish: 
Veremos cada uno detalladamente.
En la etapa de descubrimiento,
lo primero que debemos determinar
es quién es el usuario y qué necesita.
Lo fundamental
es concentrarse en los objetivos de este
y en las tareas complejas necesarias
para que alcance esos objetivos.
Uno de los grandes recursos que usamos
para generar ideas es crear historias
a partir de esta afirmación
con espacios para completar:
"Como desarrollador, quiero (espacio)
"para poder (espacio)".
Respecto del editor
de navegación propusimos
"Como desarrollador,
quiero escribir menos código estándar
"para poder concentrarme
en los flujos de mi app".
Casualmente,
nos dijeron esas mismas palabras
en uno de los estudios de usuarios.
Exacto.
Al mismo tiempo, 
evaluamos los flujos de trabajo actuales
de los usuarios para comprender mejor
las carencias y las oportunidades.
En este caso,
diseñar la navegación de la app.
Habiendo definido
las necesidades del usuario

Korean: 
이 단계에서의 핵심은
위험한 아이디어에서 안전한 아이디어까지
최대한 많이 시험해 보는 겁니다
몇 가지를 살펴보죠
Navigation Editor를 만들 때 저희는
비주얼 캔버스에서
크게 가려고 했습니다
하지만 이런 질문들이 떠올랐죠
라이브러리에는 잘 맞을 것인가?
사람들이 캔버스 UI를
직관적이라고 여길까?
사용자가 화면을 
만든다면 어떻게 만들까?
양식을 선호할까, 아니면
코드를 통해서 할까?
갤러리 선택기를 원할까?
일단 이런 화면들을 만들고 난 뒤
복잡성이 늘면 어떻게 정리해야 할까?
그릅화가 좋을까? 
네스팅이 좋을까?
화면이 실제 구분된 것처럼 보이도록
시각적 신호를 쓰는 게 좋을까?
이런 화면들을 만든 
다음에는 어떻게 연결할까?
여러 화면이 있다면
목적지도 다양할 텐데
화살표를 하나만 표시해야 할까?
아니면 여러 개 표시해야 할까?
그러면 그래프를 분석하기가 어려울까?
이러한 고민들을 전부 탐색한 후

Chinese: 
所以，这一阶段的重点
就是尽可能尝试多种想法
不管是安全还是冒险
又或者是介于两者之间
我们稍后将讲到其中一些想法
对于Navigation Editor
我们非常想让它在可视画布上发挥更大作用
但我们又会这样询问自己
这会对库产生什么影响？
用户是否会觉得画布界面比较直观？
用户是否会创建屏幕？会如何创建呢？
用户是否更喜欢表单形式？
他们是否更喜欢通过代码达成这一目标？
他们是否想要图库选择器？
若您拥有所有这些屏幕
您会如何在越来越复杂的情况下
来整理它们？
您想将其分组还是相互嵌套？
您想使用视觉线索
来区分屏幕吗？
若您真的拥有所有这些屏幕
您会如何将其关联起来？
正如您所知
很多屏幕都拥有多个目标
我们是画一个箭头？
还是画多个箭头？
这会使解析图表变得更困难吗？
在探索完所有这些想法后

Portuguese: 
O segredo é testar
o máximo possível de ideias,
seguras, arriscadas e intermediárias.
Veremos algumas delas.
No editor de navegação,
queríamos destacar a tela visual.
No entanto, precisamos nos perguntar:
como isso prejudicaria a biblioteca?
As pessoas achariam
a IU da tela intuitiva?
Os usuários criariam telas? De que forma?
Eles preferem formulários
ou fazer isso por código?
Eles gostariam de um seletor de galeria?
Depois de criar todas essas telas,
como elas serão organizadas,
à medida que a complexidade aumenta?
Você gostaria
de agrupar ou aninhar os elementos?
Você usaria dicas visuais
para diferenciar as telas?
Depois de criar todas essas telas,
como elas serão vinculadas?
Como você sabe,
muitas telas têm vários destinos.
Desenhamos uma seta
ou várias?
Isso dificulta a análise do grafo?
Depois de explorar todas essas ideias,

English: 
And so the key here is to
try as many ideas as possible
from safe to risky, and
maybe even in between.
And we'll walk through
a few of these.
So for the Navigation
Editor, we really
wanted to go big on
the visual canvas,
but you know, the
questions we had
to ask ourselves was how would
this work against the library?
Would people find the
canvas UI intuitive?
Would the user create
screens and how?
Would they prefer a form?
Would they prefer to do
it just through code?
Would they want
a gallery picker?
And once you had all these
screens, how would you actually
organize them as
complexity grew?
Would you like to group
things or nest them?
Would you want to use visuals
cues to actually see, like,
differentiate the screens?
And so once you actually had
all those screens, how would
you actually link them together?
So as you know,
many screens, they
have multiple
destinations, so it's like,
do we draw one arrow?
Do we draw multiple arrows?
Does that make it harder
to parse the graph?
And so after exploring
all these ideas,

Indonesian: 
Kuncinya adalah mencoba
sebanyak mungkin ide,
dari yang aman sampai berisiko,
bahkan semuanya kalau bisa,
kemudian menyaringnya.
Untuk Navigation
Editor, kami ingin
membuat kanvas visual selengkap mungkin.
Tapi, masalahnya adalah
bagaimana pengaruhnya terhadap library?
Apakah UI kanvas sudah intuitif?
Apakah pengguna ingin membuat
tampilannya? Seperti apa caranya?
Apakah mereka lebih
suka formulir?
Atau cukup lewat kode?
Atau memilihnya lewat galeri?
Ketika tampilan ini
sudah tercipta, bagaimana
cara mengaturnya
ketika makin banyak detail?
Apakah akan
dikelompokkan atau ditumpuk?
Apa pengguna akan mengandalkan visual
untuk membedakan tampilan?
Saat semua tampilan
ini tercipta, bagaimana
cara menghubungkannya?
Seperti yang Anda tahu,
banyak tampilan yang punya
beberapa destinasi, jadi,
apakah perlu membuat satu panah?
Atau banyak panah?
Apakah grafik jadi lebih sulit diuraikan?
Setelah mengulik semua itu,

Japanese: 
重要なのは安全なもの 危険なもの
その中間
アイデアを色々と試すことです
これからいくつかご説明しましょう
Navigation Editorでは
ビジュアルキャンバスを
大きくしたかったのですが
ご存じのように
問題はそれがこのライブラリーに対して
どう影響するかということでした
ユーザーは直感的なキャンバスUIを
見つけられるでしょうか？
ユーザーは画面を作成するでしょうか？
そしてその方法は？
フォームがよいでしょうか？
コードを使用する方がよいでしょうか？
ギャラリーピッカーが
欲しいでしょうか？
これらの画面がすべてあるとしたら
複雑性が増してきたら
それを整理する方法は？
グループ化や ネスト化でしょうか？
画面を区別するなど
視覚的なものがよいでしょうか？
これらの画面がすべてある場合
どうリンクすればよいでしょうか？
ご存知のように たくさんの画面があり
それぞれに複数の目的地があります
矢印を１つ描くのか
複数の矢印を描くのか
それによって グラフの解析は
難しくなるのか
これらのアイデアをすべて考察してから

Spanish: 
y satisfecho algunos requisitos,
debemos explorar algunas soluciones.
La clave
es probar tantas ideas como sea posible,
ya sean seguras, moderadas o riesgosas.
Veremos algunas en detalle.
En el caso del editor de navegación,
queríamos que ocupara
un gran espacio visual.
Sin embargo,
nos hacíamos varias preguntas.
"¿Cómo funcionará
en relación con la biblioteca?
"¿Al usuario
le parecerá intuitiva la IU del lienzo?
"¿El usuario creará pantallas? ¿Cómo?
"¿Preferirá un formulario?
"¿Preferirá trabajar con un código?
"¿Querrá un selector de galería?".
Con todas estas pantallas,
"¿Cómo las organizará
"cuando aumente la complejidad?
"¿Querrá agrupar o anidar elementos?
"¿Querrá usar indicadores visuales
"para diferenciar las pantallas?".
Teniendo todas esas pantallas,
"¿Cómo las vinculará?".
Como saben, muchas pantallas
tienen varios destinos. Entonces, pensamos
"¿Trazamos una flecha?
"¿Trazamos varias?
"¿Eso dificulta el análisis del gráfico?".
Después de explorar todas esas ideas,

Spanish: 
seguimos con la etapa
de perfeccionamiento,
en la que debemos aunar
y evaluar nuestras ideas.
Aquí colaboramos con los ingenieros
a fin de iniciar el diseño
y, posiblemente, crear prototipos
que se probarán con usuarios reales
para descubrir qué otros ajustes
necesita nuestra idea.
El perfeccionamiento
puede significar muchas cosas,
como definir líneas rojas,
trabajar con las microinteracciones
de las flechas
o crear un prototipo completo
del editor de navegación.
Aquí ven el prototipo que creamos
para probar
si funcionaría con la complejidad real
del gráfico de navegación
de la app para usuarios.
Esta etapa también puede implicar
el diseño de IU de depuración
para ayudar a los ingenieros a visualizar
los detalles de diseño exactos deseados.
Aquí creamos límites
alrededor de este gráfico móvil
para determinar de qué manera el lienzo
lo acercaba y alejaba,
y poder ayudar al usuario
a navegar por dicho lienzo.
Qué interesante.
También fue muy efectivo.
Después de la etapa de perfeccionamiento,
se hacen pruebas con usuarios.

Japanese: 
改善フェーズに移りました
ここではアイデアをまとめ
評価する必要があります
そして
エンジニアと緊密に連携して
構築を開始し
可能ならプロトタイプを
実際のユーザーでテストし
アイデアをさらに改善する
必要があるかについて
確認しました
改善には様々なものがあります
レッドラインの定義
矢印のマイクロインタラクションの
実際の操作
Nav Editorの完全プロトタイプの
構築などです
私たちはこうした改善を行い
ユーザーアプリの
ナビゲーショングラフによって
リアルな複雑性で機能するかどうかを
テストしました
エンジニア向けの
デバッグUIを作成して
期待どおりの設計内容を
視覚化することもできます
今回のケースでは
移動するグラフの周囲に境界線を描いて——
キャンバスがどうズームイン
ズームアウトするかを
確認しました
キャンバスを移動する際に
役に立つでしょう
本当にいいですね
とても効果的でしょう
そうですね

Korean: 
우리는 정교화 단계로 넘어갔습니다
여기서는 의견을 하나로 모아 평가하죠
우리는 엔지니어들과 긴밀하게 작업하며
구축 과정을 시작했고
가능한 경우 프로토타입을 만들어
실제 사용자들에게 테스트하고
개선이 필요한 부분을 확인했습니다
정교화는 여러 가지 형태로 이루어집니다
빨간 선을 정의할 수도 있고
이 경우에는 화살표로
미세한 상호작용을 정의했죠
아니면 Nav Editor의 정식
프로토타입을 만들 수도 있습니다
Nav Editor가 앱에서
그래프를 보여 줄 때도
어느 정도의 복잡성을 보여 주는지
테스트하기 위한 작업이었습니다
또한 엔지니어를 위한 디버그 UI를 만들어
우리가 원하는 설계 세부정보가
정확히 시각화되었는지도 확인하죠
이 경우에는 실제로
움직이는 그래프를
중심으로 경계를 그려서 파악했습니다
사용자가 실제로 캔버스를 탐색할 때
어떻게 확대 및 축소하는지
파악하기 위해서였죠
멋진데요
네, 굉장히 효과적이었죠
네

English: 
we moved to the refined
phase, where here, we actually
have to converge and
assess on our ideas.
So here, we worked
closely with the engineers
to start building things out and
if possible, build prototypes
to test with real users to see
how we'd need to further refine
our ideas.
So refinement comes in many
forms, like defining red lines,
or in this case, really working
with the microinteractions
of these arrows, or
actually building
a full prototype
of the Nav Editor,
which we did here to actually
test if it would actually
work with real complexity
with a navigation
graph for people's apps.
It also goes as far as building
debug UI for the engineers
to help visualize the exact
design details that we want.
So in this case, we
actually drew boundaries
around this moving graph
to help us figure out,
like, how the
canvas was actually
zooming in and out to
help the user actually
navigate the canvas.
PREETHI SRINIVAS: That
looks really cool.
CHRIS SINCO: Yeah, it
was very effective.
PREETHI SRINIVAS: Yeah.

Portuguese: 
vamos para a fase de refinamento,
em que precisamos
convergir e avaliar as ideias.
Nesse ponto,
trabalhamos com os engenheiros
para começar a construir os elementos
e, se possível, criar protótipos
e testá-los com usuários reais
a fim de verificar se precisamos
refinar melhor nossas ideias.
O refinamento ocorre de várias formas,
como definir linhas vermelhas
ou, neste caso, trabalhar
com as microinterações dessas setas,
ou ainda criar um protótipo completo
do editor de navegação,
o que fizemos aqui
para testar se ele funcionaria
com complexidade real,
com os grafos de navegação
dos apps das pessoas.
Podemos até criar uma IU
de depuração para os engenheiros
a fim de visualizar
os detalhes de design exatos que queremos.
Neste caso, desenhamos limites
em torno do grafo móvel para entender
como a tela era ampliada e reduzida
e ajudar o usuário
a navegar nela.
Isso é muito legal.
Sim, foi muito eficaz.
Sim.

Chinese: 
我们就进入了改进阶段，在这个阶段
我们需要对这些想法进行汇总和评估
因此，我们会与工程师紧密协作
以着手扩充这些想法
如果可能，我们还会构建原型
让真实用户亲自测试
以便了解如何进一步改进
这些想法
改进方法有多种形式，例如划定红线
或如本例所示，真实界定
这些箭头的微交互作用
您也可构建
Nav Editor的完整原型
我们此时所做的改进
实际上是为了测试这项功能
能否在用户的应用中
针对导航图表真实存在的复杂问题
发挥作用
这个过程还涉及到
为工程师构建调试界面
帮助我们将设想的设计细节真实展现出来
在本例中，我们围绕这个移动图表划定边界
帮助我们理解相关功能
例如，画布是如何
通过放大和缩小功能协助用户
在画布中导航的
听起来很棒
是的，这种方法非常有效
没错

Indonesian: 
kami beralih ke tahap
penyempurnaan, yaitu kami
harus menghimpun
dan menimbang ide.
Di tahap ini, kami bekerja sama
dengan para engineer
guna memulai proses pembuatan
dan, jika bisa, membuat prototipe
untuk diuji pengguna
sehingga kami tahu
cara menyempurnakannya.
Ada berbagai macam penyempurnaan,
seperti menentukan batasan,
atau dalam hal ini, memastikan
interaksi mikro antara
tanda-tanda panah ini,
atau membuat
prototipe lengkap Nav Editor,
yang memang kami jalankan di sini
untuk menguji apakah
fungsinya berjalan dengan
kompleksitas riil memakai
grafik navigasi untuk aplikasi.
Termasuk juga membuat
UI debug bagi engineer
untuk membantu memberi gambaran
detail desain yang diinginkan.
Dalam hal ini, kami
menentukan batasan
di antara grafik yang
bergerak ini agar tahu
bagaimana tampilan kanvas
membesar dan mengecil
untuk membantu pengguna
mengoperasikan kanvas.
PREETHI SRINIVAS: Keren ya.
CHRIS SINCO: Ya, memang efektif.
PREETHI SRINIVAS: Ya.

Chinese: 
所以在改进阶段之后
就是让用户来测试，对吧？
这个过程通常像一对一会话
但研究表明
在我们的测试进行两到三周后
用户会非常投入
而且他们在使用这项功能时
也会一直为我们提供远程反馈
这个怎么使用？
按绿色按钮
好的
在一项典型的用户调查中
我们不仅要获取开发者的看法
还要收集他们对设计的反馈
这样我们才能设法了解
可以对产品作出哪些改进
以支持他们的日常工作
对于Navigation Editor
我们进行了多个这样的用户调查
但当我们将收集到的部分见解
与自身用户体验验证流程结合起来时
我们遇到了这一障碍
而且还发现了其他问题
因此我们决定先不发布这项功能
这基本上就是我们的机器人
飞行轨迹
现在我要跳过这张幻灯片

Spanish: 
Por lo general, esas pruebas
son individuales y presenciales,
pero hemos hecho estudios
que duraron entre dos y tres semanas
en los que los usuarios
tuvieron un gran compromiso
y nos enviaron comentarios
a medida que iban usando la función.
¿Cómo funciona esto?
Toca el verde.
En los estudios de usuarios habituales,
pedimos a los desarrolladores
que hagan comentarios de nuestro diseño
y, además, nos den su opinión
para que podamos comprender
cómo mejorar el producto
a fin de satisfacer
sus necesidades diarias.
En el caso del editor de navegación,
hicimos varios de esos estudios.
Cuando combinamos la información de estos
con el proceso de verificación de UX,
lo que sucedió
fue que identificamos varios problemas.
Por lo tanto,
decidimos no enviar esta función.
Eso es lo que nos está sucediendo
en este momento.
Omitiré esta diapositiva.
Básicamente,

Japanese: 
改善フェーズの次は
ユーザーによるテストですね
これは通常１対１のセッション
のようなものですが
２週間から３週間ほど調査しました
ユーザーは非常に熱心で
機能を使用しながら
リモートでフィードバックを
提供してくれました
これはどうやって動かすの？
緑のやつをタッチして
すみません
通常のユーザー調査では
開発者から
デザインに関するフィードバック
を集めるとともに
意見をもらいます
日常業務をサポートするため
製品をどう改善するかを
これで知ることができます
Navigation Editorのケースでは
こうしたユーザー調査をいくつか行いました
しかし こうした洞察のいくつかを
独自のUX検証プロセスと
組み合わせたところ
障害にぶつかりました
さらにいくつかの問題が認められました
そのためこの機能を
出荷しないことにしました
これがドロイドが飛び立つのに
起きていることです
次のスライドは
スキップしますが

Indonesian: 
Setelah penyempurnaan,
kami mengujinya ke pengguna.
Biasanya ini sesi personal,
tapi kami menjalankan penelitian
selama dua hingga tiga minggu
saat interaksi pengguna
begitu tinggi
dan mereka memberikan
masukan selama
memakai fitur itu.
Bagaimana caranya?
CHRIS SINCO: Tekan
yang hijau.
PREETHI SRINIVAS: Baiklah.
Studi pengguna
umumnya juga
mengumpulkan masukan dari
developer kami terkait desain
dan meminta pendapatnya
agar kami bisa
mencoba memahami
cara menyempurnakan
produk untuk menunjang
pekerjaan mereka sehari-hari.
Dalam hal Navigation Editor,
ada sejumlah
studi pengguna.
Tapi ketika kami menggabungkan
informasi yang diperoleh
dengan proses
verifikasi UX kami,
muncul kebuntuan.
Timbul juga masalah lainnya
yang berujung pembatalan fitur ini.
Seperti itulah hal yang
terjadi pada fitur Android kami
yang tak diluncurkan.
Saya lewati saja slide ini.

English: 
So following the refine phase,
we test with users, right?
And this is usually like
a one-on-one session,
but there have
been studies where
we have run for like
two to three weeks where
our users have
been super engaged
and they've been providing
remote feedback as they
are using the feature.
How does this thing work?
CHRIS SINCO: Touch
the green one.
PREETHI SRINIVAS: Right.
And a typical user
study involves
gathering feedback from our
developers on our design,
in addition to
getting their opinion
so that we could sort
of try to understand
how we can make product
improvements to support
their everyday work.
And in the case of
Navigation Editor,
we had several
such user studies.
But what happened was when we
combined some of these insights
with our very own UX
verification process,
we hit this roadblock.
And we identified
several issues.
And we decided not
to ship this feature.
And so that basically is what
is happening with our droid sort
of flying out.
So I'm just going to
skip over this slide,

Korean: 
이렇게 정교화 단계에 이어 사용자를
대상으로 테스트가 이루어집니다
보통은 1대1 세션으로 진행되지만
2~3주 동안 사용하도록 하는 
테스트를 맡겼는데
사용자들이 아주 몰입해서
참여하는 바람에
원격으로 피드백을 
제공했다는 연구도 있습니다
이거 어떻게 하는 거죠?
초록색이요
네
일반적인 사용자 연구에서는
개발자들에게 디자인에 대한
피드백도 요청합니다
의견만 수집하는 게 아니라
그들의 일상적인 작업을 지원하며
제품을 계속 개선할 수 있는 방법을
이해하려고 노력하죠
Navigation Editor의 경우에도
그런 사용자 연구가 몇 개 있었어요
하지만 이러한 통찰력을
저희의 UX 검증 과정과 
결합할 때 장애물에 부딪혔습니다
몇 가지 문제점도 파악했죠
결국 우리는 이 기능을
제공하지 않기로 했습니다
말 그대로 저희 드로이드가
허공으로 날아가 버린 사건이었죠
이 슬라이드는 건너뛸게요

Portuguese: 
Após a fase de refinamento,
fazemos testes com os usuários.
Isso geralmente
é feito em sessões individuais,
mas houve estudos
de duas ou três semanas
em que os usuários foram muito engajados
e forneciam feedback remotamente
conforme usavam o recurso.
Como isso funciona?
Toque no verde.
Certo.
Um estudo de usuários típico
envolve a coleta de feedback
dos desenvolvedores sobre nosso design,
além das opiniões deles
para que possamos entender
como fazer melhorias nos produtos
para ajudá-los no trabalho diário.
No caso do editor de navegação,
fizemos muitos
estudos de usuários desse tipo.
No entanto,
quando combinamos alguns desses insights
com nosso processo de verificação de UX,
encontramos um obstáculo,
identificamos vários problemas
e decidimos não entregar o recurso.
É isso que representa essa imagem
do nosso robô voando.
Vou pular este slide.

Chinese: 
之后我们要做的工作就是
与工程师和产品经理协作
[INAUDIBLE]共同解决这些问题
很多细枝末节仍需打磨
我们还需考虑其他方面
例如无障碍使用和边缘用例
总而言之，在进行完用户调查后
我们还有更多工作要做
最后，经过所有艰苦努力
我们终于进入了发布阶段
在这个阶段，发挥作用的
通常是Android Studio潜在客户
他们会根据一套严格的通过/未通过审核流程
来决定或审批哪些功能
可在测试版和稳定版中继续使用
如果您今年早些时候
阅读过这里的其中一篇文章
或有关Navigation Editor的一些其他文章
您就可以了解这项发布的
幕后故事
这个故事真的非常精彩
下面来简要了解下我们的团队
Studio上的每项功能背后都有一个核心团队
团队成员包括工程师、用户体验设计师
产品经理以及开发者关系部推广工程师
我们将整个团队称为核心模型
一般来说，在一项功能的构思和创建阶段

Japanese: 
基本的にはエンジニアや
プロダクトマネージャーと連携して
未解決の問題に取り組む
必要がありました
改善の作業がたくさんありました
またアクセシビリティや
エッジユースケースなど
他の側面の考慮も必要でした
さらにユーザー調査もありました
多大な努力の末にやっと
出荷フェーズに到達しました
このフェーズで通常起こるのは
Android Studioのリーダーです
ベータ版と安定版で安定化した機能の
どちらかに決定する
または承認するなどの 厳密な
go/no-go判断プロセスを行います
今年初めのこれらの記事や
Navigation Editorに関する
他の記事では
今回のローンチにつながった
舞台裏の物語を
ご覧いただけると思います
素晴らしい話です
ではチームについて簡単に
説明しましょう
Studioのすべての機能に
コアチームがあります
コアチームはエンジニア UXer
製品マネージャー
開発者関連の支持者で構成されます
彼らをコアモデルと呼んでいます
通常は機能をイメージして
作成するため

Korean: 
이후 저희는 엔지니어나 
제품 관리자들과 함께
이 심각한 문제를 풀기 위해
함께 협력하며 작업해야 했습니다
손봐야 할 부분이 아주 많았죠
접근성 및 에지 사용 사례와 같은
다른 측면까지 고려해야 했습니다
필요한 사용자 연구도 더더욱 많아졌죠
그런 노력 끝에
결국 기능을 제공할 수 있었습니다
이 단계는 보통
Android 스튜디오 리드가
베타와 안정적인 버전을 통해
안정화된 기능의 사용을
승인하는 작업을 하며
승인 여부는
굉장히 엄격한 
과정을 거쳐 결정됩니다
그래서 올해 초
Navigation Editor에 대해
몇 가지 기사들을 보셨다면 아시겠지만
실제로 이번 출시로 이어지기까지는
많은 비하인드 스토리가 있었죠
이 이야기는 이 정도만 하고
이제 저희 팀에 대해
빠르게 말씀드릴게요
모든 기능에는
중심이 되는 팀이 있으며
이 팀은 엔지니어
UX 전문가, 제품 관리자
개발자 관계 담당자로
구성되어 있습니다
이를 핵심 모델이라고 부르죠
기능을 구상하고 만드는 동안

Spanish: 
después de eso,
debimos trabajar con ingenieros
y gerentes de producto
para solucionar los problemas pendientes.
Tuvimos que pulir muchas cosas.
También debimos considerar otros aspectos,
como la accesibilidad
y los casos prácticos extremos,
y seguir
con la investigación con usuarios.
Luego de este esfuerzo adicional,
llegamos a la etapa de envío.
En esta etapa,
los directores de Android Studio
llevan a cabo un proceso estricto
en el que deciden cuáles son las funciones
con suficiente estabilidad
en la versión beta para ser aprobadas.
Si durante el año
vieron alguno de estos artículos
u otros sobre el editor de navegación,
conocen el detrás de escena
que culminó en ese lanzamiento.
Esa fue una gran historia.
Ahora les hablaré
brevemente de nuestro equipo.
Tras cada función de Studio,
hay un equipo principal
formado por ingenieros, UXeres,
gerentes de producto y representantes
de relaciones con desarrolladores.
Lo llamamos el modelo principal.
Por lo general, los UXeres

English: 
but basically what we had
to do after that was we
had to work with
engineers and product
managers, sort of [INAUDIBLE]
outstanding issues.
There was a lot of polish work.
And we had to take into
consideration other aspects
like accessibility
and edge use cases.
And there was more of
following user research.
And then finally, we
hit the ship phase
with all of this extra effort.
And in this phase, what usually
happens is the Android Studio
leads, they have like a strict
go/no-go process where they are
sort of deciding which of or
approving the features that are
stabilized through beta
and stable versions.
So if you saw one of these
articles earlier this year
or maybe several other
articles on Navigation Editor,
there was actually a
behind-the-scenes story that
actually led to this launch.
Right, so that's a great story.
Now, let's talk about
our team real quick.
Every feature on
Studio has a core team
that comprises of
engineers, UXers,
product managers, and
developer relations advocates.
We call them the core model.
Typically, the UXers are
often partnering closely

Portuguese: 
Basicamente, o que precisamos fazer depois
foi trabalhar com os engenheiros
e gerentes de produto
para resolver os problemas pendentes.
Fizemos muitos aperfeiçoamentos
e precisamos considerar outros aspectos
como acessibilidade
e casos de uso extremos,
e houve mais pesquisas
de usuários de acompanhamento.
Por fim, chegamos à fase de entrega
após todo esse esforço.
Nessa fase,
geralmente os líderes do Android Studio
têm um processo rigoroso do tipo go/no-go
para decidir e aprovar os recursos
que serão estabilizados
pelas versões Beta e estável.
Se você viu
um dos artigos publicados este ano
ou uma das várias notícias
sobre o editor de navegação,
houve uma história nos bastidores que
levou a este lançamento.
Essa é uma ótima história.
Vamos falar um pouco sobre nossa equipe.
Cada recurso no Studio
tem uma equipe principal
composta por engenheiros,
especialistas em UX, gerentes de produto
e mediadores
de relacionamento com desenvolvedores.
Ela é chamada de modelo principal.
Geralmente os especialistas em UX
trabalham em parceria

Indonesian: 
Intinya, kami selanjutnya
bekerja dengan para engineer dan
manajer produk, [TIDAK TERDENGAR]
masalah yang belum selesai.
Ada banyak yang harus dipoles.
Kami juga perlu
menimbang aspek lain,
seperti aksesibilitas
dan penggunaan edge,
dan ada lebih banyak lagi
studi pengguna.
Akhirnya, kami sampai
ke tahap pengemasan
setelah semua kerja keras ini.
Pada tahap ini, biasanya
para pimpinan Android Studio
menerapkan proses
penentuan yang ketat
dalam memutuskan atau
menyetujui fitur yang
akan disempurnakan lewat
versi beta dan versi stabil.
Jika sempat membaca
artikel berikut awal tahun ini
atau mungkin artikel
lain tentang Navigation Editor,
Anda kini tahu ada kisah di baliknya
sebelum diluncurkan.
Sungguh cerita yang menarik.
Sekarang, singkat saja
tentang tim kami.
Setiap fitur di Studio
punya tim inti
yang terdiri dari
engineer, bagian UX,
manajer produk, dan
ahli relasi developer.
Ini model inti kami.
Biasanya, bagian UX
sering bekerja sama

Portuguese: 
com os outros membros desse modelo
durante a elaboração
e criação de um recurso.
Acreditamos que todas as pessoas
têm a responsabilidade,
independentemente do cargo,
de garantir a criação
de ótimas experiências do usuário.
Ao pensar na experiência do usuário,
muitas vezes nós nos referimos
a produtos de consumo,
mas também pensamos
nos desenvolvedores como usuários.
A UX para o desenvolvedor é importante,
porque ferramentas boas
geram produtos excelentes.
Quanto melhores
as ferramentas do desenvolvedor,
mais fácil será
criar experiências incríveis
para os usuários.
Obrigado.
Obrigada.

Chinese: 
用户体验设计师是与这个模型中的其他成员
合作最紧密的角色
我们认为，无论大家担任何种职位
每个人都有责任确保我们打造出
绝佳的用户体验
想到用户体验
我们通常会谈到消费类产品
但我们认为
开发者也是用户
开发者的用户体验也同样重要
因为出色的工具才能造就
一流的产品
开发者工具越实用
开发者就能越来越轻松地为用户
打造出精彩体验
谢谢大家
谢谢大家
[掌声]
[音乐]

English: 
with the other
members of this model
as a feature is being
envisioned and created.
We believe that every person
has this responsibility
irrespective of our job titles
to ensure that we are building
great user experiences.
And oftentimes when we
think about user experience,
we are talking about
consumer products,
but we think developers
are users too
and developer UX matters
because great tools lead
to great products.
The more usable developer
tools are, the more easy
it is going to be for developers
to create amazing experiences
for their users.
CHRIS SINCO: Thank you.
PREETHI SRINIVAS: Thank you.
[APPLAUSE]
[MUSIC PLAYING]

Indonesian: 
dengan bagian
lain dalam model ini
ketika suatu fitur sedang
dirumuskan dan dibuat.
Kami yakin siapa pun yang terlibat
memikul tanggung jawab ini
terlepas dari jabatannya
untuk memastikan terciptanya
pengalaman pengguna yang baik.
Tak jarang pula ketika
membahas pengalaman pengguna,
kami juga membahas
produk konsumen,
tapi bagi kami,
developer juga pengguna
dan developer UX berperan
penting karena alat yang baik
menghasilkan produk yang baik pula.
Makin banyak alat yang
bisa dipakai, makin mudah bagi
developer untuk menciptakan
pengalaman terbaik
bagi penggunanya.
CHRIS SINCO:
Terima kasih.
PREETHI SRINIVAS:
Terima kasih

Korean: 
UX 전문가는 이 모델의 다른 구성원과 
긴밀하게 협력하는 경우가 많습니다
우리는 훌륭한 
사용자 경험을 제공하기 위해서는
직책과 상관없이 누구나
책임감을 가져야 한다고 믿습니다
우리가 사용자 경험에 대해
생각할 때는 흔히
소비자 제품에 대해 이야기합니다
하지만 개발자들도 사용자이며
따라서 개발자 UX도 중요합니다
훌륭한 도구가 훌륭한 
제품으로 이어지기 때문이죠
개발자 도구가 더 많아진다면
그만큼 개발자가 사용자들에게
놀라운 경험을 
만들어 주는 일도 쉬워질 겁니다
- 감사합니다
- 감사합니다

Japanese: 
UXerはよくこのモデルの
他のメンバーと
緊密に連携しています
優れたユーザーエクスペリエンスを
構築するには
役職に関係なくすべての人に
責任があると思います
ユーザーエクスペリエンスについて
検討する際
消費者製品について話し合う
こともよくありますが
開発者もユーザーであり
優れたツールが優れた
製品につながるため
開発者UXが重要だと考えています
開発者ツールが有用であるほど
素晴らしいユーザー
エクスペリエンスを生み出すことが
容易になります
ありがとうございました
ありがとうございました
[拍手]
[音楽]

Spanish: 
trabajan con los demás miembros del modelo
en la concepción
y la creación de la función.
Creemos que,
sin importar nuestro puesto de trabajo,
todos somos responsables de crear
una gran experiencia para el usuario.
Cuando hablamos
de la experiencia del usuario,
solemos referirnos
a productos para el usuario final;
pero los desarrolladores son usuarios
y su experiencia es importante
porque las buenas herramientas
conducen a buenos productos.
Mientras más útiles sean
las herramientas para desarrolladores,
les será más fácil crear experiencias
que sean fantásticas para sus usuarios.
- Gracias.
- Gracias.
