Appearance Attribute
The product’s design is clean, modern, and consistent, ensuring a distraction-free experience
Author: Jay Thomas
Creator of the framework “Think Like the User”
Introduction
The Appearance attribute is responsible for the visual presentation and logical structure of the interface. A well-crafted appearance ensures a modern, clean design that doesn’t distract the user from their tasks. Appearance lays the groundwork for future Usability: first, you create an aesthetically pleasing and clear interface, then you test how easy it is to use during usability testing. The link between these attributes is backed by the aesthetic-usability effect: users often perceive beautiful products as more user-friendly. In short, strong visual design builds trust in the product and the interface itself—sites that look professional and well-organized are immediately seen as more reliable.
Appearance is a unique attribute in that it focuses more on creating the solution than researching it. While other attributes are about gathering insights (needs, problems, ideas) and validating concepts, working on Appearance means directly designing the final UI mockups. The method below is based on a step-by-step process through six interconnected layers of design. Each layer adds a new level of “depth” to the interface—from understanding user behavior to building a coherent design system.
When to Work on the Attribute?
You start working on the Appearance attribute only after the value of functional solutions has been confirmed and user needs are fully addressed—that is, once the Functionality and Reliability attributes are complete. In simple terms, visual design should be developed when you're ready to move on to final interface design (hi-fi mockups) before the last stage of usability testing.
You may also revisit the Appearance attribute when building or scaling a product’s design system. However, it’s best to focus on a full-fledged design system only after the core functionality is defined and there’s a clear understanding of the product’s future direction.
Let’s break down the entire process in detail.
Preparation
Define Goals and Constraints
Before diving into visual design, clearly define the boundaries: what kind of impression the interface should leave (e.g., modern, minimal, trustworthy), what brand guidelines and standards already exist, and which devices and platforms need to be supported. At this stage, gather all foundational materials:
Brand and style: brand colors, fonts, existing style guides, logos. These elements will set the tone for your design and ensure brand recognition.
Competitor analysis and references: review how similar products are designed (especially successful SaaS or internal tools). Take note of good visual hierarchy, color schemes, and iconography. Create a moodboard or a collection of references that reflect your desired style.
Target audience: consider user preferences and usage context. For example, an internal corporate tool can be more utilitarian and strict; a consumer-facing product should be more emotionally appealing. Account for cognitive and physical traits of the audience—user expertise, possible impairments (e.g., color blindness, vision)—and ensure adequate font size and contrast from the start.
Tools and Environment
Set up your workspace:
Configure your style library: define a color palette, text styles, and grid system. Use design tokens or document styles in professional tools to keep everything consistent.
Prepare screen templates or wireframes based on user scenarios validated during the Reliability phase. You should have prototypes or wireframes of key screens—these will now be visually refined. If you already have prototypes, make sure they reflect the final, approved functionality.
Layer-Based Planning
The Appearance methodology moves through six distinct design layers. It helps to outline a plan for each layer:
What problem does each layer solve in your project?
What decisions or principles will you apply at this level?
What output do you expect before moving to the next layer?
This kind of table ensures you don’t miss anything. The preparation phase is complete when you have all the required input and a plan for each layer. Now you're ready to move into layered visual development.
Development (Layer by Layer)
Each design layer is worked through sequentially (sometimes partially in parallel, where appropriate). It’s important to understand that layers are interdependent: decisions made on earlier levels affect the ones that follow. Below is a breakdown of each layer—its role, guiding principles, quality checks, and expected output.
Behavioral Layer
Role and Purpose
The behavioral layer is the foundation of design. Here, we account for users’ cognitive traits and habits to create an interface that aligns with their mental models and expectations.
The goal of this layer is to define how users will perceive and interact with the interface: what they notice first, how they understand elements, and whether the layout overwhelms them. In essence, the behavioral layer is about making the design intuitive and minimizing cognitive load.
Principles and Patterns
At this stage, the designer relies on UX principles, perception laws, and cognitive patterns. Key concepts include:
Reducing cognitive load. The interface should require minimal mental effort to understand. Apply Miller’s Law (“7±2”): short-term memory holds 5–9 items at once. Don’t overwhelm the user with too many visible elements.
Break information into smaller chunks, group related items. For example, split a long registration form into multiple steps to prevent overload.
Limit the number of simultaneous choices—users make decisions faster (Hick’s Law: choice time grows with number of options). If there are many options, structure them using filters, categories, or progressive disclosure (show extra details only when needed).
Attention constraints. Users’ attention is scattered and short-lived. Key elements must be immediately visible—achieved through visual hierarchy (covered in the visual layer).
Don’t force users to remember information between screens—display it again if needed. For instance, if a step requires previously entered data, show it on screen (pattern: Reduce Short-Term Memory Load).
Apply the principle of “recognition over recall”: interfaces should show visual hints and familiar imagery rather than making users remember things. Use common icons and metaphors (trash can for delete, magnifier for search), clear button labels. This increases predictability.
Intuitiveness and predictability. Interfaces are intuitive when new users instantly “get it.” Standard interaction patterns help here: gear icon for settings, logo top-left linking to homepage, save button at form bottom, etc.
Respecting these informal standards avoids unnecessary confusion—users don’t have to figure out how to perform basic actions. This conserves cognitive energy and creates comfort.
Also, every UI element should visually imply its function (affordance): e.g. clickable items should look distinct (underlined text, raised button) so users intuitively know they can click them.
Supporting decision-making. A good UI guides users toward optimal actions, reducing hesitation. As mentioned with Hick’s Law—don’t clutter the screen with dozens of equal choices. Highlight the recommended action (e.g., a bright “Add” button on an empty list screen). Move secondary actions to menus or separate screens.
Use visual emphasis for primary CTAs—contrast, size. Style secondary actions as text links or light buttons. This clarifies the user's path forward.
Error prevention. From a behavioral perspective, the interface should reduce the chance of user mistakes. This is a visual concern too: disabled buttons until fields are filled, warnings before risky actions, delete confirmations, etc.
Use the Error Prevention pattern: show helpful markers or hints when a user may be doing something wrong.
At this stage, define where validation, error messages, or confirmations are needed. The final visuals are implemented later, but the logic is built here.
Validating the Layer
How do you know the behavioral layer is solid? Use a cognitive walkthrough: mentally go through key product flows as a new user. Are there places where someone might get confused, overloaded, or miss a cue?
Cross-check with HCI (Human-Computer Interaction) laws and usability heuristics: does it follow Nielsen’s principles (match with real-world logic, consistency, error prevention, minimalist design, etc.)?
List the cognitive patterns applied—e.g., “Menu items limited to 7,” “Autocomplete in search field to reduce typing,” “Color coding for required steps”—and ensure they’re present in the mockups.
If possible, run a quick internal test: show mockups to uninvolved colleagues—do they instantly understand what screen they’re looking at, where to click, and what matters? Their fresh perspective may reveal blind spots.
Output
By the end of the behavioral layer, you should have a set of design decisions rooted in user behavior. Practically, this looks like annotated wireframes or sketches documenting:
What elements are essential per screen (based on user tasks).
Where help text or tooltips are needed.
Which UI patterns are used (button placements, icon conventions, input validation, etc.).
How cognitive overload is avoided (e.g., tabs instead of long lists, multi-step flows for complex tasks).
The behavioral layer is mostly invisible to users, but critical: if it’s done well, the user will simply feel that “everything just makes sense”—without realizing how much thought went into that clarity.
Functional Layer
Role and Purpose
The functional layer defines the structure and composition of the interface—essentially, it’s the skeleton of your product. At this level, we move from abstract principles to concrete UI components and screen templates that users will interact with to achieve their goals.
The goal here is to design the necessary elements (navigation, buttons, forms, lists, tables, cards, etc.) and place them in a way that makes the interface logical, consistent, and supportive of user scenarios. The functional layer ensures that all needed features are present and organized in a way that makes sense.
In other words, this is where we ask: what blocks make up each screen, how does the user move between them, and where are the buttons located? This layer is closely tied to UX architecture—it transforms functional requirements into actual mockups and wireframes.
Principles and Approaches
Key approaches in the functional layer include:
Modularity and reusability. Design should be built from modular components that can be reused across the product. This isn’t just efficient—it also boosts usability. When users encounter familiar components, they don’t have to relearn how to use them.
For example, a customer or item card should look and behave the same in listings, search, and reports. This modular approach starts with designing reusable blocks (search bar, user profile panel, navigation menu) and later combining them. (This also forms the basis of the design system in the organizational layer.)
Example: In a CRM, the contact card appears in the clients section, in deals, and in analytics. If designed once and thoroughly, it guarantees consistency and saves time when building new sections.
Logical structure and component hierarchy. Every screen should have a clear organization: primary elements should be placed higher and more prominently; secondary ones grouped or minimized. Even before detailed visuals, the functional layer already implies visual hierarchy—for example, placing key metrics at the top of a dashboard and secondary tables below.
The screen should reflect the user’s task flow. The rule “focus on the task, minimize distractions” means: only include what’s needed for the current task—no more. Anything irrelevant should be moved or hidden.
Example: In a task tracker like Asana, the project task list shows essentials (task name, assignee, deadline), while task details are hidden until clicked—this is progressive disclosure, keeping the screen clean until details are needed.
Consistency and standardization. This layer defines uniform templates: identical elements should look and be placed identically. This makes the UI predictable for users and easier to maintain for teams.
Example: In document editors (Google Docs, MS Word), the toolbar and menus look and behave similarly across all documents—users don’t waste time searching for functions due to consistent design.
Flexibility for different user levels. Well-structured functional design supports both beginners and power users. Beginners get a clear, simple path (nothing hidden); experts get shortcuts and batch actions. These options should be considered here—e.g., checkbox selection + “Delete selected” button, or toggle between compact and expanded list views.
Example: In email apps, there are both buttons for each action (for beginners) and keyboard shortcuts (for pros), as well as view toggles. All of these should be represented in the functional mockups.
Validating the Layer
Test the quality of the functional layer through usability-focused mockup reviews (even before final design):
Scenario coverage: Confirm that all user goals are covered with corresponding UI steps. Are any functions missing UI? Are there screens that serve no purpose?
Task efficiency: Do a heuristic review—how many steps does it take to complete a typical task? Can it be simplified? Is it obvious where to click first and next?
Consistency review: Check all screens side-by-side. Do they share structure? Do navigation, headers, and button placements repeat? Can you describe a rule like: “Every list view has a title and an ‘Add’ button at the top, filters on the right”? If there are inconsistencies without strong reasons—align them now before moving to visual design.
Output
At the end of this layer, you should have prototypes with the main interface components in place. These mockups:
Cover all essential product functionality.
Have logical navigation between them (clear links, menus, transitions).
Contain a consistent set of standard components.
Are stripped of excess—every element has a clear user purpose.
In short, this stage results in a functional “skeleton” of the product, ready to be “painted.” The next steps will enhance it with visuals, interactivity, and content.
Visual Layer
Role and Purpose
The visual layer defines the aesthetics and graphical presentation of the interface. This is where the design "comes to life" visually—color palettes, typography, button and field styles are established, and the overall look and feel of the product is shaped. The main goal is to make the interface visually clear and pleasant to use, with a strong visual hierarchy that guides the user to what’s important and what’s secondary. This layer also ensures brand consistency—every element must reflect the product's identity.
Well-crafted visual design reduces cognitive load (good organization naturally directs attention) and increases user satisfaction. Studies show that users perceive attractive interfaces as more usable and even more trustworthy. So, visual design indirectly builds trust: a clean, modern look signals reliability.
Principles and Approaches
The visual layer is based on fundamental design principles: color, contrast, typography, balance, alignment, and visual unity. Key ideas include:
Gestalt principles of perception. These psychological laws explain how people visually group elements. In UI, they help organize layout:
Proximity: Items placed close together are perceived as a group. Use this by positioning related elements near each other (e.g., label right above the input, OK/Cancel buttons side by side).
Similarity: Elements that look similar (in color, shape, size) are seen as related. So, all primary buttons should look the same; secondary ones should share a different consistent style.
Figure-ground: The mind separates foreground from background. Design should clearly distinguish focus elements (like modal windows) from background layers. Strong contrast supports this.
Closure: Bordered or boxed elements are perceived as a group. Use cards, panels, and outlines to visually bundle related items—like placing all filters inside a thin-bordered box.
These principles help users quickly see structure, even before reading anything.
Visual hierarchy and emphasis. Guide the user’s eye using:
Size and scale: Bigger = more important. H1 headers should be largest, primary buttons more prominent than others.
Contrast: Use tonal or color contrast to highlight important elements. High contrast = more visibility.
Accent colors: Stick to 1–2 accent colors (e.g., blue for actions, red for errors, green for success). Use neutrals elsewhere to keep attention on what matters.
White space: Space is power. Generous spacing improves readability and reduces overload. Group spacing shows relation; inter-group space shows separation. Less is more—as long as elements "breathe," the layout looks clean.
Typography and readability.
Choose screen-optimized fonts (sans-serif, grotesques). Use no more than two font families.
Set clear typographic hierarchy—e.g., H1 = 24px bold, body = 16px, captions = 12px gray. Repeat these sizes consistently.
Use left-alignment and limit line width to ~60–80 characters for legibility.
Ensure text contrast passes accessibility standards (dark-on-light or light-on-dark).
Unified style and branding. All visuals must reflect the brand’s tone. Use custom illustrations and icons where available. If not, keep visual choices consistent: same icon style, line weights, corner radii, shadows, etc.
Use design tokens—fixed values for color, spacing, border radius, shadows. Example: all buttons use a 4px corner radius, never 8px.
This consistency builds trust and recognition. Users subconsciously trust interfaces that feel visually coherent—and they learn to use them faster.
Validating the Layer
Evaluate visual design quality via design reviews:
Visual hierarchy: Do a 5-second test—ask someone what they noticed first on a screen. If it’s not what you intended, adjust your emphasis.
Consistency: Scan all screens side by side—are styles consistent? No odd button shadows or border thickness variations?
Contrast and readability: Convert screens to grayscale—does text remain readable? Do elements still stand out as intended?
Brand alignment: Cross-check against brand guidelines. Are brand colors and illustration styles applied correctly? Does it look like it belongs to the company?
Output
The output of this layer is high-fidelity (hi-fi) design mockups of all screens, fully styled and polished. These:
Include applied colors, typography, icons, in line with the chosen style.
Clearly reflect information hierarchy (important elements stand out).
Look clean, modern, and trustworthy.
Follow a consistent style and brand identity.
These mockups are presentation-ready for stakeholders and teams. This is the “finished exterior” of your product—now ready to be made interactive and filled with real content. Think of it as a built and painted house—next step: turn on the lights (interactivity) and bring in the furniture (content).
Interactive Layer
Role and Purpose
The interactive layer defines how the interface responds to user actions and adapts to various devices. Once static mockups are ready, this layer focuses on dynamic behavior: what happens on hover, click, page transitions, data loading, or on mobile. The goal is to make the interaction smooth, responsive, and predictable. The user should feel the interface is alive, reacts instantly, and always provides feedback that their action worked.
Principles and Patterns
Key aspects of the interactive layer include:
Feedback & Responsiveness. Every user action must trigger an immediate system response—no guesswork.
Examples: pressed button highlights, loading indicators, "Saved" messages. Even for long actions (like loading), give instant visual feedback (e.g., button changes to “Loading…” immediately).
Component States. Every interactive element needs defined states: default, hover, active, disabled, focused, etc. These must be designed and communicated clearly.
Example: A greyed-out “Send” button with a tooltip “Please fill out required fields” prevents errors and clarifies why it's inactive.
Microinteractions & Animations. Small animations improve flow and give helpful cues—like tooltips on hover, smooth transitions, or subtle button effects. Keep animations short (200–300 ms) and purposeful.
Example: Hovering over a graph highlights a data point with a tooltip—extra detail without a click.
Responsive/Adaptive Design. The layout must adapt to all screen sizes—from phones to large monitors. This includes collapsing menus, scaling tables, adjusting paddings and font sizes.
Example: A 3-column layout on desktop becomes 2, then 1 column on mobile; side navigation becomes a hamburger menu.
Predictable Motion. All transitions must follow consistent patterns. For example, all modal dialogs fade in over a darkened background. Avoid inconsistent behaviors (e.g., popups sometimes sliding from left, other times from bottom). Predictability lowers cognitive load. Define clear motion standards.
Contextual Feedback. Show system responses near the user’s action, not elsewhere on the screen.
Example: A form field with a validation error shows red text directly beneath it—not just a toast in the corner.
Error Tolerance and Undo. Allow users to recover from mistakes easily.
For destructive actions, show confirmation dialogs.
Warn users if something partially failed.
Optionally add "Undo" for actions (like a deleted item sliding away with an “Undo” button for 5 seconds). This builds user confidence—they don’t fear misclicks or irreversible errors.
Validating the Layer
To validate the interactive layer:
Build an interactive prototype (in Figma or another tool) with real transitions and states. Walk through main flows—can you tell where to click? Are interactions instant and understandable?
Test on multiple devices and screen sizes—do elements stay visible? Is content clipped or misaligned?
Involve front-end developers to review animation feasibility and performance (e.g., avoid heavy transitions that slow things down).
Run a quick hallway test: give users a phone or laptop with the prototype and ask them to complete a few tasks. If they’re unsure whether something clicked or can't find a control, that’s a sign to improve the interactivity or layout.
Output
The result is a fully interactive prototype:
All screens are connected with transitions, including modals and dropdowns.
All interactive elements have clearly defined states (e.g., button: normal/hover/disabled/active; input: empty/focus/filled/error).
Animations are specified or shown—screen transitions, loaders, microinteractions.
Responsive versions of key screens are created (typically separate mobile layouts).
This stage delivers a demo-like experience, ready for usability testing—real users can now interact with it as if it were the actual product.
Content Layer
Role and Purpose
The content layer focuses on the textual and media content within the interface. Any digital product is not just buttons and forms—it’s also words: button labels, page headings, error messages, tutorials, notifications, images, icons. A well-designed content layer makes the interface clear, informative, and friendly. Its goals:
Ensure clarity: every element should be immediately understandable through labels, hints, and prompts.
Ensure informativeness: provide context, explanations, and examples when needed.
Maintain a consistent tone of voice, aligned with the brand and context (formal in some places, casual in others).
Ensure content accessibility: account for different user needs (translations, alt text, screen readers).
Principles and Practices
The content layer is guided by UX writing and content design principles:
Clarity and brevity. UI text must be concise yet informative. Users scan—they don’t read novels. Use clear, active voice. One idea per UI element.
Example: Instead of “Click here to save your settings,” write “Save settings.” Instead of “Your profile lacks an email, so you can’t reset your password,” write “Add email to reset your password.”
Helpful hints and guidance. When actions require a specific input or format, add a hint—via placeholder, helper text, or tooltips. Keep it minimal and context-relevant.
Example: Below a phone input: “10 digits, no country code.” Cuts down user errors.
Consistent tone of voice. All text—from titles to system messages—should reflect the brand’s personality.
Banking app → formal, calm tone.
Youth app → informal, friendly tone. Match emotional context: errors should sound empathetic (“Couldn’t load. Check your connection”), success should sound upbeat (“Done! Task completed”). For example: Financial system: “Report generated successfully.” Team app: “Great! Your report’s ready.” Different tones—both consistent within their product.
Terminology consistency. Use the same term for the same thing everywhere. If you say “Tasks,” don’t also use “Tickets” or “Items.” Maintain a glossary and editorial rules—especially when multiple people write content.
Content accessibility. Closely tied to the accessibility layer:
Add alt text to important images for screen readers.
Use simple, clear language—avoid idioms, slang, or ambiguity.
Plan for translation—allow space for longer strings in other languages.
Don’t rely on color alone for meaning (e.g., red for errors must be accompanied by text/icon). Example: A chart with colored lines must also have labels or textures for users who can’t distinguish colors.
Ensure fonts are readable, with a minimum acceptable size.
Validating the Layer
To validate content:
Proofread and edit. Every line should be checked for grammar, tone, and clarity. Ideally done by a UX writer or editor.
Comprehension testing. Give interface texts (e.g., menu items or error messages) to someone unfamiliar with the product—can they understand what they mean without additional context?
Content usability testing. During broader usability testing, watch for points where unclear text leads to mistakes. You can also run A/B tests on labels (e.g., “Finish” vs “Done” vs “Save changes”) to see which is clearest. Content is part of the experience—it can and should be iterated.
Output
At this stage, all mockups are filled with final content—no more lorem ipsum. Users now see real labels, messages, and visuals. Ideally, text is already legally approved and ready for localization if needed.
A key artifact might be the Content Guidelines—a document or design system section outlining tone, terminology, examples of good vs bad copy. It ensures consistency across future content creation.
Once the content layer is complete, your design becomes complete: visually appealing and intellectually clear. A user landing on a screen understands what product they’re in, what actions are possible, and what’s expected.
Organizational Layer
Role and Purpose
The Organizational Layer systematizes all design components and processes. It's the meta-layer that ensures consistency and standardization across the entire product interface and supports collaboration between team members. While previous layers focus on individual UI aspects, the organizational layer is responsible for building and maintaining the design system—a structured set of reusable rules, components, and styles.
Layer goals:
Compile all visual components, styles, and patterns into a centralized library.
Enable scalable updates—e.g., changing a brand color once and applying it system-wide.
Prepare developer handoff materials: specifications, component documentation, spacing and sizing guidelines.
Establish version control and communication processes across the design team, developers, and product managers.
Principles and Approaches
Best practices for building a design system shape the Organizational Layer:
Single Source of Truth. Everything—from color palettes to coded components—should be centralized and accessible to the team. This is often done using tools like Figma (style libraries) + Storybook (coded components). Designers and developers should refer to the same specs to avoid discrepancies.
Modularity and Reusability. What was introduced at the functional layer becomes a component library here. Each commonly used element (button, input field, card, modal, etc.) is defined as a reusable component with adjustable parameters.
Example: A SaaS analytics product might include chart, table, and filter modules that are recombined across pages. This speeds up work and ensures visual consistency.
Thorough Documentation. Beyond the component library, usage rules must be documented. Each component needs usage guidance, examples, do’s/don’ts, spacing/grid rules, color combos, and responsiveness principles. The docs must be clear and accessible to the entire team.
Example: A large-scale platform's design system has sections for buttons (with examples and code), forms (with validation and error handling), navigation, etc. This helps onboard new team members and maintain interface consistency.
Scalability and Flexibility. A product grows—new features, platforms, and teams emerge. The design system must accommodate this. When adding a new product module, designers should be able to construct it using existing atoms/molecules, extending the system only when necessary and without breaking existing patterns.
Example: A mobile banking library is structured so that new service screens can be built from pre-made elements (headings, lists, cards), with minor additions like new icons—all in the same style.
Version Control and Team Sync. As the system evolves, changes must be tracked and communicated. Example: a new heading style is introduced—it must be shared and adopted across the board. Use repositories (e.g., Git for coded components) and change logs to coordinate. Notify everyone of updates.
Atomic Design is often used here to structure the design system:
Atoms—basic building blocks (buttons, icons, input fields, colors).
Molecules—functional combinations of atoms (e.g., a search bar = input + button).
Organisms—complex UI blocks made of multiple molecules (e.g., site header with logo, search, nav, avatar).
Templates—layout skeletons that arrange organisms into structure.
Pages—final screens filled with real content.
In the design stage, you’ve been creating organisms and templates. The Organizational Layer catalogs them. Change the atom “heading font” once—and every molecule and organism using it updates automatically. This makes the system manageable and scalable.
Validating the Layer
The Organizational Layer is considered complete when:
The design system covers all elements used in the product (no one-off elements that exist only on a single screen).
The team can assemble new screens using just the system documentation.
Key changes (e.g., main brand color) can be made once and propagate everywhere automatically.
Conduct an audit: pick a few live screens and verify that every element is present in the system. If not—either add it or revise the screen to use existing components.
Developer feedback: is the component library practical? Are there mismatches between mockups and coded elements? Continuously refine documentation based on this.
Output
At this stage, the product’s design system is fully formed:
Component library (in design tools like Figma, and in code).
Documentation/guidelines covering component usage, spacing, styles, screen examples.
A governance process—who maintains the system, how changes are made and shared.
The design system becomes a living artifact. New team members or vendors can quickly onboard. Internal teams speak a shared language (e.g., “This is the Project Card organism—it’s documented, grab the code/design from the system”).
Once the Organizational Layer is complete, the Appearance attribute is fully implemented. The interface isn’t just visually polished—it’s structurally organized for development and scalable growth.
Conclusion
To sum up: a methodical approach to the Appearance attribute is labor-intensive, but absolutely essential. As a result, you get a cohesive design product—an interface that not only looks modern and attractive, but is also logically structured, grounded in behavioral principles, filled with clear content, and documented in a system ready for future growth.
This approach greatly increases the chances that users will perceive your product as both user-friendly and trustworthy, and that the development team can implement and scale it efficiently. Appearance is the face of your product—and now that face is polished, professional, and thoughtfully crafted.
Jay Thomas
A UX strategist with a decade of experience in building and leading UX research and design teams. He specializes in implementing Jobs to be Done (JTBD) methodologies and designing both complex B2B admin panels and high-traffic consumer-facing features used by millions.
Previously, he led UX development at DomClick, where he scaled the UX research team and built a company-wide design system. He is a guest lecturer at HSE and Bang Bang Education and has studied JTBD at Harvard Business School.
Jay has worked with ONY, QIWI, Sber, CIAN, Megafon, Shell, MTS, Adidas, and other industry leaders, helping them create data-driven, user-centered experiences that drive engagement and business growth.
