Como desarrollador, puede ser tentador comenzar a crear funciones y productos. Sin embargo, antes de llevar las cosas al teclado, debe pensar en lo que necesitan sus usuarios. ¿Tiene un proceso para comprender y priorizar las necesidades de los usuarios y los puntos débiles? ¿Cómo puede pivotar o iterar las características de su producto en función de los comentarios de los usuarios y las pruebas de usabilidad?

In esta charla, Veerle, jefe de ciencia de datos en Analytic Health, compartió sobre cómo crear software desde cero desde una perspectiva de diseño centrada en el usuario. Encuentre el video del evento con marcas de tiempo en la primera sección y la transcripción en la segunda sección.

Grabación de eventos virtuales

Creación de software desde cero, el enfoque centrado en el usuario

• 02: 15 Introducción
• 04:54 El proceso ágil de desarrollo de software
• 11:07 Diseño centrado en el usuario (UCD)
• 22:44 Desafíos con el desarrollo de software
• 32:18 Experiencia y consejos del orador
• 44:26 terminar
• 46:33 ¿Preguntas?

Blog de eventos y transcripción

Host: Podemos empezar. Hola a todos, bienvenidos a Codementor Events. Para aquellos de ustedes que se unirán a nosotros para el segundo evento, bienvenidos nuevamente. Mi nombre es Maggie. Gracias de nuevo por unirse hoy. Es realmente genial tenerlos a todos aquí con nosotros, y estoy muy emocionado de estar aquí con nuestra oradora Veerle, para escucharla, compartir más sobre su experiencia, crear software desde cero y un enfoque centrado en el usuario.

Si tiene alguna pregunta durante el evento, siéntase libre de levantar una mano virtual para hacérselo saber. Alternativamente, también puede escribirlos directamente en un chat y nos aseguraremos de llegar a tantos como sea posible en la sección de preguntas y respuestas al final. Veerle, el escenario es todo tuyo.

Verle: Hola a todos. Gracias Maggie por darme la bienvenida. Hoy les contaré algo sobre la creación de software desde cero, el enfoque centrado en el usuario. Permítanme compartir mi pantalla y abrir mi presentación.

Como dijo Maggie, y en el chat que se ha dicho, si hay alguna pregunta, levante la mano y siéntase libre de interrumpirme y responderé la pregunta de inmediato. Después de la presentación, también tendremos una sesión de preguntas y respuestas. Entonces, si hace sus preguntas a través del chat, las responderemos más tarde.

Verle: Entonces, hoy, construir software desde cero: el enfoque centrado en el usuario. ¿De qué vamos a hablar realmente hoy? En primer lugar, daré una breve introducción. Sabes quién está hablando, también algo más sobre mi empresa y luego entraremos en un proceso de desarrollo de software ágil y cómo se ve. Luego, hablaremos sobre los desafíos que a menudo surgen cuando se crea software. Luego hablaré de mis experiencias y aprendizajes que sentí que tenemos en nuestra propia empresa. Haré un resumen rápido. Y luego, como dije, en la sección de preguntas y respuestas, responderé todas sus preguntas. Después de esta presentación, también compartiré las diapositivas de la presentación con ustedes. Entonces, si hay algo de lo que le gustaría tomar notas, tenga en cuenta que compartiré todo después.

Introducción

Verle: Entonces, ¿quién soy yo? Soy Veerle. Estoy llamando desde los Países Bajos hoy. Vivo allí y me gradué como científico de datos en 2015 de la universidad de Dilbert. Después de eso, comencé a trabajar en varias empresas como científicos de datos. Trabajé en una gran empresa de energía. Ese fue mi primer trabajo. Y luego, en 2018, entré en el sector de la salud o el sector farmacéutico como científico de datos.

Cuando estaba trabajando allí, tuve la idea de montar mi propia empresa. Así que fundé mi propio negocio, Hypebright, e hice una consultoría de ciencia de datos allí. Y durante ese tiempo conocí a mi socio comercial actual, Greg, con quien ahora dirijo Analytics Health. Soy un desarrollador. Desarrollo principalmente en R y Shiny, pero también en Node y Vue.

Esa es una descripción rápida básica de mí. A continuación, un poco más sobre nuestra empresa. Entonces, junto con mi socio comercial, Greg, y nuestra jefa de operaciones, Jana, desarrollamos herramientas y aplicaciones web para el sector salud. Por lo tanto, recopilamos y analizamos datos de atención médica para recuperar valor de los datos, porque creemos que podemos acelerar la innovación en atención médica al brindar acceso a fuentes de datos de alta calidad. Y proporcionando a los profesionales de la salud las herramientas que necesitan para analizar los datos. Recopilamos datos de atención médica del Reino Unido a diario, todo a través de fuentes de datos de código abierto. Y también usamos datos de ventas internas de compañías farmacéuticas. La mayoría de las herramientas que desarrollamos están desarrolladas en R, por ejemplo, tenemos aplicaciones Shiny y tenemos API que también están dentro de R. Además de eso, tenemos aplicaciones en Node y Vue.

Verle: Como puede ver, tenemos tres tipos de aplicaciones. Tenemos Pharmly Analytics y Pharmly Cloud Data, y luego tenemos Pharmly Portal. Pharmly Cloud Data es nuestro mercado de datos de atención médica, por lo que este es el lugar donde puede tener acceso a todas sus fuentes de datos de atención médica de alta calidad en el Reino Unido. Ahora, Pharmly Analytics es una aplicación construida sobre esos datos para brindarle realmente información sobre los datos, y Pharmly Portal es el lugar donde básicamente se unen todas esas aplicaciones. Esa es básicamente nuestra página de inicio, va encima de nuestros productos nuevos de Pharmly, también desarrollamos algunas aplicaciones dedicadas para algunos de nuestros clientes, que son principalmente compañías farmacéuticas.

El proceso ágil de desarrollo de software

empecemos el proceso de desarrollo ágil. Entonces, ¿cómo se crea software utilizando un enfoque centrado en el usuario? Y ahora la primera pregunta que me viene a la mente, ¿por qué necesitamos un proceso para empezar? Porque podemos construir software, ¿verdad? Podemos saltar, comenzar a codificar y crear características, pero necesitamos un proceso porque el proceso lo ayuda a alinear las expectativas entre los desarrolladores, los miembros de su equipo, las partes interesadas o los usuarios, pero también lo ayuda a formalizar cómo usted debe lidiar con nuevas solicitudes o con errores o con nuevos pensamientos.

Si tiene un proceso implementado o un plan, al final evitará una repetición innecesaria. Además de eso, te ayuda a mantenerte dentro del presupuesto y, obviamente, un proceso te ayuda con el plan. Así que creo que tener un proceso es una muy buena idea si estás construyendo tu software.

Y luego la pregunta, ¿por qué nos importa como desarrollador?

Verle: ¿Por qué nos preocupamos por tal proceso? ¿Por qué nos preocupamos por estar centrados en el usuario? Porque después de todo, lo único que hacemos es codificar, ¿no? Pero, según el contexto, es posible que usted, como desarrollador, participe en todas las partes del proceso. Entonces puedes ser parte de un equipo con, digamos, 20 desarrolladores y un par de diseñadores de UX y docenas de gerentes de proyecto y todo eso. Entonces su función será obviamente muy diferente de una función, por ejemplo, en nuestra empresa, donde tenemos un pequeño equipo de desarrollo de solo 1-3 desarrolladores en los que está muy cerca del usuario. Entonces, como desarrollador, dependiendo del negocio en el que se encuentre, puede estar involucrado en diferentes partes del proceso.

Además de eso, si conoce el proceso y si comprende el proceso, es posible que también se sienta menos frustrado cuando cambien algunas decisiones en el camino. Creo que todos reconocemos la sensación de que desarrollamos algo y luego, dos semanas después, debe cambiar. Ya sabes, hiciste algo, pusiste esfuerzo en ello. Y luego, un par de semanas después, todo debe ser 180 grados diferente. Eso es muy frustrante. Y especialmente si no sabes de dónde viene eso, entonces no te ayuda a entender por qué necesitas cambiar eso. Entonces, también estar involucrado en el proceso te hace ver el panorama general. Te hace entender por qué estabas haciendo las cosas. Y por qué te estás desarrollando de cierta manera.

Verle: Entonces creo que entregas software en equipo, siempre. No importa cuán pequeño o grande sea ese equipo, están construyendo un producto juntos. Así que creo que es más que justo que estés involucrado en el proceso. Que todo el equipo está pasando para construir ese producto de software. Y no solo es importante para sus grandes proyectos de software o solo cuando trabaja en una empresa, sino que también sus proyectos paralelos pueden beneficiarse de un enfoque adecuado porque incluso sus proyectos paralelos, puede administrarlos de tal manera que pueda entregar al final a productos con los que sus usuarios están satisfechos.

No creo que lo haya mencionado todavía, pero yo mismo soy un maestro de scrum. Así que tengo mucha experiencia con la metodología ágil y, sinceramente, me encanta y usamos esta empresa interempresarial para optimizar nuestros proyectos y definitivamente también la recomendaría si está desarrollando software.

Verle: ¿Así que qué es lo? Si analizamos qué es el desarrollo ágil de software, básicamente estamos hablando de pequeños ciclos o pequeñas iteraciones que está haciendo. Por ejemplo, aquí ve una iteración de este tipo en la pantalla. Comienza una iteración planificando y me gusta, básicamente descubriendo cuáles son los requisitos. Luego comienzas a diseñar esa función. Entonces empiezas a codificar. Luego lo suelta, recibe una retroalimentación sobre esta función y lo hace todo de nuevo. Entonces, este ciclo constante de pequeñas iteraciones, normalmente un ciclo toma como dos semanas o algo así. Este pequeño ciclo de iteraciones lo mantiene básicamente involucrado con sus usuarios y partes interesadas. Y es una excelente manera, y una forma eficiente de proporcionar software tangible, como al principio. Porque cada dos semanas intentas lanzar algo, aunque sea como un pequeño botón o un cambio de estilo de tu aplicación o lo que quieras lanzar lo más rápido posible para obtener sus comentarios. Y eso es muy importante si está desarrollando un software centrado en el usuario.

¿Por qué necesitamos ser ágiles?

Verle: Como dije, es una forma eficiente de proporcionar software tangible lo antes posible. Como cada dos semanas o algo es como normal. Debido a que es como trabajar en estas pequeñas iteraciones, como recopilar comentarios constantemente, como cada dos semanas, también puede incorporarse rápidamente a los requisitos cambiantes de los usuarios.

Y creo que tener este tipo de ciclos y herramientas te da mucha transparencia y retroalimentación constante, para que puedas mejorar tus productos. Además de eso, normalmente tiene una duración tan ordenada, porque está recopilando comentarios, realmente está interactuando con sus partes interesadas y sus usuarios porque necesita probar el software si a los usuarios les gusta.

Así que hay una gran participación allí. También es excelente para las expectativas porque normalmente, ya sabes, exactamente, en las próximas dos semanas, vamos a hacer esto y aquello. Y luego, sus partes interesadas saben que, al final de estas dos semanas, puedo esperar que este botón esté aquí o allá donde estén presentes estas funciones.

Verle: Y creo que es menos desalentador trabajar en este tipo de ciclos más pequeños en comparación con los grandes proyectos. Porque si tienes un proyecto grande y digamos, este proyecto te tomará ocho meses, hazlo, diviértete. Quiero decir, creo que es bastante desalentador si dices, bueno, ocho meses, ¿qué tengo que hacer? ¿Cómo voy a organizar eso? Así que córtalo en trozos más pequeños. Luego, al lado de ser ágil. Existe esta otra filosofía con la que si estás un poco involucrado, en realidad lo sabrás y lo llamamos el diseño centrado en el usuario. El diseño centrado en el usuario es como otra metodología junto a ágil, que también tiene que ver con sus proporciones aquí.

Solo el enfoque está realmente en el usuario y se trata de diseñar sus características y funcionalidad para que básicamente se adapte a los usuarios lo mejor posible. Entonces, primero van a ver, está bien, ¿qué necesita mi usuario? Intenta empatizar con ellos y va a definir como los requisitos de una característica o funcionalidad que van a idear o hacer ideas al respecto.

Es una lluvia de ideas, luego estás construyendo un prototipo y luego lo vas a probar. Este principio de diseño centrado en el usuario aún no se trata de codificación, pero se trata de, ¿este futuro, cómo va a funcionar esto para mi usuario? ¿Les gustará? ¿Y cómo puedo diseñar mejor? El enfoque es diferente aquí.

Diseño centrado en el usuario (UCD)

Verle: ¿Por qué necesitaríamos algo como UCD o el diseño centrado en el usuario? Bueno, porque básicamente minimiza las conjeturas al proporcionar un mecanismo contra el cual las decisiones de diseño se pueden encontrar en las edades que esto se debe a que constantemente se te ocurren diseños, que se los devolverías a tus usuarios para que ellos puedan realmente comprender. O puedes entender si a tus usuarios les va a gustar o no. Entonces, al final, un UCB le brinda un producto más útil y significativo. Y eso es porque hiciste todas esas pruebas y obtuviste esa retroalimentación. Por lo tanto, también minimiza el lugar donde trabaja. Porque si sabe lo que sus usuarios van a pensar en función, entonces, obviamente, sus comentarios serán del estilo de, wow, esto es genial. Eso te ahorra algo de trabajo. Proporciona una forma de ofrecer experiencias de calidad. Entonces hablamos de ser ágiles y de este diseño centrado en el usuario.

¿Cual es la diferencia? ¿Ser ágil en realidad está centrado en el usuario?

Verle: Honestamente, hablamos de toda esta discusión entre Agile y UCD. Pero lo que quería decirles hoy es que si observan las dos filosofías que verán en Agile, hay un enfoque en el lanzamiento rápido de cosas, asegurándose de que sean clientes satisfechos y el equilibrio de capital de UCD sería como, está bien, necesitamos crear o pensar en nuestros usuarios finales.

Necesitamos asegurarnos de que tengan la mejor experiencia posible al usar nuestros productos. Y creo que si puede combinar los dos, si puede combinar la metodología de ser ágil, como liberar rápidamente comentarios constantes, enfóquese en uno mismo tangible. Y si puede combinar UCB con el enfoque extremo en estar bien, todo lo que diseñe debe ser adecuado para mis usuarios, porque van a usar el producto.

Creo que si estás uniendo los dos, eso es genial. Y lo que también quiero mencionar es que, lo más increíble de estas filosofías, no es necesario que las veas como fijas. Por ejemplo, si Agile le prescribe que realice los pasos uno, dos y tres, no significa necesariamente que deba seguirlo al 100 % con todo detalle.

Eso es lo mismo para UCB. Puede seguir todos estos pasos con todo detalle y entregarse por completo a la metodología, pero no ayuda. Se trata más del pensamiento detrás de esto. Y lo único que quiere el desarrollo ágil es asegurarse de estar cerca de su usuario, cerca de la realidad.

Verle: Al tener estos ciclos cortos, he ido pidiendo retroalimentación y es solo para mantener la mente para que puedas combinar los dos. Por eso siempre digo que tienes este proceso ágil de UCD que puedes seguir. Y este es solo el proceso. Y como dije, no veo que esté 100 % solucionado, pero este es el proceso que puede seguir para tomar conciencia.

Así que primero empiezas reuniendo requisitos para que tengas un sentido claro. Esto es probablemente lo que quiere mi usuario. Esto es lo que buscamos, mis partes interesadas quieren, así que esto es lo que debemos hacer. Debe encontrar una forma estandarizada de documentar básicamente los requisitos para que todos en su equipo conozcan los requisitos para saber cómo se ven.

Entonces siempre empiezas con el diseño de las cosas. Entonces, si tiene un requisito, siempre es bueno tener esa representación visual que representa cuál es el requisito. No es necesario que sea una estructura alámbrica completa o un trabajo completo, tal vez incluso un pequeño boceto en particular que haremos. Siempre que tenga algo en lo que pueda mirar, y esto lo ayudará a guiar lo que sea que esté buscando.

Verle: E incluso si tiene un boceto, puede presentárselo a sus usuarios y decir, oye, ¿qué piensas de eso? Sabes, especialmente, si puedo hablar por mi negocio, desarrollamos un software dedicado para ti. Así que conocemos bastante bien a nuestros usuarios. Hablamos con ellos como cada dos semanas, y luego es muy fácil.

Si tienes un boceto, aunque sea un boceto rápido para mostrarles y luego ver, oye, ¿ves esto funcionando? ¿O te gusta esto? Y luego, cuando tenga el diseño, puede comenzar a profundizar en el código. Por lo tanto, puede comenzar a construir y siempre recomendaría a los adultos las mejores prácticas de codificación y hacer que el código sea coherente en todo su equipo.

Asegúrese de que en cualquier equipo en el que esté tenga un conjunto estándar de reglas que siga coherentemente, pueden ser cosas como convenciones de nomenclatura, estilo de código y ese tipo de cosas, pero solo asegúrese de que sea, no importa si la persona A o la persona B escribieron el código, pero tienes un flujo de código.

Verle: Veo una pregunta de Jen.

Jen: Levanto la mano por uno de nuestros asistentes. Así que Hyung, lo siento. Lo siento si pronuncié mal tu nombre, ¿querías levantar la mano y luego preguntarle a Veerle? Alguien puede quitarle el silencio y ver, está bien. Entonces, ¿puedes oírme ahora?

Asistente: Sí. Así que solo tenía una pregunta. No quiero interrumpir porque estás en curso, pero no quería perderme este punto al final, si hubiera ido al final. Entonces, solo quiero verificar su diseño centrado en el usuario, que es como un ciclo más pequeño de obtener durante el uso de comentarios antes de hacer un ciclo completo.

¿Correcto? Entonces, ¿tiene algún consejo para un buen número de usuarios finales? Como 5 o 30? Quiero decir, esto es algo con lo que también estoy luchando porque yo mismo soy un desarrollador independiente. Y también veo que solo tenéis un equipo de tres, por lo que reunir a mucha gente logísticamente es muy difícil. Entonces, ¿tiene algún buen consejo para la cantidad de usuarios finales?

Verle: Sí. Así que eso también depende del contexto. Entonces nuestras aplicaciones, por ejemplo, tienen menos de 100 usuarios. Eso significa que no vamos a pedirle a 100 personas sus comentarios. Por ejemplo, si tiene miles de usuarios, 100 podría ser un número razonable. Por lo tanto, depende de qué tan grande sea su aplicación, cuántos usuarios emiten a quién se le pregunta si puede.

Apuntaría a, bueno, en algún lugar a lo largo de las líneas, 1-5% de su base de usuarios. Y luego no, y también debe considerar cuidadosamente para qué características va a hacer una investigación completa, porque a veces puede ser suficiente para tomar la investigación existente. Por ejemplo, si necesita pensar en los colores de los botones o dónde colocar los botones de cierre y cosas por el estilo, puede confiar en la investigación existente y, de lo contrario, simplemente deletrear, vea que necesita un equilibrio entre, está bien, ¿va a funcionar esta función? ser realmente grande y realmente importante y realmente fundamental? Tal vez debería pedir una muestra más grande de mi base de usuarios, pero todo depende realmente del contexto. ¿Eso responde un poco a tu pregunta?

Asistente: Sí, eso creo. Lo pregunto porque, en mi caso, me pongo en contacto con los usuarios finales a través del marketing directo de Instagram, ya sabes, por lo que a veces es muy agotador y lleva mucho tiempo, pero supongo que realmente depende. Gracias por su respuesta.

Verle: Eres bienvenido. Bueno. Otra mano.

Asistente: Lo siento, solo para dar seguimiento a eso. Sé que soy parte de Komen, pero solo un poco, dijiste, ya sabes, realmente depende de la característica y como 1-5%, en términos de metodologías, ¿usualmente usas, digamos como encuestas o haces ¿Distribuyes encuestas a como el 5% de las personas en esto? No sé, el 10% de eso para hacer entrevistas a usuarios y cosas así.

Verle: Sí. Así que en realidad tenemos mucha suerte con nuestros usuarios porque nuestros usuarios están muy involucrados en nuestros productos. Desarrollamos productos muy especializados, para un número limitado de personas. Así que tenemos el lujo de simplemente reunirnos con ellos, presentar lo que tenemos en mente y recopilar sus comentarios.

Y recibiremos todos estos comentarios de ellos, pero eso es un lujo que tenemos. Si tiene una aplicación realmente grande con miles de personas, por ejemplo, y estará disponible en la tienda de aplicaciones, será una historia diferente porque es muy difícil recopilar comentarios de las personas en ese momento.

Pero luego, para audiencias más grandes, haría algo como pruebas A/B o configurar encuestas. Pero eso, de nuevo, depende realmente del contexto, lo que podrías hacer mejor.

Verle: ¿Bueno, dónde estábamos? Así que estaba en la etapa de prueba. Si desarrolló su función, obviamente también es muy importante que la pruebe. Porque no puede lanzar todo en producción y luego esperar lo mejor que necesita para probarlo. Puede usar pruebas unitarias para desarrolladores, pero también solo algunas pruebas de usuario. Puede obtener algunos usuarios y recopilar algunos comentarios.

Luego puede liberar, pero liberar sabiamente porque estos ciclos de dos semanas están realmente destinados a liberar lo más rápido posible, ya sabes, hazlo lo más rápido posible, queremos ver los resultados ahora. Pero también debes hacerlo sabiamente. Así que asegúrese de que todo lo que publique sea de alta calidad, porque solo puede ofrecer un producto de software centrado en el usuario si también ofrece un producto de alta calidad. Así que asegúrese de que todo lo que publique esté realmente centrado en el usuario y le brinde la mejor experiencia posible.

Y luego obviamente muy importante. Tómese el tiempo para recibir comentarios. Lo que veo que sucede demasiado en esta metodología ágil es decir, tenemos este ciclo de desarrollo. Liberamos algunas características. Ahora es el momento de los fines de semana por cuestión de velocidad, pero tómese su tiempo para recibir comentarios sobre las funciones que acaba de lanzar para que pueda mejorarlas o incorporar estos comentarios en ciclos posteriores de su desarrollo. Así que tómate el tiempo para eso.

Desafíos con el desarrollo de software

Verle: Entonces, un par de desafíos que tienes con el desarrollo de software. Uno de ellos es un concepto muy conocido conocido como deuda técnica. También se conoce como deuda de diseño o deuda de código. Es un concepto en el desarrollo de software que refleja el costo implícito de los costos adicionales de reelaboración al elegir una solución fácil.

Ahora, en lugar de un mejor enfoque, si tomamos. Y esto es algo que es realmente un riesgo cuando estás haciendo un desarrollo ágil. Porque como dije, el desarrollo ágil suele tener como objetivo lanzar lo más rápido posible. Hazlo lo más rápido posible. Queremos ver resultados tangibles después de esas dos semanas, pero a menudo lleva a los desarrolladores a tomar la decisión más fácil.

Al final te vas a arrepentir. Porque si toma decisiones ahora y construye sobre eso, entonces está acumulando más y más deudas. Y es muy difícil pagar eso. Entonces, Ward Cunningham, es uno de los autores del manifiesto ágil. Una vez dijo que algunos problemas con el código son como una deuda financiera, por lo que está bien pedir prestado contra el futuro siempre que pague. Ward usó este término como una metáfora y lo llamó deuda técnica y ha cobrado impulso desde que creo que todos los desarrolladores de software conocen este concepto, y sigue siendo un problema real en el mundo de hoy porque lo vemos todo el tiempo.

Verle: Entonces, ¿qué causa realmente esta deuda técnica? Bueno, uno de ellos es como por definición y requisitos, plazos demasiado ajustados, demasiada presión. Como dije, si todo está dirigido y dirigido lo más rápido posible, es posible que busque soluciones más fáciles. Y también está subestimando el tiempo que lleva completar una tarea.

Porque si usted, especialmente, si trabaja en estos ciclos ágiles por adelantado, planifica, esta tarea me llevará muchas horas. Y lo que pasa es que subestimamos el tiempo. Y luego, al final, hay alguna crisis o algún estrés para llegar a la fecha límite que elegimos para la solución fácil.

También es una falta de conocimiento y una falta de prueba. Entonces, si resume todo esto, las causas de las deudas técnicas son en realidad para el proceso de desarrollo de software. Si se asegura de tener un proceso de desarrollo de software sólido, si tiene en cuenta todas estas cosas, entonces puede minimizar la cantidad de deuda técnica.

Deuda técnica, todos la hemos visto. Y solo le llevará más tiempo crear funciones además de su producto. Es peligroso y dañino para su producto y necesita prevenirlo. Y como desarrollador, también juegas un papel en esto. Tiene la función de educar al resto de su equipo y también tiene la función de reconocer el riesgo de la deuda técnica.

Experiencia y consejos del orador

Verle: Entonces, como desarrollador, si está trabajando en un equipo, tenga cuidado. Ahí es cuando estás haciendo una elección, piensa por ti mismo, ¿es esta la elección fácil porque quiero entregar esto lo más rápido posible? ¿O es la mejor opción? Porque, nuevamente, deudas técnicas, sus usuarios verán eso porque si sus usuarios esperan una experiencia 'wow' de su aplicación, pero le lleva, no sé, meses crear este botón adicional, porque ha elegido un marco que no es adecuado para él, entonces sus usuarios no se beneficiarán de él.

Luego, otro desafío que a menudo tenemos cuando estamos haciendo un desarrollo de software ágil es, está bien, todo está bien. Y todo este enfoque centrado en el usuario y hacer lo que el usuario quiere, pero desafortunadamente el usuario no siempre sabe lo que realmente necesita porque hay un, ¿qué quieren los usuarios versus qué necesitan los usuarios?

Verle: Entonces, un usuario puede decir, "oh, quiero X", pero es posible que el usuario no necesite X, sino Y. Así que imagínese como hace un par de años, si no sabía que necesitaba un iPhone, pero ahora lo hacemos. , ya sabes, así es exactamente como funciona. No sabemos lo que necesitamos y si está creando software, es su trabajo básicamente resolverlo.

Debe tratar de averiguar qué es lo que realmente necesita el usuario o la parte interesada en lugar de simplemente entregar artículos en el camino, porque eso es muy fácil, especialmente las partes interesadas comerciales que podrían no ser las mismas que los usuarios reales de los productos podrían simplemente decir, está bien , dame esta característica y esa característica y esa característica.

Y entonces estamos teniendo un buen producto. Pero siempre esfuércese por ser como el pensador crítico y también pregunte si esto es realmente lo mejor para nuestro usuario. Y, de nuevo, esto vuelve a, si desea crear un enfoque centrado en el usuario, necesita comprender a su usuario y cómo puede hacerlo, mientras que también puede hacer preguntas. Así que preguntas de sus propias preguntas realmente.

Verle: Bueno. Así que quieres este, este botón en tu episodio. ¿Por qué, por qué lo necesitas allí y cómo te ayudaría en tu vida diaria? En lugar de, si está diseñando una aplicación para comprar comestibles en línea, podría decir: ¿Por qué compra comestibles en línea?, pero también puede hacer otras preguntas, como, ¿qué hace cuando compra comestibles en línea?

¿Qué haces antes de ir de compras en línea? ¿Qué haces después de ir de compras? ¿Qué no te funciona cuando estás comprando comestibles, o con quién estás cuando compras comestibles en la fila? ¿A quién consulta para pedir consejo? Por ejemplo, puede hacer todo tipo de preguntas sobre eso para comprender realmente que esto es probablemente lo que mi usuario necesita. En lugar de simplemente crear una aplicación en la que puedan comprar comestibles.

Luego, otro desafío obviamente es elegir el marco correcto porque si comienza con un gran proyecto de desarrollo de software, en las primeras etapas, ya necesita elegir el marco y qué marco aquí.

Quiero decir, ¿vas por Vue o vas por React? ¿Vas por una aplicación Shiny? Hay tantos marcos que puede elegir. Entonces, ¿qué deberías elegir realmente? Porque esto al final también va a determinar tu deuda técnica. Porque si comete un error al principio al elegir el marco, es posible que sea porque es el marco más fácil o es el marco sobre el que tiene más conocimiento. Puede terminar construyendo algo que no es adecuado para usted. Entonces, las cosas que quizás desee considerar y lo más importante en el desarrollo de software centrado en el usuario, sus usuarios. Piense primero en cómo sus usuarios van a usar los productos, cómo van a abrirlos en sus PC. ¿Cómo lo van a ver en el móvil? Y en función de eso elegir el marco que mejor se adapte a las necesidades.

Verle: Por ejemplo, desarrollamos nuestro Pharmly Portal, que es básicamente un portal con todo tipo de cosas. Aplicaciones más pequeñas. Eso es porque nuestro modelo o modelo de precios dirá, está bien, los usuarios o clientes pueden elegir diferentes módulos. Así que podrían ir desde el módulo A, B y C, o podrían ir solo por el módulo A o solo por el C. Así que pensamos, ¿cuál sería la mejor forma de hacerlo? ¿Qué marco podríamos elegir mejor para hacer eso? Al final, elegimos micrófonos y estructura. Y con esta estructura de micrófono, tenemos como todas estas aplicaciones independientes, que son básicamente nuestros módulos.

Y luego, estas son como mini aplicaciones independientes. Por así decirlo, y hace que sea muy fácil para nuestros usuarios elegir básicamente un paquete en el que decir, solo quiero esta pieza y esa pieza y esa pieza, y quiero tener acceso a ella. Y es por eso que tomamos la decisión, por el bien de nuestros usuarios.

Estructura, pero para usted, puede parecer totalmente diferente porque todo depende de su contexto y sus usuarios. Entonces, además de sus usuarios, es posible que desee echar un vistazo, obviamente, a la comunidad de desarrollo. ¿Se habla mucho sobre el marco que está eligiendo? ¿Hay suficientes personas activas? Si no sé nada, quiero buscar el desbordamiento de pila.

Verle: ¿Puedo realmente encontrar algo en el desbordamiento de pila? Y es realmente importante que se mantenga el soporte de los desarrolladores del marco o de otros desarrolladores, obviamente cosas como si hay suficiente documentación técnica. ¿Es fácil de entender? ¿Es sostenible? Y obviamente necesitas mirar a tu equipo.

Es posible que desee crear una aplicación y reaccionar, pero nadie en su equipo sabe acerca de las deudas. Entonces esa también es otra opción sólida para ti, ¿verdad? Así que todo es un equilibrio entre, mientras que no me gustó. ¿Y el marco actual de vanguardia en la comunidad de desarrollo de hoy en día en comparación con lo que quieren mis usuarios y lo que es más adecuado para ellos en comparación con lo que puedo hacer para cada uno?

¿Tengo las habilidades para nombrar recursos?

Sí. Luego llego a nuestros aprendizajes porque teniendo tu propia empresa, aprendes mucho. Puedo decirte eso. Hemos aprendido mucho del desarrollo de software. Hemos aprendido mucho de cometer errores. Todavía estamos aprendiendo mucho y solo quiero compartir aprendizajes similares con ustedes y nuestras propias experiencias, para que también puedan beneficiarse de eso.

Verle: La primera pregunta es, está bien, somos un equipo pequeño. Sí, somos un equipo pequeño. Entonces, ¿podemos hacer un desarrollo ágil? Y sí, puedes. Quiero decir, ser un equipo de 10 o 50 personas para implementar como una metodología ágil o una forma ágil de pensar que puede ser de cualquier tamaño. Y como dije antes, puede adaptar la metodología y sus procesos a sus entornos específicos porque el contexto importa, ya sabe, para nosotros en nuestra empresa, una empresa nueva con un equipo relativamente pequeño de personas, cosas y soluciones puede verse diferente a una empresa establecida que ha estado allí durante 25 años y tiene múltiples equipos de desarrollo.

Así que el contexto es realmente importante. Cuando está implementando cualquier cosa, realmente cualquier proceso de desarrollo de software que elija, pero puede hacerlo. Sinceramente, me encanta hacerlo incluso en un entorno tan pequeño, porque te mantiene enfocado como los pequeños ciclos de liberación constante y te ayuda a ver resultados tangibles rápidamente.

Por eso me gusta tanto. Hacemos todo como en pequeños ciclos, pero obviamente no es así como comenzamos de inmediato. Entonces, digamos que recién está comenzando con este gran proyecto para un cliente o está construyendo un nuevo esfuerzo desde cero. Obviamente no estás saltando a estos ciclos cortos de sprint como los llamamos de inmediato.

Verle: Lo que hacemos normalmente es comenzar con varias reuniones iniciales. Entonces eso es, solo tenemos reuniones de lluvia de ideas sobre, ¿qué va a hacer la aplicación? ¿Qué aspecto tendrá? También tenemos reuniones sobre, ¿cuál es la planificación a largo plazo? Porque la planificación de dos semanas no va a ser suficiente cada vez que necesite ir.

Necesitas saber. En tantos meses voy a lanzar este producto. O dentro de tantos meses, voy a comercializar este producto y tendremos reuniones de lanzamiento con y sin nuestros accionistas. Así que es sólo nuestro equipo central. Hablamos sobre el nuevo proyecto, pero también con nuestros stakeholders para intercambiar ideas con ellos.

Entonces tenemos, como, normalmente lo que hacemos es como este gran diseño. Así que comenzamos con bocetos y luego tenemos un diseñador de UX que nos ayuda de vez en cuando y le permitimos convertirlo en wireframes y así tuvimos un diseño amplio. Así es como se ven los solicitantes. La mayoría de las veces también llevamos este diseño a nuestros clientes: “Oye, hemos diseñado esto. Entonces piensas, esto es lo que haces de manera diferente”. Así que es muy valioso tener eso y asegurarse de mantener los diseños en esa marca, porque si está recopilando comentarios en el camino, y si está llevando sus diseños a sus usuarios y si dicen, bueno, no, yo , no veo cómo funcionaría eso o lo que sea, especialmente.

Verle: Si tienes un producto dedicado. Es decir, hacemos productos para empresas farmacéuticas que tienen necesidades muy específicas y la empresa farmacéutica no es la otra. Entonces, para nosotros, es muy importante mantener los diseños dinámicos y cambiarlos a medida que avanzamos. Y luego, obviamente, antes de comenzar, debe decidir sobre su marco y no hacer eso.

Al igual que durante la noche, lo harán en una reunión de una hora. Piénsalo. A ver si tiene sentido. Asegúrese de no terminar con una gran deuda técnica porque tomó una decisión equivocada y también tenga en cuenta a sus usuarios, los objetivos que son los productos. Y, obviamente, es como este delicado equilibrio entre el tiempo que tienes las habilidades que tienes en tu equipo, el presupuesto que has dicho, bueno, todo eso es importante al elegir este marco.

Así que creo que lo hemos hecho así. Pre-proceso general como, y sabemos con respecto a las facturas, sabemos qué marco vamos a usar. Sabemos que parecerá que las partes interesadas están contentas con la idea. Todo el mundo dice, estoy emocionado de empezar. Luego comenzamos nuestros ciclos de sprint. Así que básicamente hemos seguido.

Verle: De alguna manera, los pasos que mencioné anteriormente nos permiten obtener un requisito en el tablero que puede ser cualquier tipo de tablero. Es solo que el proceso de pensamiento puede ser como el tablero git o el tablero del proyecto. Usamos la noción para eso, pero también te ha gustado JIRA o cualquier otro tipo de software. Luego, especialmente para las funciones más pequeñas, porque si puede tener algo como su diseño general para su gran aplicación, verá que lo hace cada vez que esté haciendo pequeños complementos o, según los comentarios, podría pensar en otras funciones que desee. para implementar en su aplicación.

Vas a los diseños de necesidades a veces. O todos somos diseñadores creativos de UX para hacer algo por nosotros, o hacemos bocetos rápidos, pero asegúrese de que cualquier requisito que tenga, como esta comprensión clara de, está bien, así es como se ve aquí. Luego desarrollamos, que es la parte divertida. Y luego, qué hacemos para asegurarnos de que nuestro equipo tenga una forma estandarizada de codificar y enviar nuestros proyectos. También tratamos de estandarizar el uso de bibliotecas y paquetes, porque a la persona A le puede gustar una biblioteca específica y a la persona B y otras, pero está bien. Si puede llegar a un punto en común, ya sabe, no es un código que se ve completamente diferente cada vez.

Y luego también hacemos algunas pruebas, obviamente. Así que probamos la funcionalidad. Vemos si integra alguna característica nueva, no rompe nada más. Si se cumplen los requisitos, obviamente liberamos, obviamente cuando las tareas caen, liberamos a producción. Y a veces, antes de que hagamos el lanzamiento, lo posponemos.

Verle: Obtenga algunos comentarios de nuestros usuarios antes de que lancemos, porque a veces una función está tan dedicada a un cliente o usuario específico como decimos con ellos. Bueno. ¿Estás contento con eso? Entonces, si necesita cambiar antes de que hagamos el lanzamiento, entonces podríamos cambiar un poco la retroalimentación y la etapa de lanzamiento.

De nuevo, eso depende de tu situación y sí. Y así, cuando se lanza, recibimos comentarios, básicamente de todo, de todo. Así que todos los días recibimos comentarios sobre nuestras aplicaciones. También agradecemos los comentarios de nuestros usuarios, obviamente. Si dicen nuevas ideas de características o errores, los arreglamos en el próximo ciclo.

Hay un pequeño bucle rápido en nuestro proceso. Y luego algunos aprendizajes. Quiero compartirlo contigo. Tengo bastantes porque aprendimos mucho. Mi aprendizaje número uno es, no te quedes atascado en este marco o proceso en particular. No sigues la metodología ágil o la metodología UCD, como el paso a paso al 100%, no es blanco y negro.

Verle: Bueno. Tienes que hacer lo que funcione para tu equipo. Como ejemplo, normalmente cuando trabaja ágilmente con tareas más pequeñas, puede tener muchas tareas en su plato. Entonces, es posible que un miembro del equipo tenga como 10 tareas para completar en un ciclo de dos semanas. Pero en realidad no nos gustó tanto eso en nuestro equipo, nos gusta mucho más tener una gran epopeya, que básicamente llamamos un gran tema, en el que luego trabajamos.

Así que lo llamamos épico y es básicamente una tarea muy grande, en la que incorporamos todas las tareas relacionadas. Así que nos hace más cómodo trabajar con ella. Entonces, haga lo que haga, cualquier proceso que elija, haga lo que funcione para usted, entonces tampoco cometa el error. Y no digas, bueno, sé que va a terminar con deudas técnicas. He cubierto definitivamente. No conozco ningún proyecto propio que no tenga mucha profundidad técnica. Siempre tendrás un poco porque las elecciones que hiciste al principio van a, bueno, establecerte, ya sabes, son las elecciones que haces las que determinarán qué elecciones futuras puedes hacer. Este siempre será el caso, pero puede limitar esto e intentar igualarlo, pero siempre tenga en cuenta que esto sucede.

Luego, cualquiera que sea el proceso que elijas, tal vez inventes tu propio proceso porque te funciona. No me importa. Necesita comunicarse claramente con sus partes interesadas. Debe asegurarse de que sus partes interesadas sepan lo que está haciendo y cómo se ve su proceso, porque eso evita la frustración en sus sitios.

Verle: Entonces estoy apuntando a la protección. Creo que mucha gente tiene la tendencia de hacer todo perfecto. Ellos no irán, sino un impulso para hacerlo. Es un pequeño paso. Entonces, si está desarrollando software, intente hacerlo como, no sé, primero asegúrese de que la funcionalidad esté ahí. Y más adelante, puede optimizar la funcionalidad adicional. Por ejemplo, si desea crear una función en la que pueda agregar listas de compras o algo así, primero asegúrese de que la funcionalidad esté ahí para agregar listas y algunas. Y luego, tal vez, a continuación, puede concentrarse en cambiar el ícono o el color o fuera de la lista, ya sabe, como hacer estos cambios más personalizados.

Entonces, concéntrese en lanzar rápidamente al menos algo para que pueda recibir comentarios y luego pueda perfeccionar la forma, porque si apunta a la perfección de inmediato, podría desarrollar algo que sus usuarios realmente no quieren. como dije antes, en lugar de centrarse en los requisitos de las partes interesadas y simplemente cumplir con una lista de deseos, enfóquese en la motivación de la línea, porque al final, las partes interesadas, les pediré que se desarrollen a sí mismos para el producto.

Te pidieron que desarrollaras algo porque tienes experiencia en el desarrollo de software. Así que decir que quieren A, B y C en su lista no significa que saben más. Eso no significa que ABC sea realmente lo mejor. Así que siempre trato de obtener esa motivación subyacente para que realmente pueda ayudarlos a hacer o ayudar a hacer que el producto sea un producto mejor.

Verle: Luego otra cosa: no subestimes nuestra investigación. Pero tampoco subestime la poderosa investigación existente. No es necesario reinventar la rueda. Se ha realizado una gran cantidad de investigación de UX sobre la mejor manera de hacer las cosas. También puedes pensar, mirar, hacer tu propia investigación, aplicaciones similares. Míralos, mira cómo hacen las cosas.

No necesitan hacer todo desde cero necesariamente. Entonces creo que con cada proyecto, proyecto paralelo pequeño o grande o proyecto para una empresa o trabajar para la planificación es clave. Si solo está dando vueltas, como diré, y solo crea características aquí y allá, y simplemente sigue como usted, por favor. Y esto no le dará por defecto.

Entrega o software centrado en el usuario. Y también, si elige este proceso ágil de desarrollo de software en el que tenemos, como estos ciclos cortos, estas iteraciones no se atascan en esta visión de dos semanas, porque a veces, cuando trabaja en un proyecto ágil, si mi equipo, las dos semanas, es este tiempo que pasaste que tuviste las dos semanas es todo lo que hay.

Y luego todo comienza de nuevo. Pero no pierdas de vista el panorama general, siempre debes saber en qué estás trabajando, y eso es como la mejor autorrepresentación posible para tu usuario. Así que no olvides eso. Y luego, si desea evitar cosas como deudas técnicas, y si desea evitar tomar decisiones demasiado rápidas, porque por cuestiones de tiempo, asegúrese de que si está estimando el diseño para una característica o funcionalidad que incorpora adicional.

Verle: Entonces, si dices, está bien, esto me llevará 10 horas ponerlo. No sé si es con el 50% o algo así, tal vez 15, porque estás subestimando. Y hemos aprendido que las leyes que todavía hacemos, todavía subestimamos el tiempo que toman las cosas. Y sin embargo, como te decía, siempre diseña tus rasgos.

Incluso si es solo un rasguño rápido, no necesita hacer una estructura alámbrica completa o lo que sea que no necesite ser, especialmente un diseñador de UX para hacer este tipo de cosas, incluso si está solo y desarrollando un proyecto por su cuenta, asegúrese de hacer un boceto rápido para saber en qué está trabajando.

Envolver

Luego, un resumen rápido, pero les dije hoy antes de ir a las preguntas. Creo que lo principal que puedes sacar de esta presentación es que no saltes directamente al código. Ya sabes, piensa, planifica, obtén requisitos antes de comenzar a codificar. Y a todos nos encanta hacer eso como desarrolladores.

Lo sé, pero han dado un paso atrás y se han centrado en lo que podría ser mejor para ti aquí. Y no importa cuán grande sea ese proyecto, pequeño o grande. Todos necesitamos un proceso. Todos necesitamos diseñar y todos debemos centrarnos en el usuario. Si realmente queremos que nuestro software sea un éxito. Y luego construirse bien, es un esfuerzo de equipo, ¿sabes?

Verle: No se aísle demasiado como desarrollador. He escuchado a personas decir cosas como, sí, soy desarrollador. No necesito saber nada sobre. Oh, soy un desarrollador. No necesito saber nada sobre, no sé, cómo funcionan las cosas, cómo se ve la interfaz de usuario como si solo codificara. Pero creo que solo puede crear software sesgado si comprende para qué se está creando, donde un nombre para su usuario, y si comprende el proceso completo, y si lo hace como un equipo, los equipos están ahí por una razón. , los temas están ahí, va, funcionan bien.

Y debido a que las personas en el equipo, asegúrese de que haya más fallas de cada miembro individual del equipo solo. Por eso hay equipos. Entonces, incluso como desarrolladores, construya un software como un esfuerzo de equipo y no solo concéntrese en su entrenador, intente comprender también a su usuario. Y realmente ayudará.

Verle: Y entonces es correcto. Como, hazlo de nuevo. Obtenga comentarios. Vea lo que puede mejorar porque el software nunca está terminado. Puedes tener la definición de terminar. Puedes tener una definición de hecho. Puede tener la definición de primer lanzamiento, pero el software nunca ha terminado. Siempre hay cosas que mejorar.

Entonces, si itera sobre eso, en realidad mejorará cada vez más en cada paso. Y ese es mi resumen principal. ¿Hay alguna pregunta? Creo que están sucediendo muchas cosas en los chats, que no he estado leyendo, pero lo haré. Así que déjame ver lo que tenemos.

Q&A

Host: Así que creo que la primera pregunta es de Wayne. Wayne, ¿quieres dejar de silenciarte y hacer las preguntas tú mismo?

Wayne: Hola, ¿cómo están todos? Muchísimas gracias. Es una muy, muy buena presentación, en primer lugar. Sólo una pregunta rápida, de verdad. Me intriga el enfoque por fases que tiene y que mostró en una de sus diapositivas anteriores sobre la fase de diseño. Y me intriga saber, ¿cómo se prueba eso?

¿La etapa de prueba está haciendo como pequeñas pruebas? ¿Estás usando los diseños? ¿Tiene un control de calidad que analiza eso y cómo lo integra en su AC?

Verle: Entonces, como dije, somos un equipo muy pequeño, por lo que no tenemos un equipo completo. Probamos el diseño yendo directamente a nuestros clientes, lo cual tenemos la suerte de hacer.

Ellos también son nuestros usuarios. Tenemos la suerte de contar con estos usuarios dedicados que nos ayudan a crear nuestros productos. Así que vamos a ellos y todo se deriva como este es el diseño. ¿Te gusta? ¿Quieres ver algún cambio, etc? Si está trabajando para una audiencia más grande, definitivamente haría algo con las pruebas AB.

Entonces, si desea averiguarlo rápidamente, si su diseño funciona para un determinado grupo de personas, solo subconjuntos, básicamente su gran audiencia en una barra más pequeña, luego muéstreles una versión de la aplicación u otra versión de la aplicación y haga algunas pruebas al respecto. Y luego, obviamente, porque probar su diseño lleva tiempo. Debes hacer ese ciclo antes de que realmente te desarrolles. Por lo tanto, los requisitos de diseño siempre son ciclos largos antes de los ciclos de desarrollo. Porque si tu desarrollo, si estás desarrollando, ya necesitas saber que esto es, esto va a ser ocho. Eso es lo que diría. Eso responde tu pregunta?

Asistente: Sí. Sí, no, está bien. Está bien. Sé que no hay respuestas explícitas a esto, a veces creo que tienes toda la razón. Definitivamente está confirmando con la base de usuarios y que cuando haya realizado una iteración, obtendrá comentarios. Sí, muchas gracias. Gracias.

Host: Entonces, si alguien más tiene alguna pregunta, siéntase libre de levantar su mano virtual y luego Veerle puede saber. Para la siguiente pregunta, estaba preguntando sobre la construcción de un producto de software, ¿es realmente importante la elección del marco? Además, cuando se usa un marco, ¿cuál es el mejor enfoque arquitectónico? A veces, un proyecto se vuelve abrumador cuando crece en tamaño. Por ejemplo, tener un buen componente de estructura. Me encantaría saber de ti y cómo manejas esto.

Verle: ¿Es importante la elección del marco? Sí, lo es, porque no todos los marcos son adecuados para las cosas que quieres hacer. Por ejemplo, como dije, algunas cosas las desarrollamos en nuestro Shiny, las otras las desarrollamos en Vue y eso es por una razón porque la aplicación Vue es más un tipo de sistema CRM, que no es realmente adecuado para una aplicación Shiny. mientras que nuestras aplicaciones Shiny son más estilo tablero, como equipos.

Entonces, sí, el marco que elija definitivamente puede limitar lo que puede hacer con una aplicación. Entonces es importante. Y, obviamente, cuando un proyecto crece y se hace más y más grande, puede ser muy abrumador y eso realmente no importa qué marco estés usando. Pero si su proyecto crece, debe asegurarse de que lo hace dentro de los componentes, que no se repite, principio seco, y que lo hace lo más manejable y eficiente posible.

Entonces, incluso si elige Shiny, si elige Vue, si elige Note, intente hacerlo en componentes, intente dividirlo en partes más pequeñas para que sea realmente manejable. Estructura de componentes. Si. Definitivamente recomendaría eso. Y creo que todos los marcos hoy en día admiten ese tipo de estructura. Así que espero que eso responda la pregunta.

Host: Bueno. Gracias por responder eso. Así que tenemos un par de preguntas más de Donjung, ¿quieres silenciarte o. Creo, está bien. Creo que dijo en el chat que le gustaría que hiciera las preguntas en su nombre. Entonces, esta pregunta es ¿cómo se asegura de que los usuarios estén siempre motivados para colaborar y brindar comentarios, especialmente si son usuarios nuevos? ¿Proporcionas una compensación? En caso afirmativo. ¿Qué consejo daría para motivar a sus usuarios finales a recibir comentarios?

Verle: ¿Ofrecemos compensación? No, no lo hacemos. Tienes una charla encantadora con nosotros. Esa es la compensación y obtendrá un producto después. Así que creo que es una gran motivación, pero, de nuevo, tenemos una base de usuarios muy dedicada. Ese no es el caso si estás desarrollando para talentos o para individuos. Entonces, por decirlo, lo que haría si estás haciendo cosas como encuestas, creo que siempre funciona si tienes algún tipo de compensación por una encuesta, aunque tal vez sean puntos extra en una cuenta de ahorros que tienes, o tal vez sea como una función adicional que se está desbloqueando o un pequeño agradecimiento. Lo que también puedes hacer, incluso si estás hablando con los clientes, haz algo simple, dales un café de Starbucks, ya sabes, tienes como estos cupones en línea que puedes hacer. Solo dales las gracias. Di que realmente valoras sus comentarios. Y también trata de motivar a la gente haciendo un fondo de encuestas, ya sabes, da tu opinión de una manera divertida.

A menudo ves cosas como estas que puedes poner una cara sonriente o una cara muy, muy enfadada. Haz las cosas que a la gente le intriga hacer rápidamente, no les hagas 7 millones de preguntas y no les pongas requisitos. Su texto debe aplicarse a 300 escuelas chárter. Nadie va a hacer una tonelada como sea posible. Y espero que eso motive a la gente a realmente ayudarte. Y también hágales saber a las personas lo que hizo con esos comentarios, porque nada es más motivador para un usuario que decir, está bien, quiero ver esta característica que si puede decir un par de semanas más tarde, Hey, hemos creado esto para usted. Ve a verlo. Así que trate de realizar un seguimiento de quién le proporcionó realmente esa retroalimentación. Intenta devolverles eso. Esa es una forma muy agradable, creo.

Verle: También tenía una pregunta de seguimiento. Básicamente, nuestros experimentos realizados con el enfoque UCD le brindan una mejor claridad de resultados en la dirección del diseño a partir de un diseño completo o dos piezas específicas de diseño. Tenemos que entender que a nuestros usuarios les puede faltar esa atención, poder con un horario paciente.

Eso es ciertamente cierto. Bueno, eso, nuevamente, depende realmente del contexto, ya sabes, es posible que desees mostrarle al mismo usuario 3, 4, 5 opciones diferentes de cómo podría verse el diseño, lo que obviamente es muy pesado para el usuario porque requiere mucho de tiempo o va a dividir su base de usuarios en, con suerte, considere bien, gráficamente el mismo tipo de muestras, que solo proporciona con el diseño A, B, C, DE, ya sabe. Si hace las deudas sobre una base estadísticamente sólida, puede obtener la respuesta que está buscando.

Pero como realmente depende del contexto, cómo puede manejarlo mejor. Si hay alguna pregunta de seguimiento, házmelo saber y luego me enviaron otra pregunta de Steve.
Pregunta: ¿Qué herramientas recomienda para wireframes o bocetos?

Creo que wireframes es dibujar. Figma está escribiendo. Bonito. Y también tienes maquetas, Figma. Creo que tal vez sea un poco más difícil de entender si no eres un diseñador de UX, no es difícil, pero requiere un poco de habilidad y maquetas, todo el mundo realmente puede hacer eso. Y si no tienes acceso a maquetas o Figma, también puedes simplemente rellenar la comodidad o algo así, ¿sabes?

Siempre que tenga una idea general, no es necesario que sea perfecto. No necesita ser 100% exacto. Siempre y cuando tengas una idea general de cómo se verá.

Pregunta: Entonces una pregunta. Como persona del lado comercial, ¿cómo podemos garantizar que el desarrollador utilice el marco adecuado?

Bueno, no sé si una persona de negocios necesariamente sabe si es el mejor marco, una persona de negocios. Depende de qué tipo de persona del lado del negocio sea. Creo que debería dejar la elección del marco a las personas que realmente tienen más experiencia con los marcos. Diría desarrolladores, pero nuevamente, este es un esfuerzo de equipo. Y como equipo, deben decidir el marco. No deje que una persona de todo el equipo diga, está bien, este será el marco que necesita para ponerse de acuerdo sobre el marco que va a utilizar.

Y el marco que vas a usar depende de muchas cosas, la habilidad del equipo que contiene los datos, todas las cosas, como mencioné, ya sabes. No dejes que sea una decisión de un solo hombre. Y yo, estamos casi fuera de la vista. Veo si estamos fuera de tiempo. Tengo tiempo para una pregunta. Una última pregunta.

Pregunta: Soy un desarrollador de software que ha acumulado algunos conocimientos técnicos, ¿cómo encuentro personas con las que trabajar?

¿Cómo puedes encontrar gente con quien trabajar? Puede preguntar, como a los trabajadores independientes que quieren ayudarlo, puede encontrar, ver si puede, como, no sé, comunicarse con conexión o Codementor, probablemente.

En Codementor, tiene muchos desarrolladores que podrían ayudarlo o asistirlo en sus proyectos. Si tuviera LinkedIn a través de las redes sociales, simplemente, hay muchos desarrolladores por ahí y esos desarrolladores que podrían realmente formar un equipo con usted. Así que definitivamente echamos un vistazo a este tipo de plataformas para deudas.

Eso es. Lo que quiero compartir contigo. Una última cosa es, mi LinkedIn. Por favor, mantente en contacto conmigo. Envíame una solicitud de conexión o dame un seguimiento. De vez en cuando comparto cosas sobre quizás nuestro lenguaje de programación, pero también sobre desarrollos de software y cómo hacemos las cosas en nuestra empresa.

Entonces, si cree que es interesante, comuníquese allí y luego muchas gracias por su tiempo y por todas sus preguntas. Y si tiene más preguntas que quiera que le haga, que no pude responder aquí, siempre puede comunicarse conmigo en LinkedIn. Gracias.

Host: Impresionante. Muchas gracias por esta increíble charla, Veerle. En cuanto a tomarse el tiempo para responder a las preguntas de todos y esas cosas. Maravillosa charla. Y personalmente aprendí mucho de esto. Así que gracias de nuevo a todos por unirse a nuestro evento y muchas gracias a nuestro orador, realmente por dar esta charla hoy. Así que espero que todos hayan disfrutado esto y estén atentos a nuestro próximo evento, que se titula cómo superar el síndrome del impostor en tecnología. Se llevará a cabo la próxima semana, el XNUMX de diciembre, si todos están interesados ​​en unirse y espero verlos a todos allí, publicamos información en ese chat.

Más sobre el evento virtual para desarrolladores

Este evento fue organizado por Codementor events, una comunidad de desarrolladores y una plataforma de eventos virtuales para compartir y aprender nuevas herramientas y conceptos. Encuentra mas sobre Eventos de Codementor aquí ->

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.codementor.io/blog/cme-usercentric-dmirs6ed92