¿Existe un estándar para describir un formulario en una especificación de programación?

Esa tabla no está lista para el cliente. Entiendo los términos técnicos como "desplegable" y "área de texto", pero esas palabras nunca deben ponerse frente a un cliente. Excepto por la rara excepción de que tiene algo de experiencia en programación, en el mejor de los casos el cliente no obtendrá nada y, en el peor de los casos, tendrá una experiencia realmente incómoda y se resentirá contigo por ello.

Le recomiendo que no use tablas para explicar estas interfaces a sus clientes; en su lugar, use una ilustración. Es muy estándar usar ilustraciones en la escritura técnica. Cuando escribí libros técnicos, eran 1000 páginas con 500 ilustraciones. Si no fuera por las ilustraciones, habrían sido 3000 páginas.

Es muy probable que incluso el cliente menos técnico haya utilizado un formulario web. Así que todo lo que tiene que hacer es mostrarles algo parecido a un formulario web y verán un formulario web:

Hice esa ilustración con Autodesk Graphic en aproximadamente 5 minutos, como máximo, incluida la ubicación en este artículo. Son solo algunos rectángulos y algunos objetos de texto. La parte más difícil fue buscar una lista de estados alfabéticos de EE. UU. que podía pegar allí. Incluso si no tienes experiencia con las herramientas de dibujo, es probable que te lleve menos tiempo hacer una ilustración como esta que hacer una tabla o escribir una descripción.

Es posible que desee poner un título "solo con fines ilustrativos, no como un diseño final" en su ilustración para evitar que el cliente piense que así es como se verá realmente el formulario final. Está destinado a ser simplemente un paso adelante de la tabla que hizo, no para ser un diseño. Pero una ventaja adicional más allá de una mejor comprensión del cliente es una menor ambigüedad para la persona que realiza el diseño final. La versión de la tabla podría malinterpretarse accidentalmente, pero es bastante difícil para un diseñador o programador web malinterpretar una ilustración como esta.

Así que las ilustraciones mejoran su especificación para todos.

No existe una "manera estándar" de explicar los conceptos técnicos a aquellos que no los entenderían, al menos que yo sepa. Sin embargo, tengo algunas técnicas que puede probar cuando tenga que redactar un informe técnico de manera sencilla.

• Divide tu informe en secciones claramente divididas. Esto permite que el lector entienda más claramente lo que está viendo.

• Definir todo en palabras fáciles de entender. Personalmente, no me gusta mirar las notas al pie; hace que el documento parezca más difícil o complejo de lo que realmente es. Pero la decisión sobre dónde definir las palabras depende de usted.

• Generalizar. Si puede dar una pequeña descripción de cómo funciona algo sin entrar en grandes detalles, entonces bríndelo como una descripción general.

• Si puede, use analogías y/o diagramas. Sus tablas probablemente ayuden mucho, pero asegúrese de que sean lo suficientemente grandes para leerlas y verlas fácilmente. Es probable que muchos clientes no quieran tener que pensar demasiado en lo que muestra una tabla.

• Consigue ayuda. A menudo finjo que le estoy explicando cosas a mi mamá y eso me ayuda a usar un vocabulario más pequeño y generalizar las funciones tecnológicas.

Desafortunadamente, esto es algo que siempre puede afectar a los desarrolladores de tecnología. Tengo una última sugerencia, aunque puede que no sea la más ideal.

• Mantenga a su cliente en una base parcial de "necesidad de saber". Bríndales toda la información, pero para las secciones técnicas, déjalo tan complejo y extenso como sea necesario para compartir la información. Ofrézcales una descripción general de los métodos de recopilación, etc., pero si pueden confiar en usted para desarrollar un producto que logre los objetivos previstos y cumpla con los requisitos establecidos, entonces su trabajo será mucho más fácil. Ofrécete a reunirte con ellos y profundizar más si quieren/si puedes, pero si no lo entienden, no es necesario que lo hagan.