Purpose

Definir un lenguaje común para clasificar, dimensionar y controlar la complejidad de los componentes de un Website.

Este estándar busca evitar situaciones como:

vender “componentes ilimitados”;
tratar todos los componentes como equivalentes;
descubrir durante Production que un componente era mucho más complejo de lo esperado;
sumar componentes pequeños de manera aparentemente inocua hasta ampliar significativamente el scope;
o depender de la interpretación individual de Sales, Design o Development para determinar qué tan grande es un componente.

El sistema utiliza:

Complexity Tiers → S / M / L / XL

Component Points → 1 / 3 / 6 / 12

para transformar el sistema de componentes en un scope cuantificable y flexible.

Core Principle

Un componente no se clasifica únicamente por:

cuánto espacio ocupa;
cuántos campos tiene;
cuánto “parece” que llevará hacerlo;
o qué tan llamativo se ve visualmente.

Su complejidad surge de la combinación de factores como:

layout + responsive behavior + variants + interaction + animation + state / logic + data + integrations.

Dos componentes visualmente similares pueden tener complejidades radicalmente diferentes.

1. What is a Component?

Un componente es una unidad reutilizable de interfaz con una responsabilidad clara, diseñada para funcionar dentro del sistema de páginas del Website.

Ejemplos:

Hero
Text + Media
Logo Grid
Testimonials
Stats
Cards Grid
FAQ
Timeline
Interactive Map
Contact Form

Una vez desarrollado, el mismo componente puede utilizarse múltiples veces en diferentes páginas sin convertirse en nuevos componentes.

Por ejemplo:

Un Text + Media utilizado en Home, About y Product continúa siendo un único componente.

El Component Budget mide el sistema que /nk diseña y construye, no la cantidad de veces que posteriormente se utiliza.

2. What is NOT automatically a new Component?

No debería considerarse un componente nuevo simplemente por:

cambiar contenido;
utilizar otra imagen;
cambiar el orden de elementos;
utilizar otro background;
invertir una composición;
ocultar un campo opcional;
cambiar alineación;
utilizar el mismo layout con video en lugar de imagen;
reutilizar el componente en otra página.

Estos casos pueden resolverse mediante variants.

Sin embargo, cuando cambia materialmente la estructura, lógica, funcionalidad o responsabilidad del bloque, probablemente estemos frente a un componente nuevo.

3. Complexity Dimensions

Para clasificar un componente debemos observar su complejidad en varias dimensiones.

No todos los factores deben estar presentes.

La clasificación final debe representar el conjunto del esfuerzo y riesgo esperado.

Layout

Evaluar:

cantidad de elementos;
estructura;
cantidad de breakpoints relevantes;
comportamiento responsive;
layouts alternativos;
cantidad de contenido variable;
dificultad de mantener consistencia con contenidos extremos.

Variants

Evaluar:

cantidad de variantes;
cuánto cambia el layout entre ellas;
qué partes se comparten;
qué partes requieren comportamiento específico.

Variantes puramente visuales agregan poca complejidad.

Variantes que cambian radicalmente estructura o comportamiento pueden implicar un componente diferente.

Interaction

Evaluar si existen:

sliders;
accordions;
tabs;
carousels;
switches;
drag;
hover states complejos;
navegación interna;
controles;
interacción dependiente del usuario.

Motion

Evaluar:

entry animations;
scroll animations;
timelines;
transitions;
choreography between elements;
scroll-driven behavior;
canvas / WebGL;
motion dependent on interaction.

Una animación simple de aparición no convierte automáticamente un componente en L o XL.

State & Logic

Evaluar si el componente:

mantiene estado;
cambia según selecciones;
tiene múltiples modos;
depende de reglas;
filtra información;
calcula resultados;
reacciona a datos;
tiene diferentes outcomes según la interacción.

Data & CMS

Evaluar:

cantidad y complejidad de campos;
repeatable content;
relaciones con otros Content Types;
contenido dinámico;
queries;
filtering;
conditional fields;
nested structures.

Tener CMS por sí solo no implica alta complejidad.

Integrations

Evaluar si consume o envía información mediante:

APIs;
third-party services;
authentication;
CRM;
payment systems;
external data sources;
internal client systems.

Las integraciones suelen aumentar el riesgo de manera desproporcionada respecto de la complejidad visual.

4. Complexity Scale

Cada componente se clasifica dentro de uno de cuatro niveles:

S / M / L / XL

S — Small / Simple

Componente simple y autocontenido.

Generalmente tiene:

una responsabilidad;
estructura sencilla;
contenido estático o administrable;
poca o ninguna interacción;
pocas variantes;
sin lógica de negocio;
sin integraciones.

Typical characteristics

Layout simple.
Responsive predecible.
0–2 variantes menores.
Sin state significativo.
Motion simple opcional.
Datos directos desde CMS.

Examples

Rich Text
Image
Video
Quote
Simple CTA
Simple Stats
Logo strip
Simple heading block

Points

1 point

M — Medium

Componente con mayor riqueza de layout o repetición de elementos y una cantidad moderada de interacción.

Generalmente puede incluir:

repeated items;
carousel;
accordion;
cards;
media combinations;
layouts más elaborados;
variants;
interacción simple;
lógica mínima.

Typical characteristics

Layout responsive con cierta complejidad.
Repeatable items.
Varias opciones de presentación.
Interacción simple.
State limitado.
Sin lógica de negocio significativa.
Sin integraciones complejas.

Examples

Cards Grid
Carousel
Accordion
Testimonials Slider
Text + Media
Logo Grid with interaction
Simple Map
Tabs simples

Points

3 points

L — Large

Componente con interacción rica, múltiples estructuras posibles, estado relevante o comportamiento dinámico.

Generalmente combina varias dimensiones de complejidad.

Typical characteristics

Multiple structural variants.
Internal state.
Conditional behavior.
Advanced interaction.
Complex responsive logic.
Significant motion.
Dynamic content.
Filters or switches.
Multiple content modes.

Examples

Complex Tabs with dynamic content
Configurable grids
Interactive Timelines
Multi-step visual explorers
Advanced carousels
Interactive comparison modules
Content filtering interfaces

Points

6 points

XL — Extra Large

Componente que funciona prácticamente como un mini-producto o sistema dentro del Website.

Suele combinar:

interacción rica;
lógica;
múltiples estados;
animación compleja;
integración;
data;
comportamiento custom;
y mayor costo de build, testing y mantenimiento.

Typical characteristics

Multiple subsystems.
Business logic.
Significant integrations.
Advanced interactive behavior.
Complex state.
API communication.
Highly customized animation.
Multiple failure / empty / loading states.
Higher QA requirements.

Examples

Advanced forms integrated with external systems
Product configurators
Interactive product explorers
Loyalty modules
E-commerce functionality
Complex calculators
Highly interactive 3D / WebGL experiences
Complex maps connected to APIs
Multi-step application flows

Points

12 points

5. Classification Rule

La clasificación debe representar el componente tal como esperamos que funcione, no solamente el diseño estático que vemos en Figma.

Antes de clasificarlo debemos considerar:

¿Qué hay que diseñar, construir, integrar, hacer responsive, animar, testear y mantener?

Cuando un componente se encuentre entre dos tiers, debe evaluarse cuál representa mejor su riesgo total, no solamente su apariencia.

Ante una duda relevante entre dos categorías, Design Lead y Tech Lead deberían alinearse antes de cerrar el scope.

6. Variants

Cada componente puede incluir variantes sin que cada una se convierta automáticamente en un nuevo componente.

Como referencia, un componente puede contemplar hasta aproximadamente 3–4 variantes razonables dentro de su definición original.

La cantidad no es una regla matemática: importa cuánto cambia realmente el componente.

A Variant IS

Un cambio sobre la misma responsabilidad, estructura y funcionamiento general.

Examples:

Position

Text left / Media right

→

Media left / Text right

Media type

Image

→

Video

dentro de la misma estructura.

Theme

Light / Dark

Alignment

Centered / Left aligned

Content density

Versión con o sin ciertos campos opcionales dentro del mismo modelo.

7. A Variant is NOT

No es una variante cuando agregamos:

New functionality

Por ejemplo:

Text + Media → Text + Media + Contact Form

Fundamentally different structure

Por ejemplo:

Text + Media → Interactive Cards Grid

New integration

Por ejemplo:

Static Map → Map connected to an external locations API

New logic

Por ejemplo:

Cards Grid → Cards filtered according to user selections

New responsibility

Cuando el bloque empieza a resolver un problema funcional diferente al componente original.

En estos casos debe evaluarse:

nuevo componente o reclasificación de complejidad.

8. Point System

Cada tier tiene un valor relativo de puntos.

Tier	Points	Reference equivalence
S	1	—
M	3	1 M = 3 S
L	6	1 L = 2 M
12	XL	1 XL = 2 L = 4 M

Los puntos representan una unidad de scope relativo.

No representan:

horas;
días;
precio;
story points;
una estimación exacta de Development.

Sirven para limitar y administrar el tamaño relativo del sistema de componentes.

9. Component Budget

Todo Component-based Website debe tener un Component Budget definido en el SOW y Project Definition.

Ejemplo:

Component Budget: up to 120 points

El budget establece cuánto sistema de componentes está incluido dentro del engagement.

La distribución inicial por tiers debe existir como referencia.

Por ejemplo:

Tier XL – Estimated Quantity 3
Tier L – Estimated Quantity 7
Tier M – Estimated Quantity 9
Tier S – Estimated Quantity 8

Pero Discovery puede modificar esa composición manteniéndose dentro de las reglas del budget.

10. Reference Project Size

El análisis histórico realizado sobre sitios de /nk mostró como referencia:

Enfamil

XL: 4
L: 13
M: 13
S: 11
Total: 41

Pomelo

XL: 7
L: 17
M: 20
S: 3
Total: 47

Ambos proyectos funcionan como calibration examples, no como objetivo para nuevos proyectos.

De hecho, fueron identificados como sistemas con una cantidad particularmente alta de componentes.

El objetivo del estándar es fomentar:

reuse + variants + consolidation

antes que crear un componente nuevo para cada necesidad.

11. Reference Ranges

Como referencia para un Website de tamaño medio, el análisis inicial propone:

Tier XL – Reference Range 3-5
Tier L – Reference Range 6-8
Tier M – Reference Range 8-10
Tier S – Reference Range 6-10
Total ~23–33 components

Estas cantidades no constituyen un paquete obligatorio.

Funcionan como referencia para detectar proyectos que se alejan significativamente de un sistema razonable de componentes.

El presupuesto real debe definirse según el proyecto.

12. Reference Point Budget

Aplicando el sistema de puntos a esos rangos:

Tier XL – Range 3-5 – Points 12 – Aprox subtotal 36–60
Tier L – Range 6-8 – Points 6 – Aprox subtotal 36–48
Tier M – Range 8-10 – Points 3 – Aprox subtotal 24-30
Tier S – Range 6-8 – Points 1 – Aprox subtotal 6-8

Como referencia operativa, puede considerarse:

~120 points

como un Component Budget representativo de un Website de tamaño medio.

Esto no significa que todos los Websites deban venderse con 120 puntos.

Un proyecto puede tener, por ejemplo:

60 pts;
90 pts;
120 pts;
160 pts;

dependiendo de su tamaño y complejidad.

13. Rules by Tier

S / M

Existe mayor flexibilidad para redistribuirlos durante Discovery.

Pueden utilizarse como una bolsa relativamente flexible dentro del Component Budget siempre que:

se mantenga la naturaleza funcional del proyecto;
no aparezcan integraciones nuevas;
no aparezca lógica estructural nueva;
no aumente materialmente el riesgo.

L

Debe existir una cantidad estimada y un límite razonable.

Un aumento importante de componentes L puede alterar significativamente el esfuerzo total aunque el número bruto de componentes permanezca similar.

XL

Los XL necesitan mayor control.

Siempre que puedan identificarse antes del proyecto, deben quedar nombrados en el SOW / Project Definition.

Por ejemplo:

Included XL Components:

Interactive Hero
Locations Explorer
CRM Form

Un nuevo XL no contemplado inicialmente requiere un Scope Review, incluso cuando existan puntos disponibles.

Los puntos por sí solos no capturan todos los riesgos asociados a un XL.

14. Using Points During Discovery

Discovery puede redistribuir el Component Budget.

Por ejemplo:

El scope inicial contiene:

2 L = 12 pts

pero Discovery demuestra que la mejor solución son:

4 M = 12 pts

Esto puede realizarse sin modificar comercialmente el scope.

También puede ocurrir:

1 L inicialmente estimado = 6 pts

termina resolviéndose como:

1 M = 3 pts

Los puntos liberados pueden reutilizarse razonablemente dentro del sistema vendido.

El objetivo es poder optimizar el sistema sin renegociar cada componente individualmente.

15. Points are NOT a blank check

Tener puntos disponibles no implica que cualquier requerimiento pueda agregarse automáticamente.

Por ejemplo:

“Tenemos 12 puntos disponibles, agreguemos una integración nueva con Salesforce.”

no es necesariamente válido.

Una nueva integración puede introducir:

dependencies;
APIs desconocidas;
authentication;
security requirements;
client stakeholders;
data mapping;
error states;
testing complexity.

Por eso ciertos cambios requieren Scope Review aunque matemáticamente entren dentro del budget.

16. Complexity Changes During Discovery

La clasificación inicial puede cambiar al obtener nueva información.

Por ejemplo:

M → L

porque Discovery descubre:

múltiples estados;
filtros;
motion complejo;
comportamiento dinámico.

Ese cambio no implica automáticamente un Change Order.

Primero debemos observar el Component Budget total.

Puede ocurrir que otros componentes se simplifiquen y el scope global continúe dentro del envelope acordado.

17. Scope Review Triggers

Debe realizarse un Scope Review cuando, entre otros casos:

Component Budget proyectado supera el acordado.
Aparece un nuevo XL.
Aparece una integración nueva.
Aparece lógica no contemplada.
Un componente cambia significativamente de complejidad.
Se agregan funcionalidades.
Aparece un nuevo subsystem.
Se intenta tratar como variante algo que cambia fundamentalmente la estructura o función.
La cantidad de L/XL aumenta materialmente respecto de la distribución inicial.
Una assumption utilizada para clasificar un componente deja de ser válida.

18. Scope Review Outcome

Scope Review no significa automáticamente pedir más presupuesto.

Primero debe analizarse si el cambio puede absorberse mediante:

simplificación;
reutilización;
variants;
consolidación de componentes;
reemplazo de otro componente;
redistribución del Component Budget.

Si no puede absorberse razonablemente, deberá gestionarse mediante:

Project Health & Change Control

y eventualmente:

Scope Adjustment
Timeline Adjustment
Change Request
Change Order

19. How to use it in the SOW

El SOW debería dejar visible el límite del sistema sin obligar a definir anticipadamente toda la solución.

Ejemplo de wording:

Component System
The project includes a component budget of up to 120 points, based on /nk's component complexity framework.
Components are classified as S, M, L or XL according to their layout, interaction, animation, state, logic and integration complexity.
The final component definition and distribution will be refined during Discovery while remaining within the agreed Component Budget.

Cuando existan XL conocidos: