A Communication Problem

The project started with a very familiar design problem. Teams knew when something felt wrong, but the critique often collapsed into vague language: make it pop, make it cleaner, make it more intuitive, make it feel premium.

The issue was not that the feedback was useless. The issue was that the feedback had no structure. It pointed to a feeling but did not define the signal, the intended meaning, the constraint, or the action that should follow.

That became the first version of SMA: a way to separate what a user or stakeholder is signaling from what the product should mean and what the system should do next.

The first insight was simple: feedback becomes useful when it can move from taste to signal.

At first, this was a critique framework. Then the same problem started appearing at a larger scale, not just in design feedback, but in the structure of websites themselves.

Separating the Interface from the Architecture

Traditional web design treats UI and IA as a single object. The navigation is the architecture. The page structure is the experience. Every user receives the same hierarchy, the same path, and the same sequence of decisions. The interface is built once and handed to everyone identically.

That model worked when information was static and audiences were homogeneous. Neither is true anymore. AI made the problem impossible to ignore because it removed the navigation burden of search without restoring the signal that search preserved.

The shift from search to AI collapsed the interface, but it also collapsed the meaning layer.

When UI and IA operate as separate layers, the architecture remains intact underneath while the surface adapts to the person using it. The same underlying system can serve radically different users without requiring two sites, two navigation structures, or two content strategies. The IA becomes the meaning engine. The UI becomes its output surface.

The interface should not make the user navigate the entire architecture to find the one path that was built for them. SMA's role is to design the meaning layer that makes the decoupling coherent.

Meaning as a System Layer

Separating the interface from the architecture solved one problem, but it exposed another. If the interface is no longer responsible for deciding what each user sees, where does that decision live? That question led to the core insight behind SMA.

Meaning should exist as its own architectural layer, positioned between raw signals and rendered outputs.

Instead of allowing interfaces, APIs, or AI systems to interpret data independently, SMA defines meaning once, then projects it consistently across every surface. That realization transformed SMA from a UX framework into a semantic architecture.

The diagrams below illustrate that evolution. The first introduces the protocol itself. The second shows how that protocol can shape both user experience and technical implementation.

Experience Avatars at the Data Layer

Experience Avatars are not decorative personas. They are data-layer constructs with UI projections. A persistent base identity carries who the person is, while environment, state, and active context determine what matters in the current experience. The system does not have to reconstruct intent from ambiguous behavior after the fact.

For developer platforms, that distinction matters because the same person may be evaluating a service, implementing it, debugging a failure, or responding to an incident. These are not separate users or separate avatars. They are contextual extensions of the same underlying identity. SMA keeps the architecture intact while adapting the experience around the user's role, task, state, and current workflow.

That was the important technical turn. The avatar stopped being a design artifact and became a contract: persistent identity combined with transient context before the interface adapts.

class ContextModifier(BaseModel):
    attribute: str
    multiplier: float
    axis: Literal["outer", "inner"]
    source: Literal["sensed", "declared"]

class ExperienceAvatar(BaseModel):
    identity:    Identity      # Role · Goal · Context
    environment: Environment   # Situational · Physical
    state:       State         # Intent · Load · Experience

Adaptive Developer Experiences

The SaaS demo is the clearest example of how SMA can apply to developer platforms. Although it was built as a marketing prototype, the underlying pattern is the same problem faced by developer portals, API documentation, onboarding flows, and internal platform tools: different users need different paths through the same technical architecture.

A new developer may need orientation, language-specific examples, and a low-friction path to first success. A senior platform engineer may need system constraints, integration details, observability hooks, and edge cases. SMA separates the canonical knowledge structure from the rendered experience, reducing cognitive load without duplicating content or fragmenting the platform.

Developer Dashboards & Observability

The FinTech dashboard demo shows how the same meaning layer can shape complex data surfaces. In a developer platform context, this maps directly to observability, troubleshooting, service health, deployment status, and productivity dashboards.

The core UX challenge is not just displaying more data. It is deciding which data matters for a specific user in a specific moment. A backend engineer, platform engineer, SRE, or engineering leader may all be looking at the same system, but they need different priorities, different warnings, and different next actions. SMA gives the interface a way to interpret signal before visual hierarchy is assigned.

Contextual Data Enrichment

The restaurant demo demonstrates how SMA separates a persistent base identity from temporary contextual extensions.

The base avatar represents the person. That identity remains stable over time. Remote Work, Date Night, and Family Dinner are not separate avatars or user types. They are active contexts that change which signals carry the most meaning for the same individual.

A single person may work from a café in the morning, meet family for dinner, and plan a date that evening. The person does not change. The venue data does not change. The contextual meaning projection does.

Google Places provides raw signals such as rating, price, location, category, and reviews. SMA adds the missing semantic layer that determines what those signals mean for this person in this situation.

During Remote Work, reliable Wi-Fi, outlet access, noise level, and session length become the highest priorities. During Date Night, ambience, lighting, conversation, and proximity become more important. During Family Dinner, seating flexibility, menu variety, parking, and tolerance for noise may take precedence.

The restaurants are identical in every scenario. The base person is identical. Only the active contextual extension and resulting meaning projection change.

This same pattern applies beyond restaurants. Developer platforms, enterprise applications, and AI systems all operate on large collections of raw signals. Repositories, services, deployments, incidents, ownership, telemetry, and documentation become useful only when interpreted through the user's current workflow, environment, and state.

def calculate_context_score(venue, avatar):
    context = avatar.active_context

    return weighted_average([
        venue.wifi_reliability * context.wifi_reliability["weight"],
        venue.noise_level * context.noise_level["weight"],
        venue.outlet_access * context.outlet_access["weight"]
    ])

class ExperienceAvatar(BaseModel):
    identity: BaseIdentity
    environment: Environment
    state: State
    active_context: ContextProjection

class RemoteWorkContext(ContextProjection):

    wifi_reliability = {
        "weight": 0.30,
        "scale": "0 = absent or unreliable | 10 = strong, consistent, confirmed",
        "evidence": ["reviews", "venue_tags", "photos"]
    }

    noise_level = {
        "weight": 0.25,
        "direction": "lower_better",
        "scale": "0 = quiet, sustained focus possible | 10 = loud, nightlife",
        "evidence": ["reviews", "time_of_day_mentions"]
    }

    outlet_access = {
        "weight": 0.20,
        "evidence": ["photos", "review_patterns"]
    }

Static Sites That Behave Dynamically

The demos are static pages, but the structure behaves like a dynamic system. Content, profile logic, constraints, and visual states are separated. The interface can change based on declared context without requiring a traditional app backend.

The law firm demo shows the embedded version of the method. Instead of creating a separate interface layer, SMA is embedded directly into a conventional site structure. The page still feels like a brochure site, but the hierarchy, cues, and interaction logic can adapt through the meaning layer.

The same idea applies to mature developer ecosystems where teams cannot rebuild every surface at once. SMA can be layered into an existing portal, documentation system, dashboard, or workflow surface incrementally, without forcing a full platform reset.

deployment: embedded
surface: law_firm_site
mode: avatar_driven
meaning_layer:
  identity: declared
  environment: inferred
  state: active
projection:
  human_ui: adaptive hierarchy
  schema: practice-area context
  tool_response: structured intent

Applying SMA to Developer Platforms

SMA was developed independently, but the architecture maps directly to developer platform problems: unified portals, platform service discovery, AI-assisted workflows, troubleshooting, observability, documentation, and the larger challenge of reducing cognitive load across complex technical systems.

The practical value is not that every developer gets a different product. The value is that one coherent platform can preserve a shared architecture while adapting the surface around the user's role, task, system state, and current workflow.

Prototype Architecture

The implementation is intentionally lightweight. It uses a static front end, JSON as a pseudo database, YAML files as semantic contracts, and Python/Pydantic examples to describe how the method could become a stronger typed system.

The point was not to overbuild a production app. The point was to make the architecture legible, prove the workflow, and show how a meaning layer could be authored, inspected, and projected across multiple surfaces.

This also made the project easier to evaluate as a technical design system. The important pieces are separated: front-end presentation, reusable data structures, semantic contracts, scoring logic, and AI-ready response patterns.

What the Work Demonstrates

SMA is a product design case study about making complex systems legible. It began with subjective design feedback, moved into information architecture, then became a broader framework for adaptive interfaces and AI-ready meaning layers.

The through-line is the same across every stage: reduce cognitive load without flattening complexity. Keep the architecture intact. Make meaning explicit. Let the surface adapt around the person, context, and task.

That is why the developer platform application matters. The hardest technical systems are not only hard because they are complex. They are hard because every user is forced to traverse the same complexity in the same way.

SMA is an argument for designing the layer between what a system knows and what a person needs next.