Desenvolupament frontend: guia per decidir què necessita el teu web o aplicació

Un web pot tenir un disseny atractiu i, tot i així, dificultar una consulta, una compra o la gestió d’una tasca. El problema sol aparèixer quan la part visible es tracta com un acabat final, en lloc de com el lloc on una persona entén, decideix i actua.

El desenvolupament frontend resol aquesta part del projecte: construeix les pantalles, els controls i els comportaments amb què interactua qui visita un web o utilitza una aplicació. En acabar aquesta guia podràs distingir què correspon al frontend, quina informació convé definir abans de desenvolupar-lo i quan un requisit aparentment senzill necessita més detall.

Resposta directa

El desenvolupament frontend és la construcció de la interfície que es mostra al navegador o en una aplicació: pàgines, menús, formularis, botons, llistats, missatges d’error i estats de càrrega, entre d’altres elements.

La seva funció no es limita a reproduir un disseny. Ha de permetre que cada persona completi una acció amb claredat i que la interfície respongui de manera coherent al que passa. Per exemple, si algú envia un formulari, el frontend ha de mostrar quines dades falten, confirmar l’enviament quan correspongui i evitar que una acció sembli completada si ha fallat.

En un projecte d’empresa, convé decidir el frontend a partir d’aquestes tres preguntes:

• Objectiu: què ha d’aconseguir la persona que utilitza la pantalla?
• Abast: quins continguts, pantalles, accions i casos ha d’incloure?
• Solució: com s’organitzaran i construiran aquests elements?

Aquesta separació evita decidir una tecnologia o un efecte visual abans d’entendre quina necessitat ha de resoldre la interfície.

Context i abast: què inclou el frontend

El frontend és la capa amb què interactua la persona usuària. Inclou tant la presentació de la informació com les respostes visibles a les seves accions.

En un web de serveis, pot abastar la navegació, les pàgines de serveis, les crides a l’acció i un formulari de contacte. En una eina interna, pot incloure una pantalla per consultar comandes, filtres, avisos, permisos visibles i formularis per registrar dades.

Normalment, l’abast frontend reuneix aquestes decisions:

• Estructura de les pantalles i jerarquia de continguts.
• Components reutilitzables, com ara capçaleres, botons, targetes o camps de formulari.
• Adaptació a diferents mides de pantalla.
• Estats d’interacció: càrrega, confirmació, absència de resultats i error.
• Validacions visibles abans d’enviar informació.
• Navegació entre seccions o tasques.
• Manera com la interfície mostra dades procedents d’altres sistemes.

No tot el que passa en un web pertany al frontend. La gestió de dades, les regles internes, els permisos reals o la connexió amb serveis externs poden requerir una part de servidor, habitualment anomenada backend. La divisió exacta depèn del projecte, però la interfície necessita conèixer aquests comportaments per comunicar bé cada resultat a qui la utilitza.

Criteris pràctics per definir un bon abast

Abans de demanar que es desenvolupi una interfície, no cal que triïs un llenguatge de programació. Sí que cal reduir les ambigüitats que afecten les pantalles i les accions.

Parteix d’una acció concreta

Descriu què ha de poder fer cada tipus de persona. «Necessito una àrea privada» és una etiqueta massa àmplia. És més útil concretar si la persona podrà veure documents, descarregar arxius, modificar dades, consultar l’estat d’una sol·licitud o contactar amb l’equip.

Quan una mateixa pantalla reuneix usuaris amb necessitats diferents, identifica els perfils i els seus permisos. Una interfície clara per a un client pot no ser adequada per a qui gestiona informació internament.

Defineix els estats, no només la pantalla ideal

Una pantalla no està acabada perquè es vegi bé amb dades completes. Cal preveure què es mostra quan falten dades, una cerca no retorna resultats, un servei triga a respondre o una acció no es pot completar.

Aquest detall redueix interpretacions durant el desenvolupament i ajuda a evitar missatges confusos. També permet comprovar el resultat amb situacions reals d’ús, no només amb una maqueta estàtica.

Aclareix el contingut i qui l’aprova

Els textos, les imatges, els documents, les fitxes de producte i els avisos legals condicionen la interfície. Si el contingut encara no existeix, convé registrar-lo com una dependència i decidir qui el prepara i el valida.

No cal tancar cada text abans de començar, però sí conèixer la naturalesa del contingut. Una pàgina preparada per a un paràgraf breu pot deixar de funcionar si finalment ha de mostrar comparatives, documents descarregables o informació extensa.

Pensa en l’ús des de mòbil i escriptori

Adaptar una interfície a pantalles petites no consisteix únicament a reduir mides. Pot canviar l’ordre de la informació, la manera de desplegar una navegació o l’espai necessari per completar un formulari.

Defineix quines accions han de ser especialment senzilles en mòbil i quines requereixen més context o treball d’escriptori. Aquesta decisió ha de respondre a l’ús previst, no a una preferència visual.

Estableix com comprovaràs cada funció

Un requisit verificable ajuda a evitar converses basades en impressions. Per exemple: «en completar els camps obligatoris i enviar el formulari, ha d’aparèixer una confirmació visible; si falta un camp, s’ha d’indicar quin».

Aquest tipus de criteri no decideix com es programa la funció, però sí fixa quin comportament s’ha d’observar abans de donar-la per acabada.

Aplicació: d’una necessitat de negoci a una interfície

Imagina, com a exemple hipotètic, una empresa que rep sol·licituds per correu electrònic i vol ordenar el primer contacte des del seu web. Demanar «un formulari modern» no és suficient per definir el desenvolupament frontend.

El punt de partida seria concretar l’objectiu: recollir la informació necessària per valorar una sol·licitud sense dificultar-ne l’enviament. A partir d’aquí, l’abast podria incloure els camps necessaris, missatges d’ajuda, validació de dades, confirmació d’enviament i adaptació a mòbil. La solució tècnica es decideix després, atenent també com es rebran i gestionaran aquestes sol·licituds.

La mateixa lògica serveix per a una zona de clients o un panell intern. En lloc de partir d’una llista de pantalles aïllades, ordena la feina per recorreguts:

1. Què necessita consultar o fer la persona.
2. Quina informació ha de veure abans d’actuar.
3. Quines dades pot introduir o modificar.
4. Què passa després de cada acció.
5. Quines alternatives ha de mostrar la interfície si alguna cosa no està disponible.

Aquest enfocament també ajuda a prioritzar. En una primera versió, pot ser suficient que una persona consulti informació i enviï una sol·licitud. L’edició de dades, les notificacions avançades o els filtres complexos poden quedar per a una fase posterior si no són necessaris per complir l’objectiu inicial.

Quan el projecte combina disseny, continguts, funcions i una part d’administració, el frontend forma part d’un abast més ampli. Pots revisar el servei de desenvolupament web per a empreses d’AVSISTEC si necessites situar la interfície dins d’un web orientat a explicar serveis, facilitar contactes o resoldre processos concrets.

Límits: el que el frontend no resol per si sol

Una interfície cuidada no corregeix automàticament un procés mal definit. Si no està clar qui rep una sol·licitud, quines dades necessita l’equip o què passa després de prémer «enviar», el desenvolupament frontend només pot reflectir aquesta incertesa.

També hi ha decisions que requereixen una validació específica:

• Els textos sobre condicions, privacitat o requisits sectorials han de ser revisats per les persones responsables i, quan calgui, per assessorament especialitzat.
• Les integracions amb eines externes necessiten confirmar accessos, dades intercanviades i comportament davant de fallades.
• Els permisos no s’han de definir només pel que s’oculta a la pantalla; requereixen regles reals en la part que controla l’accés a les dades.
• El manteniment ha de preveure qui actualitzarà continguts, revisarà incidències i decidirà canvis futurs.

Per això, l’elecció d’eines o tecnologies no hauria de ser el primer pas. Hi pot haver diferents solucions vàlides per a una mateixa interfície. La decisió depèn de les funcions, de qui la mantindrà, de les integracions necessàries i de l’evolució prevista.

Pas següent: prepara una conversa útil sobre el teu projecte

Si ja saps quines accions hauria de facilitar el teu web o aplicació, reuneix una breu descripció dels usuaris, les pantalles o recorreguts necessaris, els continguts disponibles i les eines amb què s’ha de connectar. Si algun d’aquests punts encara està obert, indica-ho: fer-ho visible és millor que donar-ho per descomptat.

Si vols contrastar aquest abast i valorar com encaixaria dins d’un projecte web, pots explicar el teu projecte de desenvolupament web a AVSISTEC.