> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/introduccion.md).

# Introducción

*En el capítulo anterior, ya adelantamos qué significaba el proceso **Microsoft Design Style**. A lo largo de este nuevo capítulo vamos a llevar a la práctica dicho proceso para diseñar nuestra interfaz de usuario y cumplir sus cinco principios básicos.*

*Comenzaremos por identificar las necesidades de la aplicación. Continuaremos con diferentes maneras de hacer bocetos, **wireframes**, **mockups** y prototipos y, definiremos cuál será el flujo de navegación entre páginas. Por último, echaremos un vistazo a **Blend** para una primera integración.*

*"Task\[in] comienza a tomar forma".*

***

#### Introducción

Cuando decidimos comenzar a desarrollar una aplicación, una de las primeras tareas a tener en cuenta, son los requisitos de la misma. En qué consistirá, cuál será su objetivo, qué acciones permitirá llevar a cabo y de qué manera y cuál será su aspecto.

En algunas ocasiones se documentarán todos estos requisitos en papel, pero sin concretar en ellos, es decir, se extraerán a muy alto nivel. En otras ocasiones, un prototipo o boceto podrá pensarse que es costoso o no hay tiempo para ello, llegando incluso a rechazar dicha fase. Nada más lejos de la realidad esto es un error. Sin un boceto, un *wireframe*, una maqueta (o *mockup*) o un prototipo, los requisitos pueden malinterpretarse y por tanto las necesidades del usuario nunca quedarán cubiertas. Puede suceder que al usuario no le guste la aplicación, que se canse de ella o incluso que no llegue a utilizarla.

Para minimizar todos estos inconvenientes, es importante dedicar esfuerzo a la creación de un prototipo que ayude al usuario a entender cómo será y cómo funcionará ésta. A la vez, diseñadores y programadores entenderemos sus necesidades y desde el principio, una vez más, ganaremos tiempo e iremos directo al grano con las tareas a realizar, evitando así alguna que otra divagación. En definitiva, seremos más productivos.

Es en este punto cuando numerosas reuniones aportan un resultado final consensuado por todas las partes y, a partir de entonces, es cuando realmente estamos en disposición de iniciar el desarrollo. Por tanto, y siguiendo estas recomendaciones, a lo largo del capítulo completaremos el prototipo para nuestra aplicación, **Task\[in]**.

Conocer los controles y la posibilidad que ofrece el *SDK* siempre ayuda, aun así, debemos abstraernos todo lo posible durante esta fase de diseño.