Empieza con la persona que usa la dApp
Una dApp debería hacer que su tarea principal sea fácil de entender antes de que aparezca una wallet o una acción de contrato. Empezamos mapeando lo que un miembro viene a hacer, luego conectamos cada paso con las pantallas y los datos que la aplicación necesita.
Esa primera conversación puede ser sencilla. Cuéntanos para quién es el producto, qué deberían poder hacer las personas y qué es lo que ya existe. Un boceto aproximado o unas pocas notas son suficientes para empezar. Los convertimos en una imagen compartida del primer lanzamiento, incluyendo las partes que requieren decisiones técnicas.
Por ejemplo, un proyecto de NFT podría querer que los miembros exploren una colección y luego realicen una acción on-chain. Podemos separar las partes que necesitan una wallet conectada de las que deberían permanecer abiertas para todos. Si el producto también necesita nuevos contratos, podemos coordinar el plan de la aplicación con el desarrollo de smart contracts. Para el panorama técnico más amplio, el desarrollo Web3 cubre el trabajo de productos conectados más allá de una sola dApp.
Traza la construcción en tres pasos claros
Un plan útil de dApp lleva la idea a través de las tareas del usuario, las integraciones y una decisión sobre el primer lanzamiento. Estos tres pasos mantienen visibles las decisiones importantes antes de que comience el desarrollo.
- Describe el recorrido. Listamos las acciones que un miembro debería realizar, desde abrir la aplicación hasta completar la tarea principal. Anotamos dónde la interfaz necesita explicar una elección o mostrar una respuesta.
- Reúne las conexiones. Revisamos los contratos, wallets, redes y servicios existentes con los que el producto debe funcionar. También anotamos la información que cada pantalla necesita mostrar.
- Elige el primer lanzamiento. Acordamos qué pantallas e integraciones pertenecen a la construcción inicial. Otras ideas pueden permanecer en una lista de seguimiento, en lugar de unirse silenciosamente al trabajo a mitad de camino.
Imagina que tu equipo ya tiene un boceto del producto y un contrato, pero las vistas de datos aún son inciertas. Podemos marcar las partes confirmadas, listar las preguntas abiertas y acordar qué debe responderse antes de la implementación. Si el producto necesita un sitio público separado, el desarrollo de sitios web y landing pages Web3 puede cubrir esa superficie sin mezclarla en el plan de la aplicación.
¿Dónde deberían encontrarse las wallets y los datos on-chain?
El flujo de wallet y la vista de datos deberían respaldar la misma tarea del usuario. Los planificamos juntos, para que un miembro pueda entender lo que muestra la aplicación y por qué se necesita una conexión.
Pasos de wallet
Mapeamos los momentos que necesitan una dirección de wallet o una acción aprobada por el usuario. La interfaz debería contemplar 3 estados básicos: desconectado, conectado y de regreso a la aplicación. También acordamos cómo la aplicación explica el siguiente paso, en lugar de dejar que las personas interpreten un mensaje de wallet sin contexto.
Datos que las personas pueden usar
Vale la pena considerar la indexación cuando los miembros necesitan encontrar u organizar registros on-chain. Empezamos con las preguntas que la pantalla debe responder, luego identificamos la fuente y la presentación de esa información. Una vista de cuenta individual puede requerir un trabajo de datos diferente al de un historial de actividad buscable.
Supongamos que un coleccionista regresa para verificar una acción anterior. Podemos rastrear qué información necesita la pantalla y decidir si una fuente existente es suficiente. Trae ejemplos de los registros o vistas que quieras mostrar. Cuando la funcionalidad de wallet es un producto más amplio por sí mismo, el desarrollo de dApps es una opción separada.
Haz que los momentos tranquilos sean parte del diseño
Imagina a un artista de NFT con pocos seguidores, justo cuando la única persona que responde se va de vacaciones. Un nuevo miembro llega con una pregunta sobre la colección y una acción en la dApp. Haríamos visible el siguiente paso en la interfaz, para que el producto no dependa de que alguien esté en línea para explicarlo.
Ese tipo de momento pertenece a la revisión del producto, no solo a un plan de soporte. Observamos lo que ve un miembro por primera vez, qué sucede cuando falta información y cómo responde la aplicación después de una acción. Luego acordamos qué estados deben diseñarse y probarse.
Antes del trabajo de construcción, verificamos:
- La tarea principal que un nuevo miembro debería completar.
- Qué se puede explorar sin conectar una wallet.
- Qué mensaje aparece cuando los datos aún se están cargando o no están disponibles.
- Qué ve el miembro después de enviar una acción.
Esta revisión mantiene la interfaz anclada en el uso real. También te ayuda a decidir qué pertenece al primer lanzamiento y qué puede esperar hasta que tengas más comentarios.
Mantén el trabajo visible hasta la entrega
Una buena entrega muestra lo que se construyó, cómo se verificaron los flujos de usuario acordados y qué dependencias quedan. Usamos dos puntos de revisión, uno antes de la implementación y otro cerca de la entrega. Antes de la implementación, confirmamos las funcionalidades acordadas. Cerca de la entrega, recorremos el trabajo completado contigo.
Durante la construcción, verificamos los estados planificados del frontend y las integraciones con respecto al recorrido del usuario. Mantenemos visibles las preguntas abiertas y discutimos las nuevas solicitudes antes de que cambien el trabajo acordado. En la entrega, recorremos la aplicación, compartimos notas de implementación e identificamos cualquier tarea de seguimiento que tu equipo quiera considerar.
Los proveedores de wallet, redes, contratos y servicios de datos están fuera de nuestro control. Su disponibilidad, manejo de transacciones, actualizaciones y compatibilidad pueden cambiar, por lo que verificamos el comportamiento acordado de la aplicación sin prometer cómo funcionarán esos sistemas externos.
Para empezar, envíanos tus notas del producto, borrador de la interfaz, detalles del contrato disponibles y ejemplos de los datos que los miembros necesitan. Brand Community los revisará contigo, aclarará las preguntas abiertas y dará forma a un plan de primer lanzamiento sobre el que puedas tomar una decisión clara.
Cómo trabajamos
- Comparte la imagen del productoCuéntanos a quién sirve la dApp, qué necesitan hacer los miembros y qué tienes ya.
- Traza las conexionesRevisamos las wallets, contratos, redes y necesidades de datos que respaldan esas tareas.
- Acuerda el primer lanzamientoDecidimos qué funcionalidades pertenecen a la construcción y qué debe cubrir la entrega.
- Construye y verifica los flujosImplementamos el trabajo acordado y lo revisamos con respecto al recorrido del miembro.
- Recorre la entregaTe mostramos el trabajo completado, compartimos notas e identificamos las dependencias restantes.
Preguntas frecuentes
¿Qué debería traer a nuestra primera conversación sobre dApps?
Trae una breve descripción del producto, las tareas principales del miembro y cualquier cosa ya construida. Los bocetos de la interfaz, los detalles del contrato y los ejemplos de los datos que quieres mostrar también son útiles. Incluso una lista simple de 3 acciones de usuario nos da un lugar práctico para empezar.
¿Construirán la interfaz de la dApp en torno a nuestros contratos existentes?
Sí. Podemos planificar el frontend y el flujo de wallet en torno a contratos existentes. Comparte la información disponible del contrato y explica qué necesitan hacer los miembros. Revisaremos los puntos de conexión, anotaremos cualquier cosa que aún no esté clara y acordaremos qué funcionalidades pertenecen al primer lanzamiento.
¿Cómo deciden si una dApp necesita indexación?
Empezamos con las preguntas que tus miembros necesitan que la aplicación responda. Si necesitan encontrar, organizar o ver registros a través de la actividad, la indexación puede ser útil. Comparte un par de ejemplos de los registros o pantallas que tienes en mente, y mapearemos la necesidad de datos con el producto.
¿Puede la aplicación mostrar información útil antes de que alguien conecte?
Sí, cuando el flujo del producto lo permite. Identificamos qué información se puede explorar sin una wallet y qué acciones necesitan una conexión. Por ejemplo, una vista de colección pública se puede planificar por separado de una acción de miembro que necesita aprobación de wallet.
¿Cuánto tiempo suele llevar construir una dApp?
Establecemos los plazos después de revisar las funcionalidades, los materiales existentes y las integraciones. Un flujo de frontend enfocado y una aplicación con varias conexiones de contrato o datos necesitan planes diferentes. Acordamos hitos en función del trabajo, para que puedas ver qué viene a continuación en cada revisión.
¿Pueden asegurar que cada wallet y conexión de datos seguirá funcionando?
No. Los proveedores de wallet, redes, contratos y servicios de datos pueden cambiar su disponibilidad, manejo o compatibilidad. Podemos construir y probar el comportamiento acordado de la aplicación para integraciones seleccionadas, luego documentar las dependencias. Por ejemplo, la entrega puede mostrar qué conexión espera la aplicación y qué debe monitorear tu equipo.
Cuéntanos sobre tu proyecto
Responde cuatro preguntas rápidas y en menos de una hora te enviamos un plan, plazos y un rango de presupuesto. Todo es confidencial.
Cargando el formulario…