Gua-de-referencia-para-el-desarrollo-y-distribucion-de-software-en-plataformas-moviles

Vista previa del material en texto

Universidad Nacional
Autónoma de México
Facultad de Ingeniería
“Guía de Referencia para el
Desarrollo y Distribución de Software
en Plataformas Móviles”
Tesis Profesional que para obtener el título 
de Ingeniero en Computación presenta:
Héctor Zárate Rea
Asesora: Laura Sandoval Montaño
Ciudad de México, Septiembre de 2010.
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
Agradecimientos
A las personas que inventaron y han hecho posible: 
Y por supuesto, a mi padre, a la maestra Laura Sandoval, a Flor Aguilar y a todas las personas 
increíbles que han estado cerca de mi y que me han apoyado: mis amigos. 
:)
Héctor Zárate Rea
Licencia
Una guía de referencia sería de poca utilidad si encontrarla, consultarla y distribuirla fuera difícil. 
Lamentaría que este fuera el caso.
Guía de Referencia para el Desarrollo y Distribución de 
Software en Plataformas Móviles by Héctor Zárate Rea is 
licensed under a Creative Commons Attribution-NonCom-
mercial-ShareAlike 2.5 Mexico License.
 
http://creativecommons.org/licenses/by-nc-sa/2.5/mx/
http://creativecommons.org/licenses/by-nc-sa/2.5/mx/
http://creativecommons.org/licenses/by-nc-sa/2.5/mx/
http://creativecommons.org/licenses/by-nc-sa/2.5/mx/
Tabla de Contenidos
Introducción
 1
La Visión de un Producto de Software
 1
Más allá del bit y del byte
 2
Advertencia
 3
Objetivo
 4
Desarrollar un Producto
 5
Sobre la Ingeniería en general
 5
El Proceso de Diseño en la Ingeniería
 6
La tarea del software
 7
Dispositivos Móviles
 8
Nuevas Plataformas Móviles, Distribución y el Contexto Actual
 9
Android
 11
iOS
 12
Blackberry
 13
Hacer un Producto de Software Valioso
 15
Planeación
 16
 Planeación
 16
 Scrum
 18
 Roles Importantes dentro de Scrum
 19
 El Ciclo Scrum
 20
 Planeación y Bitácora del Producto
 20
 2. Iteraciones (Sprints)
 20
 3. Juntas Diarias (¡pfff!)
 20
 Demostraciones
 21
 5. Retrospectiva
 21
 Algunas Buenas Prácticas para Cada Iteración
 22
 Claridad en el Código
 22
 Comentar el Código
 22
 Wikis
 23
 Respaldos de Seguridad
 23
 Control de Versiones
 24
 Tips de Verificación y Validación para cada iteración
 25
 Probar la aplicación en dispositivos físicos 
 26
 Usuarios ßeta
 26
 Errores Fatales
 26
 Verificar la interfaz de usuario
 27
 Verificar problemas de conectividad
 27
Interfaces de Usuario
 28
Pasos para Crear una Interfaz de Usuario
 29
Arte y Diseño Gráfico
 30
Elementos de Diseño en las Interfaces de Usuario
 30
 Color
 31
 Tipografía
 31
 Imágenes
 32
 Distribución y Agrupación
 33
 Sonidos
 33
Principios Básicos para el Diseño de Interfaces 
 34
Internacionalización y Localización
 35
Accesibilidad
 37
Consideraciones Particulares para Plataformas Móviles
 37
Pantallas Pequeñas 
 38
Menos Memoria y Menores Capacidades de Procesamiento
 38
Batería
 38
Conexiones Costosas 
 39
Servicios de Posicionamiento
 39
Gestos y Nuevas Formas de Interacción
 39
Ayuda Mínima
 40
Duración de la Interacción
 40
Interacción Individual con las Aplicaciones
 40
Integración con el Sistema del Dispositivo
 41
Medir Resultados: Tests de Usabilidad
 41
¿Qué esperar de una buena interfaz?
 43
Marketing
 44
1. Conocer a la audiencia
 45
2. Elementos Importantes de Marketing Dentro de la Aplicación
 46
Nombre de la Aplicación
 47
Look’n Feel
 48
Ícono
 48
Pantalla Splash
 49
Actualizaciones
 50
3. Elementos de Marketing dentro de la Tienda Electrónica:
 51
Screen-shots
 51
Copy (Descripción)
 52
Categoría
 54
Precio
 56
4. Tener un sitio web para el producto
 58
Información indispensable del sitio
 58
Algunas Estrategias de SEO
 59
5. Mantenerse en Comunicación
 60
Blog
 61
Redes Sociales
 62
 Facebook
 63
 Twitter
 64
5. Hacer una Marca
 65
¿Qué es una Marca?
 66
Registro de una marca en México
 67
Estudios de Caso
 70
Ubícate!
 70
Inventando el Producto
 70
Fijar las necesidades del consumidor
 70
2. Definir el conjunto de acciones que el artefacto de software hará
 71
Determinar funciones específicas 
 71
Planeación del Producto
 77
Interfaces de Usuario
 78
Proponer la Presentación y Asignar Acciones 
 78
Marketing
 82
Website
 83
Publicación
 84
Recepción y Resultados
 84
Historial de Actualizaciones85
Conclusiones
 86
Glosario
 88
Bibliografía
 90
/ Introducción1
“Ladies and Gentlemen please take your seats. The show is about to begin.”
- ?
La Visión de un Producto de Software
La producción de software2 en México es generalmente hecha bajo la demanda de un cliente 
que solicita una solución específica para un problema específico. Resultando generalmente en 
software que una empresa utilizará para su operación. 
Esta práctica, la producción de software "In-House", ha sumergido al ingeniero en computa-
ción mexicano en un trabajo técnico de limitada creatividad donde adapta e implementa solu-
ciones existentes para resolver un listado de requisitos de un cliente. 
Este tipo de trabajo, concentrado en resolver un set de problemas de un cliente en particular, 
no ofrece la oportunidad de hacer un software tan refinado y atractivo porque este tipo de ca-
racterísticas no son costeables3. Aunque es una actividad redituable, la mayoría de las veces 
se limita a perseguir el cumplimiento y aprobación de los requerimientos mínimos acordados 
con el cliente. 
En contraste, un producto de software comercial, disponible a usuarios finales en el mercado, 
requiere un esfuerzo continuo de innovación y creatividad los cuales impactarán directamente a 
los usuarios, traduciéndose directamente en su satisfacción y a su vez generando más ventas.
1
1 Toda la vida me he preguntado si en verdad hay alguien leyendo los capítulos introductorios de los libros.
2 Software es un término completamente válido en la lengua española y aparece en el Diccionario de la Real Academia 
Española (RAE) vigésimo segunda edición. Aunque puede sustituirse por expresiones españolas como “programas in-
formáticos” esto es tan alienante como decir “pantaloncillos cortos” en lugar de “shorts”. 
Los anglicismos que aún no están contemplados en la RAE son incluidos en un glosario y son escritos en cursivas.
3 Spolsky, Joel. “Yale Talk” en More Joel on Software. Estados Unidos: Apress, 2008.
Pero hacer un producto de software en México era una tarea prácticamente imposible y una 
visión ajena a muchos desarrolladores. Hacer un producto requería de una infraestructura im-
portante para realizar la distribución física de los productos o en el caso de optar por una dis-
tribución en línea, los trámites para aceptar pagos con tarjetas de crédito, las medidas anti-pi-
ratería y la infraestructura tecnológica para hacer la entrega virtual del producto eran una su-
matoria de obstáculos suficientemente grande como para hacer desistir a cualquiera. 
Pero en los últimos años, junto con los dispositivos móviles, aparecieron nuevas plataformas 
que resolvieron todos los problemas anteriores; revolucionando por completo algunos escena-
rios adversos como el caso de México. Esto ha abierto nuevas posibilidades para el ingeniero, 
pero al mismo tiempo lo hace enfrentarse a nuevos retos de los que tiene que ser consciente y 
que a primera vista, podrían parecer de poca incumbencia para la ingeniería.
Más allá del bit y del byte
Esta tesis tiene la intención de ser un estudio útil para una creciente comunidad de universitarios 
y personas de habla hispana que quieren incursionar en el desarrollo de aplicaciones móviles. 
Pero su análisis no está centrado en “el bit y el byte”, sino en presentar el conjunto de prácti-
cas determinantes para obtener un producto de software exitoso en el mercado y crear cons-
ciencia acerca del deber de invención de la Ingeniería.
Se ha dividido en 5 capítulos que pueden o no ser leídos consecutivamente. De hecho, el lector 
con déficit de atención (o meramente cansado de la linealidad) es libre de consultar cualquier 
capítulo aleatoriamente o de hojear el libro para leer solamente los párrafos con las imágenes 
más interesantes. Los capítulos son los siguientes:
1. Desarrollar un Producto
Una excursión teórica acerca de la ingeniería, su tarea, el proceso de invención, el contexto 
del cómputo móvil y las plataformas actuales.
2. Planeación
Descripción de una metodología ágil para la planeación de un proyecto y algunas buenas prácticas.
2
3. Interfaces de Usuario
Uno de los elementos más importantes en la comercialización de un producto. Se mencio-
nan consideraciones particulares de los dispositivos móviles, sus elementos, una metodolo-
gía para proponer interfaces y una metodología para verificarlas. 
4. Marketing
Estrategias básicas para lograr la exposición de la aplicación y alcanzar a los compradores.
5. Casos de Estudio
¿Cómo aplicar realmente el contenido de este trabajo? Se estudia un caso de éxito que ha 
implementado la mayoría de las prácticas aquí mencionadas.
Advertencia
Ante la convención, podría parecer un texto sobrado de humor e iconografía, pero esto no es 
arbitrario, se ha hecho con la intención de que sea un trabajo consumible por una comunidad 
que requiere textos prácticos, directos y cercanos a ella. De cualquier forma, la academia en-
contrará descanso en saber que la investigación fue tan cuidadosa y formal como en la tesis 
más notable y aburrida del acervo.
Así que sin más preámbulos, “Guía de referencia para el desarrollo y distribución de software 
en plataformas móviles”.
3
/ Objetivo
Analizar las prácticas que constituyen una aplicación exitosa dentro de los escaparates virtua-
les de las plataformas móviles y presentar a la Comunidad Universitaria una guía de referencia 
que contenga información clave para el desarrollo y distribución exitosos de un producto de 
software comercial dentro de estas nuevas plataformas .
4
/ Desarrollar un Producto
“An amazing invention - but who would ever want to use one?”
-  Rutherford B. Hayes
Sobre la Ingeniería en general
La ingeniería es un conjunto de actividades metódicas, científicas y conscientes 
basadas en la apreciación y aplicación de las ciencias, la experiencia y la técni-
ca. Estas actividades se orientan a crear herramientas y adaptar el entorno del 
ser humano para su bienestar y comodidad, pero ocurren determinadas por 
el contexto socio-político en el que se llevan a cabo.
Varios resultados de la ingeniería como estructuras, máquinas, aparatos o 
nuevos procesos (hardware, reglas y sistemas4) pueden ser llamados tecnología, 
la cual a su vez, puede definirse como el arte y conocimiento de “hacer las cosas”5. Un proce-
so en parte ciencia y en parte arte, llevado a cabo dentro de los márgenes del método y la 
exactitud, pero acompañada de ingenio, creatividad e innovación.
Dentro de esta invención deliberada se producen artefactos tecnológicos orientados a que las 
personas extiendan sus capacidades físicas naturales y así, satisfagan necesidades prácticas, 
logren objetivos concretos y (en el mejor de los casos) mejoren su calidad de vida. 
Estos artefactos son objetos físicos hecho por humanos para otros humanos, que tienen una 
función particular y están acompañados de un plan de uso. En una definición más extendida y 
actualizada, son objetos (ya no necesariamente físicos, pudiendo ser también abstracciones) 
muchas veces inconcebidos que tienen un propósito de uso, una descripción bien definida de 
su estructura compositiva e instrucciones acerca de cómo usarlos. 
5
4 Dusek, Val. Philosophy of technology: an introduction. Reino Unido: Blackwell Publishing. 2006. Páginas 31-33.
5 Bird, Michael S. Art and interreligious dialogue: six perspectives. Estados Unidos: University Press of America. 1995. 
Pagina 60.
El Proceso de Diseño en la Ingeniería
La ingeniería concibe estos artefactos en un proceso conocido como “diseño”, varias 
actividades metódicas y sistemáticas para crear cosas nuevas y que en contraste con 
los esfuerzos hechos por la investigación científica, requieren ser una tarea plau-
sible: con un pronóstico claro de éxito y con certidumbre acerca de la dura-
ción y el costo que representará, acotaciones insalvables y presentes en 
cualquier proyecto de diseño para la ingeniería.
Este proceso desdeuna perspectiva general consta de 5 etapas, al final de las cuales el artefacto será, 
además, un objeto disponible a la compra con un ciclo de vida en el mercado. Es decir, un “producto”.
1. Convertir necesidades en funciones.
2. Convertir las funciones en descripciones específicas.
3. Llevar a cabo la construcción de un artefacto según las descripciones propuestas.
4. Probar el artefacto.
5. Producir el artefacto (prototipo) en una escala masiva6.
Hasta este punto, debería tenerse un producto que presente una solución a algún problema real y que 
al utilizarlo para esta tarea, hiciera la vida de quien lo use (el usuario) más productiva, saludable o feliz. 
No obstante, hacer un gran producto sería inútil sin consumidores que costearan su desarrollo: 
hoy en día el diseño de producto debe contemplar también la forma de conseguir y mantener 
esos consumidores, tarea que es conocida como marketing. 
6
6 Este paso es la diferencia entre un prototipo y un producto.
Koren, Yoram. The Global Manufacturing Revolution: Product-Process-Business Integration and Reconfigurable Systems. 
Estados Unidos: John Wiley and Sons. 2010. Página 5-6.
La tarea del software
El software es precisamente un artefacto que ha adquirido gran importancia 
para la sociedad y que hoy se utiliza en forma masiva para mejorar la calidad 
de vida y soportar actividades como el trabajo, la transportación y el entrete-
nimiento. En teléfonos, automóviles, Furbys7, aviones y línea blanca entre 
otras cosas, el software es virtualmente omnipresente en la vida moderna.
Pero decir que el software es una herramienta que simplifica las tareas del 
hombre es ahora una definición insuficiente. Se ha convertido en un componente de la socie-
dad que, más allá de contribuir aisladamente, está transformando todas las actividades de ella 
como la política, la economía, los negocios, la comunicación y la socialización8. La transforma-
ción que está efectuando en la sociedad es tan profunda, que podría ser comparada con la re-
volución industrial en el siglo XVIII y XIX. 
¿Y qué es exactamente el software? El software puede ser visto como una maquinaria virtual 
construida mediante instrucciones en un lenguaje formal de computadora para ser ejecutadas 
por otras computadoras. Esencialmente se divide en dos categorías: software de aplicación 
(aplicaciones) que sirve para hacer tareas útiles y software operativo, el cual está encargado de 
la operación misma de la computadora donde se ejecuta. 
La primera categoría, las aplicaciones, tienen un valor importante y directo para el usuario por-
que éstas determinan cómo realizará determinadas tareas. Por lo que el reto más importante 
de desarrollar una aplicación hoy, no está en el aspecto técnico, sino en proveerle a los usua-
rios herramientas significativas para ellos.
7
7 Thrift, N. J. Knowing capitalism. India: SAGE. 2005. Páginas 190-191.
8 Barkhuus, Louise. Student Socialization in the Age of Facebook. Universidad de California, San Diego. 2010.
Dispositivos Móviles
Los dispositivos móviles de hoy como teléfonos, tablets o iPods son el último 
capítulo de una larga historia de distintas tecnologías que han convergido para 
otorgar movilidad física a los entornos computacionales.
A cambio de otorgarle al usuario la posibilidad de movilidad física, estos dispositivos 
tienen interfaces de entrada menos cómodas, pantallas pequeñas y menores presta-
ciones de hardware, pero esto no debe hacer pensar que su potencial es por de facto me-
nor al de una computadora de escritorio. Muy al contrario, su portabilidad, duración de la batería, 
servicios de posicionamiento y capacidad de comunicación y conectividad los hacen más podero-
sos y adecuados para ciertas tareas que cualquier computadora portátil o de escritorio.
Existe una clara tendencia de que el uso de la computación se está inclinando hacia el uso de 
estos dispositivos móviles: el mercado de las computadoras móviles ha continuado creciendo 
significativamente en los últimos años9, al grado de sobrepasar las ventas de computadoras de 
escritorio10; 3 de cada 4 personas en el mundo utilizan la telefonía celular11, superando la pro-
porción del 33% de personas que tienen acceso a internet; su uso y capacidades son cada vez 
más parecidos al de  una computadora de escritorio; y en internet hay cada vez más teléfonos 
conectados12, con un pronóstico que apunta a que estos superen a las computadoras de escri-
torio y laptops en poco tiempo. 
8
9 Wauters, Robin. Smartphones Lead Global Mobile Market to 20% Growth in Q1. Seeking Alpha. 29 de Abril de 2011. 
Consultado el 5 de Mayo de 2011.
<http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1>
10 Arthur, Charles. Android dominance of worldwide smartphone sales goes on, says Canalys. guardian.co.uk. Consulta-
do el 5 de Mayo de 2011.
<http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates>
11 Internet and mobile phone usage data published by UN. Royal Statistical Society eNEWS. 1ero. de Febrero de 2009. 
Consultado el 5 de Mayo de 2011.
<http://www.rssenews.org.uk/articles/20110131_2>
12 Ingram, Mathew. Mary Meeker: Mobile Internet Will Soon Overtake Fixed Internet. GigaOm - Tech News and Analysis. 
12 de Abril de 2010. Consultado el 5 de Mayo de 2011.
<http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/>
http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1
http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1
http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates
http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates
http://www.rssenews.org.uk/articles/20110131_2
http://www.rssenews.org.uk/articles/20110131_2
http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/
http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/
Nuevas Plataformas Móviles, Distribución y el Contexto Actual
El 11 de Julio de 200813 Apple inauguró el “App Store”. Una tienda virtual disponible des-
de cualquier dispositivo iPhone, iPod Touch o iPad en la cual se puede descargar soft-
ware para estos dispositivos de una forma muy sencilla.
Este nuevo escaparate electrónico y su programa de desarrollo, le dio a todos los 
desarrolladores de software una forma más simple de crear aplicaciones innovado-
ras y de distribuirlas a un nivel global sin preocuparse por aspectos como la imple-
mentación de números de serie o la forma de distribución y pago.
Esto posibilitó a un grupo particular y de interés en este trabajo, desarrolladores individuales o grupos de 
desarrollo muy pequeños, con la oportunidad de comercializar un producto de software ante usuarios 
finales: desde tener una idea, hasta hacer llegar su última y más refinada versión a millones de usuarios.
Esta nueva tendencia presentó un éxito inimaginable, reportando ventas de 1.5 mil millones14 de des-
cargas en su primer año. Naturalmente, varias compañías replicaron el modelo. Entre ellas estuvieron 
Android Market para Android (Octubre de 200815), App World de RIM (1ero. de Abril de 200916), Nokia 
con Ovi Store (26 de Mayo de 200917) y App Catalog de Palm (6 de Junio de 200918).
Al respecto, el dominio del mercado para cada plataforma en Estados Unidos19:
9
13 Quinn, Michelle. Apple: App Store still coming July 11. CNET News . 11 de Junio de 2008. Consultado el 2 de Mayo 
de 2011.
<http://news.cnet.com/8301-13579_3-9966086-37.html>
14 Antony, Bruno. “Change In The Air”. Billboard, Agosto 15 de 2009.
15 Horn, Leslie. Want Free Apps? Try the Android Market. PC Mag. 28 de Abril de 2011. Consultado el 2 de Mayo de 
2011.
<http://www.pcmag.com/article2/0,2817,2384594,00.asp>
16 Patel,Nilay. BlackBerry App World to launch April 1, says BusinessWeek. Engadget.26 de Marzo de 2009. Consultado 
el 2 de Mayo de 2011.
<http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/>
17 Eric. Update on Ovi Store opening. Ovi by Nokia - Blog. 26 de Mayo de 2009. Consultado el 2 de Mayo de 2011.
<http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/>
18 Barletta, Bryan. Palm Pre App Catalog Reaches 1 Million Downloads. Medialets. 24 de Junio de 2008. Consultado el 2 
de Mayo de 2011.
<http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads>
19 Arthur, Charles. Nokia and RIM bleeding smartphone share while Android cleans up. guardian.co.uk . 18 de Abril de 
2011. Consultado el 29 de Abril de 2011.
<http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose>
http://news.cnet.com/8301-13579_3-9966086-37.html
http://news.cnet.com/8301-13579_3-9966086-37.html
http://www.pcmag.com/article2/0,2817,2384594,00.asp
http://www.pcmag.com/article2/0,2817,2384594,00.asp
http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/
http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/
http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/
http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/
http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads
http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads
http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose
http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose
Figura 1: Dominio del mercado de smartphones por sistema operativo
Esta información revela que las plataformas más importantes hoy en día son Android, iOS de 
Apple y los dispositivos Blackberry de RIM; aunque para un país en desarrollo como México, 
estas cifras son ligeramente distintas: los dispositivos de gama baja (como los producidos por 
Nokia) tendrán un mayor dominio del mercado por su menor costo. 
A continuación se analizarán brevemente las tres plataformas más representativas por su im-
portancia en el mercado:
Android iOS RIM Symbian Windows Otros
1%5%1%
11%
27%
55%
10
Android
Android es un set de software open-source basado en Java que opera en un 
kernel de Linux. Este incluye un sistema operativo, middleware y otras apli-
caciones. La programación de aplicaciones se realiza en Java (utilizando 
preferentemente Eclipse) y aunque las interfaces pueden definirse también 
en Java, pueden definirse en XML utilizando herramientas más cómodas. 
Los componentes de una aplicación son:
• Actividades
Análogas a ventanas y diálogos. 
• Proveedores de Contenido
Abstracciones para generar, acceder y disponer de data en las aplicaciones, información que 
puede ser contenida entre aplicaciones. 
• Servicios
Aplicaciones que no tienen un ciclo de vida corto y finito, sino que continúan ejecutándose en 
el background independientemente de otras actividades. 
• Intentos (Intents)
Notificaciones internas que avisan a las aplicaciones de cambios de estado del hardware o 
"mensajes" enviados por otras aplicaciones. 
Como una característica especial, las aplicaciones de terceros se ejecutan con la misma priori-
dad que los procesos del sistema, y todas las aplicaciones pueden tener acceso a los mismos 
recursos de los que dispone el sistema operativo. 
Como recursos comunes se tiene almacenamiento, conectividad a internet, multimedia (imáge-
nes, audio y video), servicios de posicionamiento (GPS) y telefonía. Ya que hay distintos fabri-
11
cantes produciendo dispositivos con Android (los más importantes20: Motorola, HTC y 
Samsung), sus características de hardware (velocidad del procesador, tamaño de la pantalla, 
etc.) pueden variar enormemente entre cada dispositivo. 
El canal oficial para a distribución y venta de aplicaciones es Android Market.
iOS
iOS es el sistema operativo basado en Darwin con el que cuentan los dispositivos 
móviles comercializados por Apple.
El primer dispositivo de este sistema operativo fue el iPhone, puesto a la venta 
el 29 de Junio de 200721. Tras este primer dispositivo continuaron nuevas ge-
neraciones, otro dispositivo idéntico en su funcionalidad exceptuando el teléfo-
no y la localización GPS, iPod Touch y más recientemente una tablet llamada iPad.
Los recursos físicos con los que cuentan estos dispositivos son acelerómetros, cámaras, servi-
cios de posicionamiento, pantalla táctil (todos), multimedia y telefonía.
El desarrollo sobre esta aplicación se hace en el lenguaje Objective-C. Las herramientas de de-
sarrollo son gratuitas, pero para la publicación de una aplicación, el desarrollador necesita rea-
lizar un proceso de registro y el pago de una cuota. Antes de su publicación, todas las aplica-
ciones son revisadas personalmente y evaluadas en términos de usabilidad y desempeño.
Una de las ventajas de la plataforma iOS (iPhone, iPod Touch y iPad) es la poca segmentación 
que hay entre dispositivos, con lo que se evita tener que considerar distintos tamaños de pan-
talla o diferencias sustanciales en el hardware.
12
20 Warren, Christina. Motorola Droid Is Android’s Dominant Device [STATS]. Mashable. 27 de Abril de 2011. Consultado el 
2 de Mayo de 2011.
<http://mashable.com/2010/04/27/admob-stats-march-2010/>
21 Block, Ryan. iPhone release date confirmed: yours on June 29th. Engadget. 3 de Junio de 2007. Consultado el 30 de 
Abril de 2011.
<http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/>
http://mashable.com/2010/04/27/admob-stats-march-2010/
http://mashable.com/2010/04/27/admob-stats-march-2010/
http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/
http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/
La venta y distribución de aplicaciones se hace a través del Apple Store, la cual gestiona todo el 
proceso de compra, instalación y actualización de las aplicaciones. El pago en esta tienda puede 
hacerse con tarjetas de crédito o con tarjetas prepagadas que se venden en tiendas de servicio. 
Apple anunció en su reporte financiero del segundo cuarto de 2011 que había vendido un total 
acumulado de 189 millones22 de dispositivos con el sistema iOS.
Blackberry
Blackberry es una línea de smartphones comercializada por la compañía canadiense Research 
in Motion (RIM). El nicho de mercado de estos dispositivos es el sector em-
presarial23, aunque desde el lanzamiento del modelo Pearl 8100 está inten-
tando tener una mayor penetración en el mercado de consumo24.
Aunque son hechos por un mismo fabricante, las características físicas de los dispositivos son 
variables: tamaño y resolución de pantalla, si es táctil o no, disposición del teclado físico, velo-
cidad del procesador, memoria, velocidad de la conexión a internet y el sistema operativo, 
también es diferente entre cada uno, pudiendo existir diferencias considerables.
Las plataforma de desarrollo para los smartphones Blackberry es Java, pudiendo usar varios 
IDE’s como Eclipse o NetBeans.
La distribución y venta de las aplicaciones se hace en la tienda App World, desde el explorador 
del dispositivo o desde una aplicación de escritorio especial.
Después de evaluar estas 3 plataformas, el estudio de esta guía de referencia será enfocado 
hacia la plataforma iOS por ser una plataforma innovadora, fácil de usar y de gran potencial. 
13
22 Jordan, Jon. Apple has sold a total of 189 million iOS devices. Pocket Gamer. 20 de Abril de 2011. Consultado el 30 
de Abril de 2011.
<http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297>
23 McIntyre, Douglas. Is BlackBerry Maker RIM Ripe for a Rebound? Daily Finance. 5 de Febrero de 2011. Consultado el 
2 de Mayo de 2011.
<http://www.dailyfinance.com/2011/05/02/blackberry-rim-research-in-motion-stock-shares-rebound-outlook/>
24 Wargo, John. BlackBerry Development Fundalmentals.Estados Unidos: Addison-Wesley Proffesional. 2009. Página 4.
http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297
http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297
http://livepage.apple.com/
http://livepage.apple.com/
Sin embargo, será escrita de la forma más general posible para que todos los principios men-
cionados sean aplicables a las demás plataformas de hoy.
En cada una de estas plataformas se han facilitado varios procesos como el de la distribución y 
pago, pero al mismo tiempo ha surgido un reto importante: como existe un único canal oficial para 
la venta de aplicaciones, en cada tienda ocurre una feroz competencia directa25: más de un nego-
cio ofrece el mismo producto o servicio en el mismo mercado a través de los mismos canales de 
venta. 
Pero esta competencia no debe ser entendida como algo negativo, ya que impulsa la innova-
ción por parte de los que ofrecen un bien o servicio y permite a los consumidores tener más 
opciones y mejores productos a un mejor precio. Además, conocer a la competencia es una de 
las mejores formas de entender el mercado y saber qué es lo que necesita y cuáles son las ne-
cesidades que no han sido atendidas.
Otro cambio está en la forma en que los usuarios consumen el software: ahora están me-
jor informados y ya no tienen que atenerse a algunas pocas opciones independientemen-
te de si buenas o malas. Por si fuera poco, ahora tienen expectativas muy altas sobre la 
calidad de las aplicaciones que compran.
Todo esto coloca al ingeniero en entorno muy competitivo, globalizado y extremadamente di-
námico en el que puede ofrecer sus propios productos a potencialmente miles o millones de 
usuarios al mismo tiempo y en el mismo canal en el que lo hacen grandes corporaciones, inge-
nieros de otros países y equipos de trabajo más grandes o con más experiencia
 
14
25 Pinson, Linda. Steps to Small Business Start-Up. Estados Unidos: Kaplan Publishing. 2006. Página 22. 
Hacer un Producto de Software Valioso
La invención de un producto de software de este tipo comienza con el in-
geniero (supuestamente aquel hombre con el deber de desarrollar ingenie-
ría) haciendo un esfuerzo consciente por observar su entorno, anticipar, inter-
pretar y adaptar las necesidades de las personas para visualizar nuevas formas 
de hacer las cosas y dar con un producto útil. A continuación, se deben:
1. Fijar las necesidades del consumidor y definir quiénes son los consumidores del producto.
2. Definir un conjunto de acciones que el artefacto de software hará para que el usuario 
cumpla estas necesidades.
3. Partiendo de esas acciones, determinar funciones específicas (y la capacidad de esas fun-
ciones) para que el consumidor cumpla esas necesidades.
4. Diseñar, planear e implementar el producto de software ideado.
Las funciones específicas que el producto realice serán, junto con la usabilidad y la interfaz de 
usuario, los parámetros de comparación más importantes con otras aplicaciones similares. Todas 
estas funciones deben poder traducirse en beneficios directos para el consumidor, como por 
ejemplo: horas de diversión, ganar tiempo al hacer cierta tarea o bajar de peso más rápidamente.
Entre estas funcionalidades se debe identificar aquella (o aquellas) que son únicas en la aplica-
ción y que la caracterizan frente a la competencia. Saber esto sirve para tener una mejor idea 
de como invertir los recursos disponibles durante el desarrollo y tener una idea clara de los 
mensajes que quieren darse durante las actividades de marketing.
Por último, debe pensarse en la factibilidad monetaria del proyecto; debe ser una solución a 
una necesidad generalizada o si se trata de una aplicación con un nicho de mercado, éste de-
be ser lo suficientemente grande para generar ventas suficientes con las cuales costear el pro-
yecto (y unas fascinantes vacaciones en un lugar remoto y paradisíaco).
15
/ Planeación
“Life is what happens to you while you're busy making other plans”
-  John Lennon
Planeación
La planeación de un proyecto es una actividad centrada en completar un resultado 
dentro de un tiempo y costo determinado satisfaciendo las expectativas del cliente. 
Esta guía presupone que los proyectos realizados por sus lectores presenta-
rán características particulares como:
• Serán realizados por un individuo o un equipo pequeño de individuos.
• La dimensión del proyecto es relativamente pequeña y la primera fase de desarrollo es corta.
• El resultado del proyecto se presentará en un mercado competitivo que requiere velo-
cidad y flexibilidad.
• Probablemente se efectuará sin horarios ni espacios bien definidos, utilizando el tiempo 
libre y localizándose en casa de uno de los colaboradores, la biblioteca de la escuela o 
el Starbucks más cercano.
• No es un trabajo solicitado por un cliente, sino un esfuerzo particular por colocar un 
producto en el mercado.
• Sus integrantes cuentan con poca experiencia en la producción comercial de software.
• Se ejecutan con un presupuesto muy limitado.
• Todos los miembros del equipo comparten responsabilidades a un nivel similar.
16
Distintos proyectos y contextos requieren distintos tipos de planeación: una página web hecha por 
una persona, no requiere el mismo tipo de planeación que el software tolerante a errores utilizado 
en aviones y hecho por un equipo de cientos de personas con un presupuesto de millones de dóla-
res. Por lo general, entre mayor sea la complejidad y mayor el número de colaboradores de un pro-
yecto, se requerirá una mayor estructura en su planeación. Por esto, aunque la mayoría de las me-
todologías comparten algunos principios, no hay “metodología panacéica” aplicable a todos los 
tipos de proyectos y aún la utilización de “mejores prácticas” no es garantía de éxito26. 
Las consideraciones anteriores apuntan a utilizar nuevas metodologías (como el enfoque ágil) 
en lugar de las metodologías tradicionales, las cuales están íntimamente vinculadas con los 
procesos y estructuras del negocio. Estas últimas, fueron diseñadas para equipos de trabajo 
mucho más grandes o proyectos de mayor duración y complejidad, haciendo muchos de sus 
procesos y documentación un esfuerzo innecesario para proyectos más pequeños. 
Las metodologías ágiles surgieron como respuesta a metodologías que en teoría son efectivas, 
pero que en la práctica no lo son tanto. En el enfoque ágil, se persigue la mejora continua, en-
contrar la calidad desde la primera vez, producir únicamente lo que es necesario y enfocarse 
en el desarrollo del software en lugar de en la extensiva documentación, midiendo el progreso 
del proyecto en unidades de software funcional. 
Scrum es uno de los métodos de desarrollo más populares para el desarrollo ágil y uno muy 
adecuado para las características de proyectos de este tipo, razones por las cuales será anali-
zado con detalle y sugerido para planear la ejecución de un proyecto.
17
26 McGuire, Eugene. Software process improvement: concepts and practices. Londres : Idea Group Inc. 
1999. Página 19.
Scrum
Scrum extiende el método de desarrollo incremental a algo llamado proceso de control empírico, 
en donde los ciclos de retroalimentación se convierten en el elemento nuclear. Está inspirado en 
varias áreas de conocimiento como teoría de complejidad, sistemas dinámicos y la teoría de 
creación del conocimiento de Nonaka y Takeuchi, adaptándolas al desarrollo de software.
A grandes rasgos, las fases de desarrollo se dividen en pequeñas iteraciones llamadas 
“sprints”, las cuales duran típicamente entre una y cuatro semanas. 
Primero, se identifican y capturan las tareas requeridas en una bitácora que es actualizada, es-
timada y priorizada al principio de cada una de estas iteraciones. El equipo mantiene breves 
juntas durante cada día de desarrollo para discutir el progreso, plan y potenciales problemas 
del proyecto y se trabaja en las tareas definidas en la bitácora. Finalmenteal término del sprint, 
se demuestran y recapitulan los avances obtenidos y se inicia uno nuevo para repetir el ciclo 
hasta haber terminado la totalidad del proyecto.
Figura 2: El ciclo scrum
Planeación
Sprint
Demostración
Retrospectiva
18
Antes de explicar a detalle cada una de estas fases, hay que conocer los roles principales que 
existen en ellas:
Roles Importantes dentro de Scrum
• Equipo Scrum:
Trabajan efectivamente en los problemas del software. Se sugiere como máximo 9 personas. 
Los miembros del equipo deben decidir cómo se distribuye el trabajo y cómo se define.
• Product Owner
Representa la voz del cliente y administra la bitácora del producto, una lista de tareas priori-
zada por su rentabilidad hacia el negocio. Por lo general se trata de un cliente, pero también 
puede ser alguien que sea parte de la organización. En un enfoque completo, su labor requie-
re conocimiento de procesos de ingeniería, marketing y negocios.
• Scrum Master
Scrum Master es un nombre más divertido para quien en la normalidad sería conocido como “Project 
Manager”. Su tarea es la de poner al equipo de trabajo en las mejores circunstancias posibles y, des-
pués de cada iteración, hacer una retrospectiva para revisar las conclusiones y experiencias con el fin 
de motivar y mejorar el conocimiento del equipo para atacar la siguiente iteración.
19
El Ciclo Scrum
1. Planeación y Bitácora del Producto
En el primer sprint del proyecto, el “Product Owner” compila todos los requerimien-
tos y especificaciones de un nuevo producto para plasmarlas en algo llamado “his-
torias”, las cuales son una descripción de funcionalidades de alto nivel escritas de 
forma breve. En el caso de planear la actualización de un producto se escribirían 
nuevas funciones y parches. Después de esto y al principio de los siguientes 
sprints, se seguirán los siguientes pasos:
A. Cada “historia” que no ha sido implementada, es puesta en la bitácora del producto y el rol 
de “Product Owner” les asigna prioridades.
B. El equipo asigna una valoración de complejidad para cada historia (Ej: 1, 2, 3, 5, 8), se estiman 
cuántas historias pueden ser realizadas durante una iteración y el equipo se compromete a ha-
cer su mejor esfuerzo para terminar todo el trabajo propuesto durante el siguiente sprint.
2. Iteraciones (Sprints) 
A. Todas las historias son implementadas progresivamente en orden de importancia, por-
que son las que representan más valor desde la perspectiva del negocio. Cada equi-
po (o individuo) es responsable de cumplir las historias que ha escogido.
3. Juntas Diarias (¡pfff!)
Durante cada día de desarrollo, el Scrum Master se reúne con el equipo de trabajo para responder, en 
una junta breve, tres preguntas: 
• ¿Qué avances se han hecho desde la última junta?
• ¿Qué va a hacerse desde ese punto hasta la siguiente junta?
• ¿Hay algún conflicto o situación que impida llevar a cabo el plan?
De esta forma se logra que todo el equipo esté informado acerca del progreso del proyecto y que los 
problemas que se han encontrado, sean resueltos. 
20
4. Demostraciones
Al final de cada iteración se hace una demostración de todo el software fun-
cional que se haya realizado: todas las historias son demostradas ante el rol 
de “Product Owner”, quien las aceptará o rechazará. 
Como esta metodología está basada en la iteración de componentes de software 
funcional, en este punto las historias deberán operar en su totalidad y estar libres 
de errores. El último apartado de este capítulo, menciona la tarea de verificación y validación.
Buena Idea: Aún mejor es presentar las historias terminadas apenas se hayan completa-
do, evitando una historia rechazada que se traslapa a la siguiente iteración. 
5. Retrospectiva
Tras la demostración, los miembros del equipo y su juicioso Scrum Master 
responden las siguientes preguntas:
• ¿Qué se llevó a cabo bien? 
• ¿Qué puede ser mejorado?
• ¿Qué acciones pueden tomarse para mantener una alta calidad en el futuro trabajo?
Realimentando la siguiente iteración con los resultados aplicables. 
21
Algunas Buenas Prácticas para Cada Iteración
Claridad en el Código 
Algunos programadores escriben código conciso, complicado e indescifrable para denotar 
su basto conocimiento acerca de la sintaxis del lenguaje y sus trucos más recónditos. Es-
tos intentos desesperados por llamar la atención deben ser sustituidos por la escritura de 
un código claro, simple y entendible en el que distintas personas con distinta experiencia 
pueden trabajar fácilmente.
Un código entendible es más fácil de mantener; y durante su manutención, se reduce el riesgo 
de introducir nuevos errores porque su lógica no sea clara.
Comentar el Código
Los comentarios27 son notas dentro del mismo código del programa que seña-
lan pasos y características claves del mismo y que están escritas de tal forma 
que la computadora pueda ignorarlas para la ejecución del programa. 
Esta práctica genera un tipo de documentación interna que, implementada 
correctamente, permite entender más fácilmente el código en cuestión y es-
to a su vez facilita el mantenimiento y actualización del proyecto, así como la re-utilización de 
código mediante la legendaria práctica del copy-paste.
Tampoco hay necesidad de caer en una sobre-explicación innecesaria: los comentarios son 
empleados cuando el código no puede ser más claro mediante otros medios. 
22
27 Morley, Deborah. Understanding Computers: Today and Tomorrow, Comprehensive. Estados Unidos: 
Cengage Learning. 2009. Páginas 561-562.
Buena Idea: Escribir los comentarios del código al mismo tiempo que se codifica. Escri-
birlos tiempo después de codificar es más complicado ya que probablemente requerirá 
re-entender el código.
Wikis
Un wiki28 es un software en línea que permite a todos sus visitantes cambiar 
su contenido mediante la edición de las páginas dentro de un explorador; 
convirtiéndola en una plataforma simple y fácil de usar para el trabajo colecti-
vo de textos e hipertextos. 
Un wiki privado para los participantes del proyecto puede utilizarse para escribir 
toda la documentación referente al proyecto: bitácoras, resultados de pruebas 
de verificación y validación, tareas a completar, etc. 
En la red existen varias alternativas disponibles y la mayoría de ellas son gratuitas29.
Respaldos de Seguridad
Discos duros dañados, archivos corruptos, virus, empleados vengativos borran-
do archivos sensibles, laptops hurtadas a manos de bandidos sin escrúpulos: 
parecería que la posibilidad de perder todo el trabajo invertido en una aplicación 
es ineludible. Aunque ciertamente no lo es, sí vale la pena tener un plan en que, 
ante un infortunio como los antes mencionados, permitiera reanudar el trabajo 
sobre el proyecto de manera rápida, sencilla y económica (en términos de tiem-
po y dinero) y sin tener que repetir ningún esfuerzo. 
W
23
28 Ebersbach, Anja. Wiki: Web Collaboration. Berlin: Springer. 2008. Pagina 12.
29 :)
Por fortuna, un proyecto para una plataforma móvil tenderá a ser un conjunto de archivos y re-
cursos de tamaño relativamente pequeño y que fácilmente podría respaldarse sobre un CD, 
DVD, Disco Duro, memoria USB o un servidor remoto. Además de los recursos y archivos del 
proyecto mismo, es útil hacer copias de seguridad de la documentación del proyecto. 
Se exponen algunos principios básicos:
• Ordenar la información
backup.tar.gz o backup2.tar.gz no son títulos muy descriptivos. Un buen orden y una buena deno-
minación de los archivos de respaldo, hacen una recuperación de datos mucho más simple.
• Distintas Locaciones
Lejos de detallar ejemplos como huracanes u otras catástrofes remotas , existe el caso mucho 
más cotidiano de que un ladrón entrara a una casa u oficina. Además de llevarse todas las 
computadoras del lugar, es probable que decidiera equiparse también con accesorios como 
discos duros y memorias, convirtiera cualquier práctica del respaldo de información en un es-
fuerzoabsolutamente fútil.
Control de Versiones
Los sistemas de control de versiones (CVS) pueden considerarse como parte de las estrategias de 
backups y respaldos de seguridad, aunque incluye mayores alcances y beneficios. El mercado 
oferta un sinnúmero de posibilidades, varias de ellas gratuitas, cada una con una comunidad de 
adeptos y fanáticos que defienden religiosamente las virtudes de cada sistema y se ocupan en se-
ñalar las faltas y deficiencias de aquellos que no utilizan30. Aunque existen diferencias funcionales y 
filosóficas entre cada sistema, todos los CVS deberían poder hacer lo siguiente31:
• Mantener y permitir el desarrollo de un repositorio de contenido.
• Llevar un registro de todos los cambios hechos sobre cada recurso del repositorio.
• Proveer acceso al historial de ediciones de cada uno de estos recursos. 
24
30 Un vistazo fugaz a este recurso ejemplifica claramente el punto: http://atomized.org/2005/09/subversion-sucks/
31 Loeliger, Jon. Version Control with Git. Estados Unidos: O'Reilly Media, Inc. 2009. Página 1.
http://atomized.org/2005/09/subversion-sucks/
http://atomized.org/2005/09/subversion-sucks/
Tomando en cuenta las consideraciones enunciadas al principio del capítulo, la elección del Siste-
ma de Control de Versiones queda prácticamente reducida a la comodidad que pudiera significar 
un sistema sobre otro: como si el equipo tiene experiencia con algún sistema particular o si el CVS 
esta integrado al Entorno de Desarrollo (IDE) y supondría un uso mucho más simple del mismo. 
Tips de Verificación y Validación para cada iteración
Como se mencionó anteriormente los componentes completados al término de cada iteración 
son componentes funcionales y libres de bugs. Lo que implica que deben haber sido probados 
y se ha verificado que su comportamiento es exactamente el esperado. 
En este tipo de aplicaciones la verificación y validación del programa tiene un objetivo muy concre-
to: buscar la satisfacción del cliente por la compra que ha hecho. Los compradores de software 
son cada vez más intolerantes a productos con errores y ahora tienen altas expectativas que de no 
ser cumplidas, resultan en comentarios negativos en la tienda, o peor aún, en medios como blogs o 
redes sociales que podrían impactar negativamente en las ventas y percepción del producto.
Estas demostraciones justificadas de frustración son causadas principalmente por dos causas: 
un desempeño deficiente y falta de usabilidad. El equipo de desarrollo debe invertir todo es-
fuerzo necesario para eliminar o reducir de forma drástica cualquiera de estas deficiencias. 
Debe considerarse que un producto final distribuido en una tienda, será puesto a prueba por 
un gran número de usuarios en un amplio conjunto de posibilidades impredecibles acerca su 
uso. Entre mayor sea su uso, mayores las probabilidades de que bugs “ocultos” o difíciles de 
encontrar sean, de hecho, encontrados.
Existe un sinnúmero de técnicas y procedimientos detallados para probar código, pero este 
trabajo se acotará a señalar algunas estrategias que den una perspectiva general y práctica de 
la calidad del producto y sus componentes:
25
Probar la aplicación en dispositivos físicos
Probar la aplicación permite verificar dos aspectos importantes de la aplicación: 
• Primero, que la interfaz sea funcional (tamaño y disposición de los botones y texto) en un entorno real. 
• Segundo, los simuladores no representan fidedignamente el desempeño de los dispositivos, 
uso de memoria, conectividad, sistema operativo y otros recursos de hardware. Puede haber 
diferencias importantes en la velocidad del programa o incluso no funcionar del todo. 
Acelerómetros o servicios de posicionamiento tampoco están disponibles en los simuladores.
Usuarios ßeta
El equipo de desarrollo (o desarrollador) están demasiado involucrados y conocen demasiado el 
producto para detectar todos los bugs por sí mismos. Solicitar algunos usuarios beta a través de 
redes sociales o en el círculo de amigos de uno mismo, permite encontrar bugs difíciles de en-
contrar y hacer mejoras en su usabilidad. Como una ventaja adicional se tiene acceso a nuevas 
perspectivas para descubrir nuevos segmentos de mercado y nuevas funcionalidades.
Errores Fatales
No hay frustración más grande para el usuario que una aplicación que termina abrup-
ta e inexplicablemente. 
Si este tipo de errores son detectados, la aplicación está todavía 
lejos de poder llegar al mercado.
26
Buena Idea: Errores fatales que se presentan de maneras misteriosas, ocurren común-
mente debido a problemas con la disponibilidad de memoria.
Verificar la interfaz de usuario
La interfaz del usuario debe ser obvia y consistente. En el capítulo “Interfaces de Usuario” se 
sugiere una metodología simple, pero valiosa para la verificación de la interfaz de usuario. Am-
pliamente recomendable. ;)
Verificar problemas de conectividad
Si la aplicación depende de conectividad con la red para funcionar, deben pro-
barse casos en donde ésta sea nula o deficiente. La aplicación debe ser tole-
rante a este tipo de “eventualidades” no tan eventuales en los móviles. 
Buena Idea: Poner el dispositivo dentro de una caja de zapatos forrada de papel alumi-
nio32 permite probar un enlace degradado de Wi-Fi o de datos; además de dar al desarro-
llador un romántico aire científico-experimental.
27
32 Scholz, Fritz. Electroanalytical Methods: Guide to Experiments and Applications. Berlin: Springer. 2010. 
Página 335.
/ Interfaces de Usuario
“It is far better to adapt the technology to the user than to force the user to adapt to the technology”
- Larry Marine
Las interfaces de usuario33 son todo aquel espacio gráfico y físico en donde los usuarios inte-
ractúan con el software. Dentro de este espacio se le presenta información, la cual él debe en-
tender, evaluar e interpretar para decidir qué hacer con ella. Una vez que decide qué hacer, és-
te crea un plan de acción y retroalimenta a la interfaz con entradas de acuerdo a este plan. En-
tonces, el software interpreta esas entradas y genera cambios internos en los modelos que re-
presentan la información con la que el usuario está interactuando. Todos estos cambios, deben 
ser reflejados nuevamente en la interfaz para que el ciclo pueda iniciarse nuevamente.
La interfaz de un producto de software es una de las partes más críticas del mismo y no es un 
aspecto que deba dejarse hasta el final del desarrollo, sino que muy al contrario, deberá contem-
plarse desde el inicio del mismo, ya que una interfaz mal diseñada puede hacer que el uso de 
una aplicación se convierta en algo verdaderamente tortuoso y en un entorno en donde existen 
cientos de competidores, el usuario no dudará ni un momento en buscar una aplicación con una 
funcionalidad similar (o incluso menor) a cambio de una interfaz más atractiva y cómoda.
Además de ser una parte crítica del desarrollo, también es uno de los procesos más divertidos 
de todo el ciclo, puesto que: existen reglas claras y bien definidas acerca de cómo lograr una 
buena interfaz; no representan un reto técnico insalvable o algoritmos desafiantes que imple-
mentar y finalmente; los esfuerzos invertidos en este proceso son inmediatamente observables 
y profundamente satisfactorios.
28
33 Olsen, Dan. Developing user interfaces. Estados Unidos: Morgan Kaufmann. 1998. Páginas 11 y 12.
Pasos para Crear una Interfaz de Usuario
Pero, ¿cómo comenzar con el diseño de una interfaz? El primer paso 
para hacer una buena interfaz es conocer perfectamente a quienes van 
a usarla y entender cuáles son las tareas que querrán llevar a cabo. 
Teniendo esto claro, se puede proceder a definir un modelo de funcio-
nalidad, el cual describirá las acciones que puede hacer el usuario sobre 
los datos, el estado del sistema y la capacidad de acción que puede 
ejercer sobre los mismos. Una definición de la funcionalidad cuidadosa 
puede hacer que implementar futuras innovacionesen la aplicación sea 
más simple. Al terminar de especificar el listado de funcionalidades del 
programa se puede evaluar y realizar alguna retroalimentación junto con 
algunos usuarios potenciales a fin de verificar que las funcionalidades 
propuestas estén satisfaciendo sus expectativas y necesidades. En esta 
fase no deben contemplarse aún pantallas, comandos, etc. 
Una vez que se ha definido toda la funcionalidad involucrada a través 
de la aplicación, se pueden empezar los bosquejos de la presentación 
visual. En este punto, deben hacerse varias consideraciones respecto 
a los elementos de diseño gráfico (consideraciones enunciadas más 
adelante) y respecto al rendimiento y prestaciones del dispositivo: po-
dría ser que los autores del software deseen darle una interfaz con 
animaciones y millones de colores, pero que muchos de los dispositi-
vos donde se ejecutará el programa sean de gama baja y que cuenten 
con pantallas pequeñas con 256 colores. 
Casi a la par de la presentación, se definen las acciones que pueden 
realizarse en ella. En fechas actuales, esto no debe limitarse a un as-
pecto visual, sino que de ser posible, debería utilizar las nuevas formas de interacción de los 
dispositivos móviles (sensores, gestos en pantallas táctiles, etc.).
Definir 
Funcionalidad
Proponer 
Presentación
Asignar 
Acciones
Conocer al 
Usuario
Integrar 
Arte
29
Finalmente, teniendo el aspecto funcional de la aplicación, este debe integrarse con el diseño 
gráfico y arte de la aplicación, buscando siempre la cooperación y el balance entre función y 
forma. Al respecto, el arquitecto Louis Sullivan dijo: “la forma sigue la función”. El sentido origi-
nal de esta frase radica en que Sullivan estaba convencido de que las formas físicas más bellas 
resultan de diseños que expresen la naturaleza esencial del material en cuestión y que ésta es 
una regla simple común en la naturaleza.
Arte y Diseño Gráfico
El arte y diseño gráfico de una aplicación hacen que sea atractiva y que la actividad de utili-
zarla no solamente sea útil sino también placentera. Muy pocas veces se considera la estéti-
ca como un aspecto relevante, pero en un entorno tan competitivo como estas nuevas plata-
formas de comercialización, la estética puede ser el diferenciador determinante en la elección 
entre varias aplicaciones similares. 
El arte de una aplicación incluye mensajes, íconos, colores e imágenes y estas consideraciones 
deben estar presentes durante todo el desarrollo de la aplicación y no solo en las últimas eta-
pas. Un resultado notable y competitivo es prácticamente imposible de lograr sin la colabora-
ción de profesionales de las artes gráficas.
Elementos de Diseño en las Interfaces de Usuario
Todos los elementos que se describen a continuación deberán utilizarse con el fin de comuni-
car más claramente un mensaje al usuario, al mismo tiempo deben considerarse los lineamien-
tos de Interfaz Humana específicos para cada plataforma, ya que aunque existen tendencias 
universales, puede llegar a haber variaciones entre plataformas.
30
Color
La vida diaria está plagada de colores que transmiten mensajes importan-
tes, como los semáforos o colores en carteles de advertencia; también 
existe el caso de colores que no apelan a un fin utilitario, sino que tienen un 
fin estético como los colores en la ropa que usamos. Las interfaces de 
usuario no son la excepción en el dominio del color: este puede ser usado 
para resaltar y estructurar la información que se presenta al usuario y para 
hacer la interfaz más atractiva.
Buena Idea: El uso excesivamente desinhibido del color produce estéticas incongruen-
tes, de mal gusto e incompatibles con su funcionalidad. En una palabra, kitsch34.
Tipografía
La tipografía es el “arte de disponer correctamente el material de imprimir, de 
acuerdo con un propósito específico: el de colocar las letras, repartir el espacio y 
organizar los tipos con vistas a prestar al lector la máxima ayuda para la com-
prensión del texto”35. Es una disciplina que ha estado presente desde las prime-
ras interfaces con el propósito de tener una mejor y más rápida legibilidad. 
Deben elegirse fuentes que sean legibles y al mismo tiempo atractivas. Su tamaño debe ser 
suficientemente grande para que pueda ser leído con comodidad por personas de distintas 
edades y sus variantes de peso, inclinación y color deben ayudar a resaltar y organizar la in-
formación que se presenta ante el usuario.
A
31
34 Ejemplos, historia y un extenso debate acerca del término alemán “kitsch” pueden ser disfrutados en el libro “A Com-
panion to Aesthetics” de Stephen Davies.
35 Morison, Stanley. Principios fundamentales de la tipografía. España: Ediciones del bronce. 1998.
Buena Idea: En la red hay miles de fuentes disponibles para descargar, pero no por esto hay 
que utilizarla todas. Distintas fuentes transmiten distintos mensajes; usar más de 2 o 3 fuen-
tes por pantalla (4 o 5 por aplicación) resulta en caóticos y confusos popurrís tipográficos.
Imágenes
Las imágenes en las interfaces son ahora tan importantes como el texto que 
contienen y el avance en el hardware de los dispositivos permite usar imágenes 
de mejores resoluciones y mayores profundidades de color. Pero no solo debe 
prestarse atención a la calidad del archivo en términos de su resolución y color, 
sino que también al contenido pictórico y lo que este representa hacia el usuario: 
íconos e imágenes dentro de la aplicación pueden representar comandos, estados, objetos y resulta-
dos del modelo de datos. Todas estas imágenes e íconos deberán ser obvias para los usuarios exper-
tos y evidentes para los nuevos usuarios.
Para íconos e imágenes que tengan una relación directa con la funcionalidad del programa se pueden 
evaluar mediante el mismo método que los diseñadores del American Insitute of Graphic Arts (AIGA) 
utilizaron en 1981 para evaluar señales utilizadas en medios de transporte público de Estados Uni-
dos36. Esta evaluación contempla 3 dimensiones diferentes:
• Sintaxis: Es la relación entre las imágenes utilizadas. ¿Cómo se relaciona este símbolo con otros 
símbolos? ¿Es entonces consistente en la forma en que está dibujado? ¿Sus características como 
dimensión, orientación, formato, color, etc. son consistentes con los demás símbolos?
• Pragmatismo: Describe la relación de la imagen con el usuario. ¿Las personas pueden leer clara-
mente el símbolo? ¿El símbolo es afectado por condiciones de luz, ángulo de visión u otro tipo de 
ruido? ¿El símbolo es igualmente efectivo al ser muy pequeño o muy grande? 
• Semántica: Es la relación de la imagen con su significado. ¿Qué tan bien representa este símbolo a 
su significado? ¿Personas de distintas culturas entienden bien este símbolo? ¿Personas de distintas 
edades entienden el mismo significado? ¿Este símbolo es utilizado universalmente? 
32
36 AIGA. Symbol Signs: The System of Passenger / Pedestrian Oriented Symbols Developed for the US Department of 
Transportation. Estados Unidos: Hasting House. 1981.
Un gran ejemplo de lo anterior es el trabajo iconográfico del Sistema de Transporte Colectivo 
Metro de la Ciudad de México del diseñador Lance Wyman hecho en los años sesenta. Wyman 
trabajó bajo la consigna de hacer pictogramas de cada una de las estaciones para que los visi-
tantes extranjeros (y analfabetas mexicanos) de los juegos olímpicos de 1968 pudieran identifi-
car las estaciones independientemente del idioma que hablaran. 
Distribución y Agrupación
Al disponer controles y textos dentro de la interfaz, deben mantenerse márgenes consistentes entre 
los bordes de las pantallas y los controles relacionados entre si deben mantenerse en grupo. Contro-
les que no tengan relación con otros deben mantenerse ligeramente separados. 
Al hacer uso de márgenes se debe intentar usar una misma medida para que el usuario reconozca y 
visualice la información más fácilmente. 
Sonidos
Los estímulos auditivosinforman a las personas de señales importantes que ocurren 
a su alrededor, como alarmas contra incendios o bebés al borde de la inanición. Es 
un sentido fuertemente ligado a la experiencia de vida de las personas mediante el 
cual reciben información (no necesariamente crucial) del medio que los rodea. Las apli-
caciones pueden hacer uso de este sentido para:
1. Llamar la atención del usuario y alertarlo de un cambio de estado relevante para él (por 
ejemplo, batería baja);
2. Envolverlo en la experiencia de la aplicación (como lo hace la música de los video-juegos);
3. Dar más retroalimentación acerca de las acciones que realiza el usuario sobre el sistema (¿el mejor 
ejemplo? los tonos que se escuchan al marcar un número telefónico) y finalmente, pero no menos 
importante;
4. Hacer la interfaz de usuario más divertida :)
33
Como todo en esta vida, debe hacerse un uso moderado de este recurso para evitar que sea demasia-
do invasivo hacia el usuario y los archivos deberán ser de la máxima calidad posible evaluando también 
que no sobredimensionen innecesariamente el tamaño final de la aplicación. 
Principios Básicos para el Diseño de Interfaces
Además de las consideraciones enunciadas en la sección anterior, vale la pena mencionar una 
de las listas de principios de diseño más universales, útiles y, al mismo tiempo, más actualiza-
das hasta el momento: 8 principios investigados y depurados durante veinte años por Shnei-
derman y Plaisant y nombradas “Las Ocho Reglas de Oro para el Diseño de Interfaces”37.
6. Buscar Consistencia:
Esto quiere decir homogeneizar las propiedades de los elementos visuales como por ejem-
plo: fuentes, distribución y tamaños; y unificar todos los términos utilizados a lo largo del 
producto: menús, ventanas, avisos, documentación, etc..
7. Atender la Usabilidad Universal
Durante el diseño de la usabilidad de un producto, se debe tener en mente que los usua-
rios, por lo general, difieren en edad, experiencia y capacidades. Los usuarios inexpertos 
agradecerán algunos mensajes de ayuda mientras que los usuarios expertos preferirán co-
mandos o atajos para realizar más rápidamente sus tareas.
8. Ofrecer Retroalimentación Informativa
Las acciones del usuario sobre el sistema, deben provocar alguna retroalimentación por parte de 
éste, y esta retroalimentación debe ser proporcional a la magnitud de las acciones del usuario. 
9. Agrupar las interacciones para indicar su fin
Las interacciones secuenciales con el sistema deben organizarse en grupo de tal forma que 
un inicio y un fin puedan ser identificados y que al llegar a este, el usuario del sistema pue-
da encontrar el alivio emocional de “haber terminado una tarea” (esto también hace refe-
rencia al punto No. 3). 
34
37 Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Estados Uni-
dos: Addison-Wesley. 2009.
10. Prevenir Errores
El sistema debe ayudarle al usuario a evitar errores, por ejemplo: evitar caracteres alfabéti-
cos dentro de un campo destinado a “Código Postal”.
11. Permitir la fácil retracción de las acciones
A todos nos gustaría que la vida tuviera un botón de “CTRL-Z” que aliviara la ansiedad y 
miedo de cometer errores y explorar nuevas posibilidades. Dentro de lo posible, las accio-
nes efectuadas dentro de un sistema deben ser reversibles.
12. Hacer sentir al usuario que tiene el control
Un automóvil que no responde a la operación del usuario es un automóvil que nadie le gus-
taría usar (y una peligrosa situación que a nadie le gustaría vivir). Este fenómeno se presen-
ta también durante el uso de cualquier software.
13. Reducir la carga en la memoria de corto plazo
La memoria a corto plazo de las personas comunes esta limitada a retener 7 ± 2 ele-
mentos38. Esta es una consideración importante para el diseño de menús, opciones e 
información dentro del producto.
Internacionalización y Localización
Estas nuevas plataformas de distribución permiten al desarrollador colocar sus aplicaciones 
dentro de un alcance global. Salvo excepciones donde la aplicación se dirija a una audiencia 
delimitada a una región de composición afín entre sí (idioma, cultura, etc), habrá que considerar 
Oh là là!
35
38 Miller, George. The Magical Number Seven, Plus or Minus Two Some Limits on Our Capacity for Processing Informa-
tion. Psychological Review, Vol. 101, No. 2. Páginas 343-352.
adaptar la aplicación, su contenido y recursos, para ser consumidos dentro de distintas culturas. A 
este proceso, la estrategia de diseño en la que se soporta a la comunidad global de usuarios del 
cómputo mediante variaciones sistemáticas entre regiones y culturas, se le denomina localiza-
ción39. 
Por otro lado, la internacionalización significa “habilitar una aplicación o un sistema, para pre-
sentar distintos formatos y lenguajes sin cambios en su código fuente”40. El proceso de locali-
zación no se refiere únicamente al lenguaje escrito, sino a describir y alinear todo contenido de 
una aplicación dentro de la familiaridad de la ubicación geográfica, el lenguaje, sensibilidades 
particulares y los formatos numéricos de una cultura. 
La lista de items a considerar para una localización incluye principalmente:
• Menús y cualquier texto estático dentro de la aplicación
• Íconos y gráficas,
• Archivos de sonido que incluyan palabras
• Ayuda en línea (si es que la hay)
• Texto dinámico como fechas, horas y valores numéricos
En la mayoría de los casos, no será indispensable contar una localización que incluya 125 
idiomas, pero se deberá identificar perfectamente la audiencia a la que va dirigida el producto y 
a partir de esto, evaluar qué idiomas y localizaciones son los más importantes para la comer-
cialización del producto y hacerlo de los más inclusivos o generales hacia los más particulares. 
Una localización prácticamente indispensable es la del idioma inglés, pero algunos casos es-
pecíficos requerirán alguna otra con la misma urgencia: un diccionario francés-español / espa-
ñol-francés, deberá estar localizado (al menos) para el idioma francés y español.
36
39 Rosson, Mary Beth. Usability engineering: scenario-based development of human-computer interaction. Estados Uni-
dos: Morgan Kaufmann. 2002. Página 352.
40 Kogent Solutions Inc. Java Server Programming Java Ee5 Black Book. Estados Unidos: Dreamtech Press. 2008. 
Apéndice H.
Buena Idea: La primera localización que uno debería pensar en hacer es para el idioma inglés.
Accesibilidad
 41
Accesibilidad42 se refiere al conjunto de características que debe proveer un 
entorno, producto o servicio para ser usado en términos de confort, seguridad 
e igualdad para todas las personas, particularmente para todas aquellas 
personas con discapacidades. El diseño de las interfaces de usuario debe 
ser pensado bajo la idea de diversidad y no en función de la persona co-
mún, promedio o joven: cualquier persona de cualquier edad debe ser capaz 
de poder utilizar cualquier interfaz sin tener que enfrentar ningún problema. 
Es deseable que si la plataforma provee algún componente para mejorar la accesibilidad de la 
aplicación (como etiquetas especiales para un lector de voz) estos sean utilizados.
Consideraciones Particulares para Plataformas Móviles
Los dispositivos móviles son también un equipo de cómputo y como tal, comparte algunas ca-
racterísticas con computadoras de escritorio, laptops o servidores. Pero también presentan 
características únicas y diferencias funcionales que requieren un enfoque nuevo al desarrollar 
aplicaciones para ellos:
37
41 Macías, José A. New trends on human-computer interaction: research, development, new tools and methods. Estados 
Unidos: Springer. 2009. Página 133.
42 1st National Accessibility Plan 2004-2012. España. 2004.
Pantallas Pequeñas
Las resoluciones actuales de los dispositivos móviles más modernos se encuen-
tran alrededor de los 320 x 480 (iPhone 2G, 3G, 3GS, iPod Touch 2G, 3G)y 640 
x 960 pixeles (iPhone 4). Resoluciones 3 o 4 veces más pequeñas comparadas 
con la resolución del monitor de una computadora de escritorio común.
Como consecuencia, se requiere que el diseño de la interfaz de usuario 
presente únicamente los elementos indispensables y que los mantenga en 
una cantidad mínima para evitar un producto poco atractivo y difícil de usar. 
Menos Memoria y Menores Capacidades de Procesamiento
Vivimos una época en la que el precio de las memorias RAM y los procesado-
res han permitido ser más indulgentes en la evaluación del desempeño y 
aprovechamiento de los recursos que tienen nuestras aplicaciones. Sin em-
bargo, cualquier dispositivo móvil cuenta con una cantidad de memoria RAM 
mucho más limitada y una capacidad de procesamiento aproximadamente 3 
veces menor que el de una computadora de escritorio. Debe ponerse espe-
cial atención a fugas de memoria y uso ineficiente de la misma; de igual forma 
debe mantenerse al margen el tamaño de todos los recursos multimedia.
Batería
 Un teléfono o cualquier otro dispositivo móvil tiene una cantidad limitada de 
energía provista por baterías. Un buen diseño en una aplicación debe pro-
curar evitar hacer cálculos innecesarios, conexiones redundantes a internet 
o un uso innecesariamente intensivo de los servicios de posicionamiento 
(GPS) que pudieran agotar la carga de las baterías del dispositivo y dejar al usua-
rio desprovisto de su inseparable gadget en una situación de vida o muerte.
<
38
Conexiones Costosas
En México, la conectividad en los dispositivos móviles (tanto voz y datos) tie-
nen un costo monetario muy alto43. La aplicación debe minimizar (sin com-
prometer su función) el número de conexiones a internet o el tamaño de los 
datos que descarga, porque esto representa un costo para el usuario.
Servicios de Posicionamiento
Casi es obvio señalar que un dispositivo móvil implica movimiento. Esto le 
puede dar al desarrollador nuevas posibilidades respecto a otras plata-
formas: saber la localización del usuario puede derivar en funcionalida-
des de mucho valor para este.
Gestos y Nuevas Formas de Interacción
Hasta hace no mucho tiempo, la interacción con los dispositivos electróni-
cos (no solo móviles) estaba limitada a las puntas de los dedos. Afortuna-
damente, las interfaces más recientes empiezan a incluir nuevas dimen-
siones entre esta interacción entre dispositivos e individuos: reconocimien-
to efectivo de voz, sensibilidad a gestos táctiles más complejos, sensibili-
dad al movimiento, cámaras, etc.
Para lograr una experiencia total y actualizada de la aplicación, se requiere pen-
sar en todas estas nuevas formas de interacción y buscar aprovecharlas de forma 
que hagan la interacción con el usuario más natural, rápida y dinámica. 
39
43 “[altas tarifas], las cuales son 43.5% superior al promedio de las que aplican los países miembros de la OCDE,” 
Alonso, Ramiro. "Cofetel envía modelo de costos a la Cofemer" El Universal. 3 de Marzo de 2011. Consultado el 25 de 
Marzo de 2011. 
<http://www.eluniversal.com.mx/finanzas/84947.html>
http://www.eluniversal.com.mx/finanzas/84947.html
http://www.eluniversal.com.mx/finanzas/84947.html
Ayuda Mínima
Una aplicación móvil tiene la intención de poder ser accedida fácilmente y ser 
utilizada de manera rápida y efectiva. Por esta misma razón y el limitado 
espacio en pantalla, se prefiere evitar la necesidad de mostrar una ayuda 
en pantalla, el diseño de la interfaz de la aplicación puede recurrir a los con-
troles estándar de la plataforma, con los cuales el usuario estará familiariza-
do, disponiéndolos de una manera lógica y obvia, que lleve al usuario a intuir fá-
cilmente el funcionamiento de la aplicación.
Duración de la Interacción
La interacción de los dispositivos móviles ocurre en intervalos de tiempo muy 
cortos y de manera paralela a las actividades cotidianas del usuario. Esto 
quiere decir que las aplicaciones móviles se usan mientras el usuario con-
duce su automóvil44, usa el transporte público o espera formado en una lí-
nea al borde de un aburrimiento paralizador y que por esta misma razón de-
berán ser breves, rápidas y altamente funcionales ya que el usuario no tiene la 
capacidad de invertir mucha atención mientras las utiliza. 
Interacción Individual con las Aplicaciones
El usuario de un dispositivo móvil utiliza una única aplicación a la vez mientras utiliza su dispo-
sitivo. Aunque es posible que viaje entre una y otra, esta tarea esta aún lejos de ser igual de 
eficiente que una computadora de escritorio; este suplicio debe ser evitado a toda costa. 
Por ejemplo: que el usuario deba abrir una sesión de su explorador para registrarse en un for-
mulario y después de eso, regresar a la aplicación en cuestión.
40
44 Se estima que 28% de los accidentes automovilísticos en EU están relacionados con el uso de teléfonos.
Halsey III, Ashley. "28 percent of accidents involve talking, texting on cellphones" The Washington Post. 13 de Enero de 
2010. Consultado el 4 de Marzo de 2011. 
<http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html>
http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html
http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html
Integración con el Sistema del Dispositivo
Este punto apela al primer principio básico para el diseño de interfaces de usuario: consisten-
cia. El usuario de un dispositivo móvil, estará familiarizado con los menús y ventanas que pre-
sente su sistema operativo y la aplicación deberá intentar adaptar estos elementos y sus para-
digmas dentro de ella con naturalidad. Poner poca atención a las características y lineamientos 
particulares de cada plataforma deja al usuario con una sensación inconsciente de que su apli-
cación está pobremente desarrollada o incompleta.
Medir Resultados: Tests de Usabilidad
Una prueba de usabilidad intenta caracterizar el Look’n Feel de la aplicación y sus aspectos de 
uso desde el punto de vista del usuario. Por lo tanto estas pruebas (más correctamente valida-
ciones), son subjetivas y varían entre usuario y usuario. A grandes rasgos, lo que esperarían 
evaluar es: 
1. Facilidad de uso
2. Velocidad
3. Satisfacción visual (estética)
Hacer un test de usabilidad a gran escala y de la forma tradicional es costoso y requiere un 
gran esfuerzo, pero existen formas alternativas de llevar a cabo “tests de usabilidad caseros” 
que mejorarán notablemente el resultado de cualquier aplicación. Basada en una descripción 
de David Barnard45, una guía rápida para realizar tests de usabilidad:
41
45 Mark, Dave. IPhone User Interface Design Projects. Estados Unidos: Apress. 2009. Capítulo 3.
1. Primero lo primero: hay que encontrar algunos usuarios de la plataforma para que analicemos los 
resultados que tienen nuestras interfaces sobre ellos46. Estamos buscando al usuario común de la 
plataforma, no un power-user o mucho menos al hacker experto que le ha hecho intrincadas modi-
ficaciones al sistema operativo de su teléfono. Al mismo tiempo, estamos buscando usuarios que 
sean representativos del mercado al que nos estamos dirigiendo.
Amigos, amigos de amigos o extraños con caras amigables en un restaurante de comida rápida 
usando un dispositivo de la plataforma en cuestión, son buenos sujetos para pruebas de usabilidad. 
Buena Idea: Nada mejor para despertar el interés de los sujetos de estudio que 
recompensar su participación con algún atractivo incentivo como: una copia gra-
tuita del producto, cerveza gratis, una comida o tarjetas pre-pagadas para una al-
guna tienda electrónica de música.
2. Encontrado algún sujeto de estudio, comienza la prueba de usabilidad. En este segundo paso se 
limitaría a presentarle la aplicación junto con una descripción breve de lo que hace y a explicarle 
que en la prueba no hay respuestas buenas o malas y que sus errores son valiosos para el resul-
tado.