¿Cuáles son algunos consejos para hacer una crítica de la aplicación en una entrevista de diseño de producto? Estilo de Vida y Elegante

Criticar el trabajo a veces es arriesgado porque generalmente no sabes nada al respecto. Como ejemplo: puedo pensar que Yelp es “poco atractivo”, o que está “demasiado ocupado”, o que es “difícil encontrar la función X”, pero

No tengo idea de quiénes son los usuarios de Yelp o qué les parece atractivo o qué ha hecho Yelp para probar qué colores, por ejemplo, parecen más atractivos para su comunidad.
No tengo idea de cómo Yelp llegó a su nivel actual de densidad de información, ni cuántos casos de uso / rutas de usuarios divergentes necesitan para admitir por pantalla (¡sospecho que mucho!), Ni idea de lo que indican los datos de uso reales sobre cualquiera de No tengo idea, incluso si estoy en una prueba A / B.
No tengo idea de si Yelp quiere que la gente use la función X; tal vez tenga costos problemáticos o efectos dinámicos, pero es importante para algunos electores clave, por lo que deliberadamente han hecho que sea más difícil de encontrar o más ficticio de usar.

Y así. David Cole una vez me aconsejó que comenzara cualquier crítica con la suposición de que hay razones para lo que se ha hecho, en lugar de hacer lo que hacen muchos y muchos diseñadores: dar un paso superficial sobre la interfaz de usuario, marcar todo lo que parece irreal desde su posición de casi ignorancia total, y entregar un análisis que es a la vez duro e ingenuo.

Todo esto dijo: ¡mucho software es malo! ¡Muchas decisiones son errores! Mucha IU es terrible. Abundan los errores y una buena crítica aún puede entrar en estas cosas al transmitir el nivel apropiado de humildad epistemológica.

¡Cuidado con tus críticas! Tenga en cuenta cuándo es posible que no conozca los datos clave, que son la mayoría de las veces, o cuando no puede imaginar razones pero sospecha que pueden existir. Expresar dudas apropiadas es bueno: “Este botón parece extrañamente colocado, pero tal vez tienen una razón para eso; podría ser un mapeo de calor que les dijo que esto es realmente a dónde va la gente, o tal vez querían facilitar la internacionalización, pero parece que podría funcionar mejor incluso en esos casos aquí ”, etc. Llame siempre que (1) no realmente sé lo que podría haber informado una decisión o (2) puede imaginar posibles fundamentos. (Qué tan bien puede imaginar que esto les dice a los entrevistadores mucho sobre su experiencia y pensamiento).
Recuerde que sus entrevistadores hacen software ellos mismos. Así que cometieron errores, enviaron malos diseños, perdieron batallas organizacionales que llevaron a compromisos, redujeron las ideas a MVP brutalmente parcializados, lidiaron con reacciones públicas incomprensibles, etc. Si tienen alguna experiencia, saben que a veces las cosas parecen carecer de sentido y no lo son (y viceversa: las cosas que parecen “más inteligentes” a menudo apestan). Serán escépticos de las tomas extremadamente simples o reductivas.

En resumen: al hacer una crítica de la aplicación en una entrevista, demuestre que sabe cómo se hace el software, cuántas explicaciones puede haber para diferentes decisiones, cuánta información se requiere realmente para tomar buenas decisiones y qué tan difícil puede ser buen trabajo, al tiempo que muestra qué tipo de buen trabajo podría hacer. Suficientemente cauteloso, incluso los cambios propuestos que, de hecho, no funcionarían bien pueden demostrar buenas capacidades de diseño.