6. Qué cosas podrían pasar.
LOL
- Llega un proyecto con pocas horas
para diseño o desarrollo.
- Se hace un trabajo del que no
estamos orgullosos por mucho que se
intente.
- Expectativas del cliente son altas
como siempre.
- Tenemos que pensar en el siglo en el
que vivimos.
- Dispositivos que quiere el cliente.
7.
8. Revisando el diseño aceptado por
el Cliente, sin validación previa
entre el Front-end y el Designer.
- Cuando por falta de tiempo, Diseño no
habla con Front o viceversa….
- Cuando nos encontramos funcionalidad
que hay que realizar en poco tiempo y
está demasiado “bonito”....(Misión
Imposible)
- Cuando se pide un responsive de “nivel
Dios” y no hay ni una pantalla responsive
diseñada….
- etc….
9. Cuando el Front-end dice:
¡Claro que si Wapi!
- Calendarios
- Timelines de Redes Sociales Custom
- Megamenús
- Parallax
- Galerías
- etc...
10. Cuando el Front-end se da
cuenta que no fue buena idea
decir tan rápido: Claro que si
wapi…..
- Cuando por falta de tiempo, Front no ha
revisado correctamente el diseño...
- Cuando por orgullo propio hemos dicho
que no hay ningún problema al diseño
realizado… Drupal-Héroes.
- Cuando vemos las horas que tenemos
para realizar todas las tareas…
- Cuando ni por asomo hemos
contemplado el diseño técnico … ¿El
qué? ... eso...
- Cuando no hemos hablado con el
Back-end o Analista para ver su opinión...
- etc...
11. Buscar, desatar el espíritu “Emprendedor” de cada miembro del equipo para conseguir
que nuestras ideas se vuelvan realidad.
Buscar la unión entre IMAGINACIÓN + CREATIVIDAD + AGILIDAD + INNOVACIÓN +
EMPRENDURISMO, conceptos claves que uniéndolos buscan el camino hacia la
implementación, la REALIDAD.
SER CREATIVO PENSANDO EN LOS DEMÁS
12. Diseñar para proyectos Drupal no es tan tan
tan malo...
Enfocar las cualidades de un diseñador UI en
este tipo de proyectos significa pensar en los
demás, oír, aprender, consultar y ejecutar.
13.
14.
15.
16.
17.
18.
19. No nos gusta sentirnos así....
Esto no es diseñar
Esto no es
desarrollar Este es el resultado
muchas veces....
20. Conclusión = Resultado fatídico.
- Rehacer.
- Añadir nueva sección.
- Mantener.
- Cambiar alguna funcionalidad...
- No se ha podido hacer.
- Esto lo hemos cambiado sin consultar
porque nos venía mejor.
- Eso era imposible y lo hemos puesto así.
21. ¿Qué hay que hacer para
disfrutar del Diseño y
del Desarrollo?
- Vivimos en un mundo en el que
adoptamos metodologías, herramientas
y procesos.
- Cuando nos sacan de nuestro mundo de
confort nos sentimos extraños y nuestro
tiempo y frustración aumenta.
- Podemos adoptar acuerdos de trabajo
con nuestro equipo.
- Hacer ver la necesidad del uso de
dispositivos, estrategias, experiencia del
usuario que vamos a necesitar, al igual
que los recursos y reuniones necesarias.
27. - Reuniones diarias del equipo completo o de los
perfiles implicados.
- Perfil de negocio y Product Owner tienen que contemplar estos
procedimientos cuando hablen con el cliente y comentar que esto
ahorraría tiempo = $$$
- UX - BACKEND
- UI - FRONT
- Testing contínuo
- Sistemas de diseño
Metodología
28. Escuchar, mirar,
aprender y luego...,
¡tomar impulso!
Mejorar, optimizar la comunicación D2D
Equipo con un intercambio contínuo que
información
Éxito, satisfacción y trabajo bien
hecho , mío y de mi equipo.
A largo de la empresa
Nos gusta sentirlo, realizarlo y estar orgullosos de ello.
29. “Teams with a continuous exchange
of feedback will build better
products.” Jim Semick, InVision
31. Todos sabemos que siempre hay falta de tiempo, pero todos queremos ser Drupal
Héroes.
Optimizando las herramientas, metodologías sobre la vida de un proyecto dejaremos de
invertir tiempo en pasilleo, dudas, peleas, etc…. Para emplearlo en profesionalizar los
siguientes proyectos. (Ej. no usar tiempo en recortar iconitos con photoshop y poder usar
ese tiempo para realizar pantallas responsives en más disposivos).
Un equipo vivo construye mejores productos, sin olvidar que puedes mantenerte simple
en momentos en los que no dispongamos del tiempo necesario.
Menos es más y viva Drupal.
Resumen y Conclusiones