Local blog for Spanish speaking developers in LATAM
Diálogos de muestra: La clave para crear de Actions on Google excelentes
miércoles, 3 de octubre de 2018
Publicado por Cathy Pearl, directora de difusión de diseño de conversación
Ilustraciones de Kimberly Harvey
¡Hola a todos! Soy Cathy Pearl, directora de difusión de diseño de conversación de Google. Hace ya un tiempo que estamos creando sistemas conversacionales. Comenzamos con las IVR (sistemas de teléfono) y continuamos con experiencias de varios modos. También soy la autora del libro
Designing Voice User Interfaces
, de la editorial O'Reilly. En estos días, quiero presentar a los diseñadores y desarrolladores nuestras
prácticas recomendadas de diseño de conversación
para que las Actions puedan proporcionar la mejor experiencia a los usuarios. Hoy, voy a hablar sobre un primer paso que es fundamental al pensar en la creación de una Action: la escritura de diálogos de muestra.
Supongamos que tienen una buena idea sobre Actions on Google que desean crear. Mejoraron su desempeño con
Dialogflow
, hicieron algunos
laboratorios de código
y determinaron las API que desean usar. Están listos para iniciar la codificación, ¿no es así?
¡No tan rápido!
La creación de una Action siempre debe comenzar con
el diseño de
una Action. No teman, esto no los retrasará. Planificar el diseño primero ahorra tiempo y dolores de cabeza luego, y finalmente conduce a una experiencia mejor y más útil.
En esta publicación, voy a hablar del primer y más importante componente para el diseño de un buen sistema conversacional: los diálogos de muestra. Los diálogos de muestra son caminos conversacionales posibles que un usuario puede tomar mientras conversa con tu Action. Se asemejan a los guiones de películas, con intercambios de diálogo entre tu Action y el usuario. (Como en el caso de los guiones de películas, ¡se deben leer en voz alta!). La escritura de diálogos de muestra
antecede
a la escritura del código e incluso a la creación de flujos.
Cuando hablo con la gente sobre la importancia de los diálogos de muestra, recibo una gran cantidad de asentimientos y aceptaciones. Pero cuando regreso posteriormente y digo “Muéstrenme sus diálogos de muestra”, a menudo recibo una sonrisa vergonzosa o una excusa de por qué no se escribieron. Entre las comunes se incluyen las siguientes:
“Solo estoy creando un prototipo, puedo omitir esas cosas”.
“Las palabras no me preocupan ahora, puedo ajustar eso después”.
“¡La parte difícil tiene que ver con la integración de backend! Las palabras son la parte sencilla”.
En primer lugar, hay un concepto erróneo de que el “diseño de conversación” (o el diseño de interfaz de voz de usuario) es la capa superior de la experiencia: las palabras y tal vez el orden de las palabras que el usuario verá u oirá.
Pero el diseño de conversación va mucho más allá. Conduce la estructura subyacente de la experiencia, que incluye lo siguiente:
¿Qué llamadas de backend realizaremos?
¿Qué sucede cuando algo falla?
¿Qué datos solicitaremos al usuario?
¿Qué sabemos acerca del usuario?
¿Qué restricciones técnicas existen, para la tecnología en sí o para nuestro ecosistema?
Al final, estos aspectos se manifiestan como palabras, para que haya certeza. Pero considerarlas como “cosas para preocuparse luego” los predispondrá al fracaso cuando llegue el momento de que sus usuarios interactúen con sus Actions. Por ejemplo, sin un diálogo de muestra probablemente no puedan darse cuenta de que todas sus solicitudes comienzan con la palabra “Luego”, lo cual hace que suenen robóticas y rebuscadas. Los diálogos de muestra también les mostrarán los puntos en que necesitan palabras “conectoras” como “en primer lugar” y “por cierto”.
Google reunió
pautas de diseño
para compilar sistemas conversacionales. Esto incluye una introducción a los diálogos de muestra y la razón por la cual son importantes:
Los diálogos de muestra transmiten un sentido rápido y de baja fidelidad del “sonido y la sensación” de la interacción que se diseña. Proporcionan el flujo que el usuario experimentará realmente, sin las distracciones técnicas de la notación de código, los diagramas de flujo complejos ni los problemas de gramática con reconocimiento, entre otros aspectos.
Al escribir diálogos de muestra, pueden experimentar de manera informal varias estrategias de diseño y evaluarlas, como la manera de promover la visibilidad de características nuevas o de confirmar la solicitud de un usuario (por ejemplo, ¿se debe usar una confirmación explícita o no se debe usar ninguna confirmación?).
Consulten los
diálogos de muestra de Actions de Google I/O 2018
para ver un ejemplo. (También pueden mirar el
código de Actions de Google I/O 2018
).
¿Aún no están seguros de
necesitarlos
realmente? Escuchemos a Jessica Dene Earley-Cha, una desarrolladora que trabaja en Actions, quien dijo lo siguiente en su
publicación de Medium
reciente:
Veamos cómo se creó esto. Antes de que surja cualquier codificación, se debe crear un diseño conversacional. Originalmente, omití este paso porque creí que podría crear la estructura en primer lugar y luego completar el contenido (como crear un sitio web).
Sin embargo, la estructura está vinculada al contenido.
Me di cuenta de esto cuando encontraba obstáculos que consideraba técnicos, pero estaban ahí porque no tenía un diseño.
Señala que el diseño de sistemas conversacionales es diferente del diseño para la web. Con una interfaz conversacional, el contenido
en sí
es parte de la estructura, de modo que el diseño se vuelve aún más importante.
Así que ahora que están (espero) convencidos, veamos cuatro de los inconvenientes comunes que los desarrolladores pueden evitar al usar diálogos de muestra:
INCONVENIENTE N.º 1: Sobrecargar al usuario con demasiada información
Supongamos que escriben una Action para una tienda de bicicletas: puede generar citas de reparación y servicio, proporcionar los horarios de la tienda y mencionar las últimas ofertas. Es tentador comenzar simplemente a mencionar opciones para que el usuario sepa todo lo que puede hacer. Veamos cómo se ve un diálogo de muestra recurriendo a esa estrategia:
USUARIO
Oye Google, habla con la tienda de bicicletas de Alyssa.
ACCIÓN
¡Hola! Bienvenido a la tienda de bicicletas de Alyssa. ¿Quieres realizar una cita de reparación, cancelar una cita, conocer los horarios de la tienda, enterarte de las ofertas de esta semana o escuchar las ofertas del próximo mes?
Si leen esta solicitud en voz alta para alguien, se notará rápidamente que se presenta demasiada información. Los humanos tienen una capacidad limitada para percibir el audio, en especial si es la primera vez que los oyen.
A continuación, se muestra una alternativa más conveniente:
USUARIO
Oye Google, habla con la tienda de bicicletas de Alyssa.
ACCIÓN
¡Hola! Bienvenido a la tienda de bicicletas de Alyssa. Puedo ayudarte a fijar o cancelar una cita, mostrarte los horarios de la tienda o transmitirte las últimas ofertas. ¿Qué deseas?
Sugerencia de un profesional: en una experiencia aún mejor se omitiría la opción “cancelar” si el usuario no tiene una.
INCONVENIENTE N.º 2: Mantener en secreto lo que sus Actions pueden hacer
A continuación, se ofrece un diálogo de muestra que representa un error común en muchas experiencias conversacionales. En este ejemplo, el usuario regresa a una Action que ya probó:
USUARIO
Google, habla con Astronomy Trivia Game de Cathy.
ACCIÓN
Esto es el Astronomy Trivia Game de Cathy. ¡Bienvenido nuevamente!
USUARIO
Oh... ¿qué puedo hacer?
Cuando estamos inmersos en nuestro diseño, a menudo nos olvidamos de que el usuario se encontrará con la Action sin conocer nuestro segundo plano. Lo que puedan hacer no siempre será obvio.
Aquí hay una mejora:
USUARIO
Google, habla con Astronomy Trivia Game de Cathy.
ACCIÓN
Esto es el Astronomy Trivia Game de Cathy. Puedes jugar solo o unirte a un equipo. ¿Qué te gustaría hacer?
USUARIO
Oh, creo que me voy a unir a un equipo.
Recuerden que no tienen la necesidad de hacer una lista con todas las opciones de antemano. En lugar de ello, intenten guiar al usuario en el proceso de manera clara y terminen con una llamada a la acción.
INCONVENIENTE N.º 3: No invitar al usuario a hablar
Otro problema común es no mostrar con claridad el momento de hablar para el usuario. Como humanos, tenemos muchas alternativas para hacerle saber a alguien que es su turno: palabras, entonación, miradas y lenguaje corporal. Para elementos como el Asistente, es importante finalizar el turno con una pregunta o una instrucción clara. Aquí se muestra un ejemplo de una Action que deja al usuario en espera:
USUARIO
Google, habla con Cool Animal Facts.
ACCIÓN
¡Bienvenido a Cool Animal Facts! ¿De qué animal te gustaría recibir información?
USUARIO
¡Amo los pingüinos!
ACCIÓN
Genial, pingüinos. ¿Te gustaría recibir información sobre su hábitat o lo que les gusta comer?
USUARIO
¡Qué les gusta comer!
ACCIÓN
¡Los pingüinos pueden comer hasta 13 libras de pescado, camarones y calamares por día! ¿Y sabías que los padres se sientan sobre los huevos?
USUARIO
Sí, vi...
ACCIÓN
Mientras tanto, las madres salen a buscar pescado.
USUARIO
(pensando) Espera... ¿debo decir algo?
En este ejemplo, se ven dos problemas. Primero, la Action hizo una pregunta retórica. Cuando el usuario intentó responder, la Action lo ignoró y continuó hablando.
El segundo problema es que después del hecho no sucedió nada. No hubo indicación de lo que podía hacer luego el usuario.
Aquí se presenta una mejor alternativa:
ACCIÓN
¡Los pingüinos pueden comer hasta 13 libras de pescado, camarones y calamares por día! Por cierto, los pingüinos machos pasan tiempo empollando los huevos mientras las hembras salen a pescar. ¿Te gustaría obtener más información acerca de los pingüinos o preguntar por otro animal?
USUARIO
Es suficiente, gracias.
ACCIÓN
No hay problema, gracias por hablar con Cool Animal Facts. ¡Adiós!
Sugerencia de un profesional: A menudo, los usuarios desean un elemento de cierre explícito, como la palabra “Adiós”.
Segunda sugerencia de un profesional: ¡Produzcan una gramática sólida! Para la pregunta “¿Te gustaría obtener más información acerca de los pingüinos o preguntar por otro animal?”, prepárense para manejar respuestas como “Sí”, “No” y nombres de animales.
INCONVENIENTE N.º 4: Hacer que las solicitudes de error sean universales
Manejar con gracia la conversación cuando las cosas no funcionan bien es fundamental para cualquier sistema conversacional. Escribir varias solicitudes de errores para cada turno en la conversación puede parecer abrumador. Usar una respuesta predeterminada como “Perdón, no comprendo” no será útil para el usuario. En cambio, se debe recurrir a lo que ha sucedido hasta ese punto y al punto en el que el usuario se encuentra actualmente. Para hacerlo más sencillo, escriban diálogos de muestra para condiciones de error. Esto mostrará con mayor claridad el contenido de las solicitudes.
USUARIO
Google, habla con el Zombie Quiz.
ACCIÓN
¡Es hora de Zombie Quiz! Primera pregunta: ¿cuál de las siguientes medidas deberías tomar si te persiguiera un zombi? ¿Bloquear la puerta, huir hacia las colinas o plantar un jardín?
USUARIO
(pensando)
ACCIÓN
Lo sentimos, no capté eso. ¿Qué eliges?
USUARIO
¿Qué? No recuerdo...
ACCIÓN
Lo siento, aún tengo dificultades. ¿Qué eliges?
USUARIO
¡Oh!
ACCIÓN
Lo siento, eso es incorrecto. Pregunta dos…
El manejo de errores que dependen del contexto pone al usuario de nuevo en el buen camino:
USUARIO
Google, habla con el Zombie Quiz.
ACCIÓN
¡Es hora de Zombie Quiz! Primera pregunta: ¿cuál de las siguientes medidas deberías tomar si te persiguiera un zombi? ¿Bloquear la puerta, huir hacia las colinas o plantar un jardín?
USUARIO
(pensando)
ACCIÓN
¿Cuál de estas cosas deberías hacer si te persiguiera un zombi? ¿Bloquear la puerta, correr hacia las montañas o plantar un jardín?
USUARIO
Uhh... No estoy seguro... a ver... tal vez...
ACCIÓN
También puedes decir el número de la respuesta, como uno, dos o tres. ¿Qué eliges?
USUARIO
Oh, la número tres.
ACCIÓN
¡Correcto!
La lista de tareas previa al vuelo
Sé que están ansiosos por despegar, y por comenzar a dibujar flujos y escribir código, pero primero deben tomarse tiempo para escribir diálogos de
muestra.
A largo plazo, esto facilitará la codificación y tendrán menos errores que corregir.
A continuación, les presentamos una lista de lo que “se debe hacer” para que lo tengan en cuenta cuando escriban diálogos de muestra:
Consulten las
Conversation Design Guidelines
para obtener más ayuda.
Inicien sus diseños usando diálogos de muestra
escritos u orales
; los diagramas detallados del flujo pueden esperar.
¡Lean sus diálogos de muestra
en voz alta
!
Hagan que cada diálogo de muestra sea
un
camino que no incluya desvíos.
Escriban varios diálogos de muestra con un “camino viable”.
Escriban varios diálogos de muestra con un “camino no viable”.
Hagan una “lectura de tablas” y solicita a personas no familiarizadas con tu diálogo de muestra que ocupen el lugar del usuario.
Compartan sus diálogos de muestra con quienes participen en la creación de la Action, para que todos estén de acuerdo.
Al hacer pruebas, comparen la Action que realmente funcione con los diálogos de muestra para asegurarse de que se haya implementado de manera correcta.
¡Iterar, iterar, iterar!
¡Feliz escritura!
Labels
.app
.dev
.txt
#AMP
#CPU
#DeveloperStudentClubs
#DevFest
#DragonBall
#DSC
#Forsety
#ForsetySecurity
#freeandopen
#GCP
#Google
#GoogleCloud
#GoogleCloudPlatform
#GoogleLaunchpad
#iio2009
#Kubernetes
#MaterialDesign
#OneCommunity
#Security
#TensorFlow
#UPGlobal
#UpLatam
#WithGoogle
+page
10 YEARS
2013
2019
64 bits
A/B Testing
AA
Accelerator
Action on Goolge
actionbar
Actions
Actions Console
AdMob
Ads
adwords
adwords api
AI
AIY
ajax
alarmmanager
ALFA
almacenamiento
alojamiento de proyectos en google code
AMP
AMP Conf
AMP Project
amp-date-picker
amphtml
Analytics
Andorid
android
Android (operating System)
Android 3.1
android 3.3
android 4.2
android 9
Android 9 Pie
Android App Bundle
android design
Android Dev Summit
Android Developers
android Jetpack
Android P
Android SDK
Android Studio
Android Things
Android Wear
AndroidDevStory
androititlan
angelina jolie
Annotation
Announcements
anuncios
API
API Analytics YouTube
Apigee
APIs
Aplicaciones
aplicaciones chrome
app
app engine
App Indexing
app invites
App Server
applications
AppQuality
apps
Apps Script
AR
ARCore
arte
ATLAS
AWP
backend
Base64
batch
Bava
Betatesting
Better Ads Standars
bigdata
BigQuery
Biometrics
blink
bootcamp
BOT
BQ
Business
búsqueda ajax
by Google
byCases
byCommunity
byDevelopers
byGoogle
C++
CALENDAR
Cardboard
case
caso de éxito
Casos de éxito
casos destacados
CCOSS
Century Fox
chat
chrome
chrome web store
chromebook
chromecast
chromium
Cinéfilos
cloud
Cloud Anchors
CLOUD endpoints
Cloud Firestore
Cloud Functions
Cloud IoT Core
Cloud Next
Cloud Scheduler
Cloud services
cloud test lab
Cloud Text-to-Speech
Cloud Translation
CMD en vivo
coconut
code
code-in
code.org
CodeLabs
código
código abierto
Colab
colombia
Communities
Comunidades
concurso google
conference
contenedores
convocatoria
Coordinate
crashlytics
CRE
crear aplicaciones ajax
creatividad
Crowdsource
CSS
cws
daniela robles
dart
dart sdk
dartium
dartlang
Dataset
DCL
denis labelle
desarrolladores
Desarrolladores Google
desarrolladores LatAm
Desarrollar
Design
Design Sprint
Destacados
dev
Dev.f
DevArt
DevBus
DevBusLatAm
Developer Bus
Developer Summit
DeveloperConsole
developers
DevFest
devoxx
dialogflow
diseño UX
Distribuir
DNS
DOM
domain
DonkeyCar
doubleclick
Drive SDK
Drivers
ecommerce
ecosistema
elections
elizalde
Emoticons
emprendedores
empresas
engagement
english
Enhanced Campaigns
enterprise
eventos
Events
evolución de aplicaciones
Excel
ExpertosDicen
Faas
Family
FanBridge
FCM
FCP
Featured
fido
find people
Fintech
firebase
Firebase Cloud Messaging
firebase summit
flu trends
Flutter
Flutter 1.0
flutter 1.7
flutter developers
Flutter Live
FlutterLive
FoundersLab
Freebase
Fuction
Fuctions
Full-Stack
functional programming
G Suite Dev Show
G+
g+ goto gal
G+GotoGal
GAE
game
games
GCloud
gcm
GCP
GCS
GDA
GDE
GDG
GDH
GDL
GDLevent
GDS
Get Inspired
get.app
GitHub
GLP
gmail
golang
GOMO
Google
Google Accelerator
Google AdMob SDK
Google AdWords
Google Analytics
Google APIS
Google App Engine
Google Apps
Google Apps Script
Google Art Project
Google Assistant
google calendar
google cast
Google Charts
Google Chrome
Google Cloud
Google Cloud Console
Google Cloud Messaging
Google Cloud Next
Google Cloud Platform
Google Cloud Platform Newsletter
google cloud platforn
Google Cloud Storage
google code-in
Google Compute Engine
Google Dataset
Google Developer Groups
google developers
Google Developers Academy
google developers expert
Google Developers Hackademy
google dns
Google Drawings
Google Drive
Google Earth
Google for games
Google Forms
google geo
Google Home
google i/o
google i/o extended
google io
Google Keep
Google Kubernetes Engine
Google Launchapad
Google Launchpad
Google Maps
google maps coordinate
Google Maps Platform
Google Mexico
Google Nose
google now
Google Person Finder
google places api
Google Play
Google Play Books
Google Play Developer API
google play games
Google Play Movies
Google Play Protect
Google Play Services
Google Plus
Google Science Fair
google search
Google Sheets
google sign in
Google Top Geek
Google+
Google+ Communities
Google+ Hangouts
google+ sign-in
GoogleAPI
googlecloud storage
GoogleCloudPlatform
googledevs
GooglePlay
Googleplex
Goolge Lunchpad
GTG
Hackademy
hackers
Haiko
Haití
hangouts
Hangouts Remote Desktop
hardcode
Heello
honeycomb
HTML
HTML5
HTTPS
I/O
IA
IAM
IETF
IFAI
in app purchases
in-app
ingles
Ingress
instagram
integración de soluciones
interactive post
Interesante
International
International Women’s Day
IO
io15
io18
io19
iOS
IoT
istio
IU
IVR
J2EE
java
JavaScript
jelly bean
JS
JSON
Juegos
juegos html5
Kit ML
Knative
kotlin
kUBERNATES
Kubernetes
LATAM
latamRegionSur
Launchpad
Launchpad Studio
Lenovo Mirage Solo
lightbox
linux
lucero galindo
machine learning
Made with Code
Mapdata
Mapeo
maps
Maps Ad Unit
Maps API
Maps Engine
Market
Marketing
Marshmallow
MATERIAL DESIG
Material Design
mejores apps 2013
México
michelle marie
MIT
MIT Global Start-up Labs
MIT-AITI
ML
ML Kit
mobile
monetizar
mongoDB
MOOC
Motorola
Mountain View
móvil
MQTT
mr.white
mTLS
natalie villalobos
Navigation
NBA JAM
NES
Next Big Sound
Next Level
nfc
Niantic
Nik
NINTENDO
node.js
NoSQL
nube
OAuth2
Objective-C
OClock
open source
OPenApi
OS
OSS
Paas
PageSpeed
PagesSpeed
parallel18
patrones
patters
performance
permisos
Pipeline API
Pixability
pixel
Píxel
play
Play Console
Playtime
Podcast
pollito pio
Polymer
por lote
Posse
Prediction API
primer
Producto
programación
Propositos
Protocol Buffers
proyecto 20%
Push API
PYMES
python
Q
Q4
quickoffice
Rasberry Pi Zero WH
Raspberry Pi
Realtime
Reflectly
register
Release
Resources
robots.txt
Safe
SDK
Search
Security
seedbank
seguridad
SEO
servidores
Showyou
sign-in
SNES
SO
social media
Spain
SpLATAM
SQL
SQLite
Start
startup grind
Startup Launch
startup weekend
startup weekend for the planet
startupbus
startups
StayAtHome
story
Street View
subtitles
success
sw
SyScan
tablet
Tablet Optimization Tips
tabletas
takeaction
Tango
tendencias 2013
TensorFlow Developer Summit
testing
TextView
TF JAM
The Garage
The Venture City
tips G+
tips gmail
TLD
TLS
Top Experts
Top Geek
top level domain
TopExpert
topics
traducciones
Transparency Report
triggers
Tubular Labs
twilio
Tyka
TypeScript
UAC
udacity
ui
Umbrales
UNAM
unity
Unity3D
universal search
UX
Vector
VectorDrawable
video juegos
vidIQ
ViewPager
Visual Progress
Voicekit
VPC
VR
VSCode
web
Web hosting
Web móvil
WebAssembly
with google
Wizdeo
WizTracker
Women at Google
Women Techmakers
workmanager
WTM
XKCD
XML
Yifat Cohen
youtube
YouTube Analytics API
YouTube API
YouTube Data API
YouTube One Channel
YouTube Player API
Archive
2024
sept
2023
nov
oct
sept
ago
jun
may
abr
mar
ene
2022
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2021
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2020
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2019
dic
nov
oct
sept
ago
jun
may
abr
mar
feb
ene
2018
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2017
nov
sept
ago
jul
jun
may
abr
ene
2016
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2015
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2014
dic
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2013
dic
nov
oct
ago
jul
jun
may
abr
mar
feb
ene
2012
dic
nov
oct
sept
ago
jul
2011
nov
oct
may
mar
2010
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2009
dic
nov
sept
ago
jul
jun
may
abr
mar
feb
ene
2008
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2007
dic
Feed
Desarrolladores
Eventos y Comunidad
Casos Destacados
Dicen los Expertos
Google Accelerator