Usando Esenciales Casos de uso para diseñar una interfaz de usuario de aplicaciones centradas en [cerrada]

Question

Estoy pidiendo un nuevo proyecto (oh, cómo me gusta el sabor fresco de un nuevo proyecto!) Y estamos empezando a diseñarlo. En resumen: La aplicación es una interfaz de usuario que permitirá a los usuarios para modelar un flujo de ejecución (a Visio como el interfaz drag & drop). Por lo que nuestra mayor preocupación es la facilidad de uso y características que le ayudarán a los usuarios el modelo rápida y claramente el flujo de ejecución.

Nuestra metodología establecida hace un amplio uso de los casos de uso con el fin de crear una vista armónico de la aplicación entre los programadores y usuarios. Se trata de una empresa comercial, en realidad:. Yo prefiero usar un método ágil con historias de los usuarios en lugar de casos de usuario, pero tenemos que definir un ámbito claro para vender el producto a nuestros clientes

Sin embargo, los casos de uso tienen una serie de defectos , la mayoría de los cuales están relacionados con el hecho de que incluyen detalles técnicos, como la interfaz de usuario, etc., como puede ser parece aquí . Pero, ya que no podemos utilizar historias de los usuarios y un diseño totalmente interactivo, he decidido que nos compromiso:. Me va a utilizar Esenciales Casos de uso con el fin de ocultar los detalles

Ahora tengo otro problema: que es esencial (sin doble sentido) para tener una descripción clara de la interacción de interfaz de usuario, así, cómo debería documentarlo? En otras palabras, ¿Cómo se especifica una aplicación a través del uso de Esenciales casos de uso donde la interacción de interfaz de usuario es vital para él?

puedo ver algunas alternativas:

• abandonar el uso de casos de uso, ya que no representan correctamente el problema
• No incluya descripciones de la interfaz en el caso de uso, pero crear otra documentación (Story Boards) y el enlace a continuación para el uso esencial casos
• Incluir interfaz de usuario Descripción interacción a lo esencial casos de uso, ya que son parte de la reglas de negocio en la perspectiva de los usuarios y la propia aplicación

Answer 1

Obtener retroalimentación de los usuarios con los prototipos de interfaz de usuario es esencial para crear una interfaz de usuario que la comunidad de usuarios va a entender y ser productivo con. La mejor manera de hacerlo es con la OMI de papel de prototipos . Sus casos de uso puede conducir a la creación inicial de estos prototipos, y las sesiones de interacción del usuario con sus clientes pueden refinar el diseño de interfaz de usuario.

Si prefiere prototipos electrónicos, se puede usar algo como PowerPoint al rápido prototipo ellos.

http: //www.codinghorror .com / blog / 2008/04 / ui-primera-software-development.html y http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html

Answer 2

En primer lugar reunir información sobre el flujo de trabajo y los objetivos de los usuarios. Esto se hace mejor por ir físicamente a ver cómo los usuarios están haciendo su trabajo hoy en día (por ejemplo, usando contextual consulta ). Documentar esos objetivos como casos de uso basadas en objetivos (ver el enlace más abajo), que contienen sólo el objetivo - no deben contener ningún detalle sobre cómo se utilizará el sistema, porque esos detalles son los que estamos empezando a diseñar en base a la casos de uso.

A partir de los casos de uso, crear un prototipo de papel rápida de la interfaz de usuario, e intente el paso a paso que cómo los usuarios podrían alcanzar sus objetivos mediante el sistema de prototipo. Si los casos de uso no se pueden ejecutar bastante bien con el prototipo de interfaz de usuario, seguir mejorando hasta que se admiten todos los casos de uso. Mostrar el prototipo de los usuarios y las pruebas de usabilidad uso y otras técnicas para descubrir problemas con la interfaz de usuario.

Cuando el diseño de la interfaz de usuario es lo suficientemente bueno (~ 85% listo - algunos detalles finos son los más ajustados después de la aplicación), se puede documentar que, por ejemplo, mediante la adopción de secuencias de imágenes del prototipo, que muestran cómo los casos de uso pueden ser ejecutados con el sistema. Pero la comunicación del diseño de UI para los programadores es mejor hacerlo cara a cara, mostrando manualmente cómo funciona el prototipo y responder a sus preguntas. No se limite a "tirar la documentación sobre una pared", pero seguir adelante para ver cómo se implementa y prueba si los partidos de implementación lo que fue diseñado.

Ver la descripción más detallada del proceso en http: //www.cs .helsinki.fi / u / salaakso / documentos / Guide.pdf