 |
|
|
|
|
|
Portada | Monotemáticos | Secciones | Desarrolladores | Comunidad | Servicios | Servicios profesionales | |
||
|
||||
|
|
|||
 |
|
 |
||
|
||||
Directorio
|
Manuales
|
Scripts
|
FAQs
|
Programas
|
Artículos Copyleft
|
Actualidad
|
La Cosecha
|
Colabora
Alojamiento
|
Dominios.es
|
Micropagos SMS
|
Buscadores
|
Patentes, marcas
|
Creación web
|
Multimedia
|
Videos
¿De qué sirve el criterio cuando todo el mundo puede opinar?
Decisiones tomadas con falta de criterio suelen condenar a nuestro site a morir a menos que la suerte o casualidad se cruce en nuestro camino. Como formar criterio y aplicarlo.
| Resumen: Decisiones tomadas con falta de criterio suelen condenar a nuestro site a morir a menos que la suerte o casualidad se cruce en nuestro camino. Como formar criterio y aplicarlo. |
Es sólo mi opinión y como tal vale lo mismo que cualquier otra.
No. La opinión de los desarrolladores no vale menos que la de cualquier otra persona. La responsabilidad del éxito del desarrollo recae sobre personas identificables y no sobre el usuario o algún tipo de "ente" externo que no conocemos o controlamos.
El dejar que cualquiera pueda opinar nos puede llevar a la situación donde aspectos críticos del desarrollo (como el ancho de la tabla, el uso de frames, el diseñar una portada donde sólo ofrecemos la selección del idioma) condenen por completo el desarrollo.
El definir lo que es bueno y malo es necesario y no puede quedarse suspendido en el ámbito del "ya veremos", "depende"... es necesario que el equipo de desarrollo disponga de las herramientas para crear criterio y poder aplicarlo.
Conclusión 1: Todos los aspectos del diseño web son críticos para el éxito del site y no podemos dejar que "cualquiera" tome decisiones que pueden condenar el site.
Que sea el usuario el que decida
El usuario como "paciente" nos dirá que le duele, que le molesta, pero son los "doctores" los que pondrán soluciones y podrán determinar si el "dolor" está causado por lo evidente o si el problema viene de otra fuente.
El usuario en el laboratorio dirá que le parece mal, mejor y en el mejor de los casos si somos capaces de probar 2 versiones podrá decir cual es más adecuada, pero dificilmente podrá aventurar soluciones del tipo "pues yo este menú lo pondría aquí y le cambiaría el nombre por esto otro".
Por otro lado, tenemos que tener siempre en cuenta que el usuario en laboratorio es un usuario motivado y no padece la lacra de interés que existe en el mundo real donde las sesiones son de 2 páginas vistas y el abandono del site al 3 click es del 75%.
Conclusión 2: El usuario es clave para detectar problemas, pero es el equipo de desarrollo el que encontrará las soluciones.
Quién soy yo para decidir...
Si eres la persona responsable del proyecto y eres la persona que toma las decisiones sobre lo que va y no va, necesitas ser capaz de saber lo que es bueno, lo que es malo y ser capaz de cortar por lo sano ideas sin fundamento.
El proceso hasta llegar a ser capaz de distinguir pasa por la experiencia directa en el desarrollo. Es imposible tomar decisiones si no se ha participado en el desarrollo de forma directa y no se han evaluado las consecuencias de los actos.
El basarse en suposiciones, ideas, textos (como este que estás leyendo) es erroneo. Es necesario (esencial) el tocar el producto, moldearlo y ver las reacciones que conseguimos.
Conclusión 3: Si tu desarrollo web es crítico para tu empresa, domínalo y para ello es necesario conocer todos los detalles del mismo. Confía en tu equipo y trabaja con ellos.
Crear el laboratorio
Dentro de las empresas (y especialmente en las corporaciones) es necesario disponer de un laboratorio donde el equipo encargado de la web pueda experimentar con prototipos rápidos soluciones, nuevos productos o ideas.
Es esencial que este laboratorio cuenta con equipos capaces de desarrollar en HTML soluciones reales de baja fidelidad que puedan ser probadas por usuarios de forma directa y en condiciones "reales" de uso (es decir, navegador, links, formularios, etc...)
No se debe depender de colaboradores externos para cada desarrollo ya que ese tipo de procesos suele cortar de raiz la posibilidad de testeo constante ya que la cadena de mando se prolonga demasiado haciendo dificil el trabajo en equipo.
Tampoco es necesario tener muchos medios para tener un laboratorio. Dedicar una carpeta dentro del servidor y en ella ir probando nuevas soluciones y disponer de un par de amigos para porbarlas puede ser suficiente para la mayoría de las casos.
Conclusión 4: Probar, probar, probar...
La necesidad de poder tocar el código en caliente
Muchos sites son desarrollados desde equipos donde la burocracia suele matar la posibilidad de mejorar el site en aspectos críticos.
Es necesario desarrollar con el control del site en nuestras manos. Ser capaz de probar soluciones, confirmarlas y aplicarlas en ciclos breves que favorezcan el ganar "momento" y el mostrar respuestas a las demandas de los usuarios.
Conclusión 5: Un site vivo se siente y ayuda a ganar usuarios.
Seguir navegando a partir aquí:
+ 1 manual relacionado+ 1 categoria relacionada
+ 2 comentarios (Añadir)
| Autoría, licencia y acciones sobre este artículo | ||||||
|
Informe de César Martín*
URL: http://www.unosaficionados.com Este artículo tiene licencia Copyleft. Puedes reproducirlo citando al autor y enlazando su página web. * Para consultas técnicas utilizar la lista de correo.
|
Manuales relacionados con este artículo
Dentro de Usabilidad en la web
Anterior: Destruir 2 mitos del diseño web
Categorias relacionadas
A través de las categorías de nuestro directorio se pueden encontrar otro tipo de recursos relacionados con este artículo:
+ Entrar en Usabilidad Comentarios de los visitantes
| Los comentarios de los visitantes son para ampliar la información del artículo. Cualquiera puede participar. |
| Se muestran 2 comentarios revisados |
Comentario de José Luis Tinajero Guerrero
06/11/03
Totalmente de acuerdo.
Si un contador tiene un primo con un hospital, y este contador se ha "metido" mucho a la medicina, y a asistido a cirugias con su primo, etc... ya que despues de todo en esto de la salud solamente hay que meterse con ganas y ya ¿dejaría que ese contador le operara el apendice?, y si el cliente sabe de diseño web, tecnologías de información y comunicación, servicios remotos y tcp/ip, ¿por que nos contrató?. Claro que hay que cuidar los aspectos de la mercadotécnia y en algunos casos de la mínima educación, pero estoy convencido de que hay que dejar a los profesionales hacer su trabajo y atender al cliente en todas sus necesidades (que no siempre conoce o detecta adecuadamente -ese es nuestro trabajo-). Gracias. PD. habitualmente no pongo comentarios en ningún boletín, chat, correo, etc... pero este servicio me llamó la atención y me pareció adecuado, tal vez un poco carente de tacto si se quiere manejar de esa forma con el cliente pero eso ya es situación de cada prestador del servicio, mejor decirlo así que no decirlo.
Muy Atentamente.
Licenciado en Computación Por la Universidad Autónoma Metropolitana -México.
José Luis Tinajero Guerrero
Si un contador tiene un primo con un hospital, y este contador se ha "metido" mucho a la medicina, y a asistido a cirugias con su primo, etc... ya que despues de todo en esto de la salud solamente hay que meterse con ganas y ya ¿dejaría que ese contador le operara el apendice?, y si el cliente sabe de diseño web, tecnologías de información y comunicación, servicios remotos y tcp/ip, ¿por que nos contrató?. Claro que hay que cuidar los aspectos de la mercadotécnia y en algunos casos de la mínima educación, pero estoy convencido de que hay que dejar a los profesionales hacer su trabajo y atender al cliente en todas sus necesidades (que no siempre conoce o detecta adecuadamente -ese es nuestro trabajo-). Gracias. PD. habitualmente no pongo comentarios en ningún boletín, chat, correo, etc... pero este servicio me llamó la atención y me pareció adecuado, tal vez un poco carente de tacto si se quiere manejar de esa forma con el cliente pero eso ya es situación de cada prestador del servicio, mejor decirlo así que no decirlo.
Muy Atentamente.
Licenciado en Computación Por la Universidad Autónoma Metropolitana -México.
José Luis Tinajero Guerrero
Comentario de Silcas
05/4/04
Qué gran verdad, amigos.
Quisiera aportar mi granito de arena.
Ahora mismo me encuentro redactando el Libro de Estilo de una super-aplicación web de tamaño descomunal, por clases de usuario, importancia crítica, bla bla bla. Hemos lidiado con toda clase de organismos, empresas burocratizadas, etc.
¿Cómo hemos actuado para tener un libro de estilo definido e inmodificable?
1.- Hacer que el cliente diga sí o no, a través de las actas de las reuniones sin excepción. Se hace el acta, se le envía y se le dice que si en 3 días no hay comentarios se dará por aprobada. Con ésto te quitas de un plumazo el famoso efecto "¿y ese verdeeeeee????"
2.- Sólo hay un responsable de estilo. Él/ella centraliza todos estos aspectos y ni siquiera el director del proyecto puede tomar una decisión al respecto sin pasar por esta persona.
3.- Hacer una maqueta y validarla junto con el libro de estilo. Es un rollo, pero así no hay equívocos en cuanto a qué significa "azul" y qué significa "arial", veremos las reacciones con los combos, y qué opinan del tipo de menú preseleccionado.
4.- Identificar los azules con códigos hexadecimales, los tipos de letra con ejemplos, y hacer una guía de navegación exhaustiva y detallada. Ya sabéis, cortar con hacha y medir con micrómetro. Definir y detallar todo lo posible.
5.- Y todo esto antes de tocar una línea de código, porque si no, vamos listos.
Abrazos a todos,
La redactora feroz
Vuelvo a mi libro.
 | Añadir un comentario del artículo |
| Enlaces: |
| Maestrosdelweb |
Ir arriba
Lectura recomendada  Compra este libro en Agapea, la librería urgente a domicilio. |
||||||||
Tienda DesarrolloWeb
