design - usuario - principios de diseño de la gui
Plantilla de especificación de interfaz gráfica de usuario (3)
Creo que los prototipos de papel son una parte importante del desarrollo y especificación de UI.
Eche un vistazo a las notas de la conferencia aquí:
Creo que es importante tener en cuenta que la buena especificación de GUI debe contener un conjunto de directrices / principios para todo el proyecto, para garantizar la coherencia. Por lo general, heredo de un conjunto bien establecido de directrices (EX: http://download.microsoft.com/download/e/1/9/e191fd8c-bce8-4dba-a9d5-2d4e3f3ec1d3/ux%20guide.pdf ) y luego una lista cualquier diferencia
Para formularios individuales, componentes, etc. Especifico el diseño general usando Lápiz con muchas anotaciones:
... que permite la creación de prototipos de ui rápida y agnóstica similar a la creación de prototipos de papel. Todavía es importante usar prototipos de papel para cualquier cosa que los diseñadores no deseen cambiar. Es más probable que los usuarios sugieran cambios si el diseño parece no permanente (esta es la razón por la cual el software de la cabina puede realizar impresiones con calidad degradada de boceto).
Además, he encontrado que es útil tener una fase de prueba de aceptación de diseño de interfaz de usuario. Todas las partes interesadas del proyecto deben firmar el diseño de la interfaz de usuario antes de implementarlo. Después de todo, para la mayoría de los usuarios de computadoras no técnicos, la interfaz de usuario ES la aplicación.
En mi trabajo, colocamos algunos elementos del diseño para la interfaz gráfica de usuario tanto en la especificación funcional como en los documentos de diseño técnico. Sin embargo, esto es a menudo fácil ya que casi el 100% del tiempo estamos haciendo modificaciones al software existente.
¿Qué haría si quisieran producir un documento separado para la especificación de GUI que era para un nuevo proyecto de software? Tengo un software que me puede ayudar con marcos de alambre simples, pero ¿cómo sería un esquema de plantilla de documento? ¿Qué usas para una plantilla o esquema?
Fui parte de un grupo de hace unos años que tenía un muy buen proceso de especificación de UI. Creamos un documento que contenía:
- Una visión general de la metáfora general de la interfaz de usuario (por ejemplo, "Página y carpeta", "Tarjeta de presentación")
- Elementos de interfaz de usuario propuestos (por ejemplo, los botones de ayuda que incluyen los iconos, el estilo que se utilizará en las listas desplegables, etc.). Todos estos apoyaron la metáfora.
- Especificaciones para los estándares de espaciado y justificación para los cuadros de diálogo (todos tenían 8 píxeles o borde, los botones debajo de los cuadros de lista siempre estaban a x píxeles de distancia, etc.).
- Especificaciones de fuentes (el nuestro debía ser un proyecto muy estilísticamente único)
- Incluimos especificaciones sobre cómo proporcionar ''Ayuda'', pero esto fue un poco inusual
- Maquetas de pantalla candidatas que incorporaban los elementos de la interfaz de usuario y que demostraban la metáfora.
La documentación de la interfaz de usuario no está destinada a capturar todas las pantallas y todos los cuadros de diálogo. Sin embargo, debe tener suficiente información para que alguien que revise la especificación obtenga una idea muy clara de la apariencia de la aplicación. También nos tomamos algunas molestias para deletrear diálogos clave o aquellos en los que la metáfora era particularmente importante.
Una última cosa, cuando hicimos la especificación, trabajamos con un grupo de diseño gráfico que realmente creó varias versiones candidatas iniciales. Después de que los miembros del equipo votaron sobre los candidatos, tomamos el ganador y lo desarrollamos con mucho más detalle.
Considere si la especificación de la GUI es requerida por razones comerciales o de diseño.
La profundidad de detalle requerida de una especificación de GUI generalmente estará determinada por los requisitos comerciales del comercio que rodea el proyecto de software en lugar de los requisitos del usuario final. Por lo general, se crea una especificación de GUI que contiene detalles extensos, como selecciones de fuentes, iconos, anchuras de bordes de píxeles, etc. para capturar el alcance del proyecto a fin de evitar conflictos comerciales potenciales al final del proyecto.
Mi experiencia es que pedirle al cliente (usuarios finales) que realice selecciones en muchos detalles pequeños de la GUI al inicio del proyecto solo agrega ruido innecesario a la participación general del cliente.
Iterar la especificación de GUI
Si se trata de un nuevo proyecto de software (como se menciona en la pregunta), a menudo la GUI debe ser descubierta por todos los miembros del equipo, desarrolladores y usuarios finales incluidos. Por lo tanto, sugeriría tomar un enfoque iterativo a su especificación GUI. Comience de manera simple, solo unas pocas capturas de pantalla, que cuando se combinan le permiten al usuario completar algo útil (esto podría ser uno o más casos de uso). Luego, cada iteración posterior agrega detalles más apropiados.
¿Cómo se ve una plantilla de documento de especificación de GUI?
SI la especificación de GUI es por razones de diseño; Recomendaría un documento de Word con la siguiente estructura:
- En la mitad superior de cada página, coloque una captura de pantalla simulada [ a ].
- En la mitad inferior de cada página, escriba lo que considere importante [ b ] sobre la captura de pantalla anterior.
Si la especificación de GUI es por razones comerciales; Recomendaría un documento de Word con la misma estructura que la anterior más lo siguiente:
- Fuente, color, logotipos, ancho de borde de píxeles, glosario, etc. Casi tanto como se puede documentar en el tiempo disponible.
[ a ] Herramientas para generar capturas de pantalla simuladas: Balsamiq , Visual Studio + Snagit con comentarios útiles superpuestos son geniales.
[ b ] ¿Qué es importante? La respuesta breve es "..depende ..." y le corresponde al diseñador de la GUI y a los usuarios finales colaborar para descubrir e identificar lo que es importante.