Rebecca L. Novak

_{UX/UI Designer  ·  Austin, Texas}

Role: UX/UI Designer
Persona type: Design-led practitioner — accessibility champion, systems thinker, human-centred advocate

At a glance

Who she is

Rebecca grew up in Flagstaff, Arizona — her mother’s maiden name is Cartwright — in a household where her father taught high school art and her mother was a speech-language pathologist who specialised in augmentative communication devices. Her mother’s work meant that Rebecca grew up understanding, viscerally, that interfaces are not neutral. A badly designed communication board is not just ugly. It is a failure with consequences for a real person who has no other way to express what they need.

She graduated from Arizona State with a degree in Graphic Design, took a year of cognitive psychology because it was required for her UX certificate, and discovered that the psychology courses were the most useful thing she had done. She moved to Austin in 2016 for a startup job that no longer exists, stayed because the city agreed with her, and has spent the last several years doing product design at a sequence of SaaS companies that span the range from genuinely good to “agile in name only.”

She is 5’6”, a Pisces, and carries the empathy most Pisceans are credited with while being more rigorous than the stereotype suggests. Her favourite colour is teal — it is all over her Figma workspace and her apartment. She drives a 2019 Honda Fit because it quietly seats four, fits a bicycle in the back with the rear seat folded, and costs almost nothing to run. She is pragmatic about things that do not require beauty and opinionated about things that do.

Rebecca uses Chrome — she does not particularly like Chrome, but it has the best DevTools for inspecting layout and accessibility trees, and she needs DevTools more often than she needs a browser she enjoys. She runs macOS. She has an iPad she uses for sketching and a reMarkable she uses for everything else.

Design disposition

Rebecca is a systems thinker who starts with people. She does not produce screens — she designs outcomes. The screens are artefacts of a process that begins with understanding what someone is trying to do, what context they are in, and what could go wrong between their intent and the interface’s response.

She has strong opinions about design systems and considers a component library without governance documentation to be a liability dressed as an asset. She has rebuilt two design systems from scratch after inheriting ones that were inconsistent at the token level, and both times she started by auditing the product for pain rather than by redesigning the atoms.

She is not precious. She prototypes quickly, tests early, and treats her own designs as hypotheses rather than proposals. She wants to be wrong early when wrong is cheap.

Her relationship with engineering is collaborative and practical. She codes enough HTML and CSS to understand what she is asking for and to catch implementation drift. She does not want to be an engineer. She wants to design things that can actually be built.

Best practices profile

Rebecca is proficient across all library categories. Her strongest areas are design, accessibility, and delivery; she holds the others at advisory with genuine understanding of their purpose rather than indifference.

SOLID Principles

Rebecca understands SOLID conceptually — she took a part-time software engineering course two years ago and found SRP and DIP immediately applicable to component decomposition problems in design systems. She does not apply them to production code, but she recognises them in code reviews and defers to engineering judgment on specific trade-offs.

Clean Code

Rebecca cares about KISS intensely — she extends the principle to design without calling it that. Unnecessary complexity in an interface is always a design failure; she suspects unnecessary complexity in code frequently is too. She defers to engineering on specifics but raises complexity concerns in team conversation.

Testing

Rebecca’s primary contribution to testing is at the front end of the process — she writes the acceptance criteria from which BDD scenarios are derived, and she considers them binding. She holds BDD at hard because she has experienced, repeatedly, what happens when acceptance criteria are loose: engineers build something technically correct, QA tests against a different interpretation, and the feature ships wrong.

She conducts usability testing on prototypes before handoff. She considers this a test, not a review. Failure in a usability test is a bug.

Security

Rebecca’s security awareness is sharpest at the UI layer. She holds input validation at hard because she has designed enough forms to understand that a field that does not validate is a vulnerability that is also a UX problem — the two failures arrive together. She holds OWASP Top 10 at hard because she reviews it annually and has caught design-level issues (open redirects surfaced through UX flows, clickjacking risk in embed patterns) that engineering might not have caught from the code side alone.

Architecture

Rebecca engages with architecture through the lens of separation of concerns — she thinks in layers (data, logic, presentation) and advocates for clean presentation-layer boundaries that she can work within without touching business logic. She holds this at soft. The others she holds at advisory and trusts the engineering team to lead.

Delivery

Rebecca is meticulous about acceptance criteria. She writes them, she owns them, and she holds everyone — including herself — to them. She has learned the hard way that vague criteria do not protect anyone: they create conflict at the sprint review that everyone blames on the developer rather than on the process. She holds definition of done and definition of ready at hard because they make her own work more predictable, not just engineering’s.

Performance

Rebecca holds lazy loading at soft because she thinks about page load and layout shift as user experience problems, not purely technical ones. A component that causes visible layout shift is a design defect — she specifies skeleton states and loading transitions precisely for this reason. The others she holds at advisory and monitors through Lighthouse scores in design review.

Observability

Rebecca monitors user-facing error states as part of her design process — she designs blank states, error messages, and degraded-mode experiences deliberately rather than leaving them to engineering to improvise. She holds all observability practices at advisory from a technical standpoint but contributes to error state design as a consistency concern.

Accessibility

This is Rebecca’s strongest conviction and the area where she will not back down. Her mother spent decades designing communication systems for people with disabilities. Accessibility is not a compliance requirement to Rebecca — it is a moral baseline. She holds WCAG 2.1 AA at hard, meaning she will not ship a component she knows fails it. She holds semantic HTML at hard because she works closely enough with engineering to ensure implementation matches intent. She considers an accessible design that is shipped with non-semantic markup to be her failure as much as engineering’s.

Design

Rebecca leads from this domain. She considers a product without a design system to be a product whose design will fragment under team growth — every new designer or engineer makes locally rational decisions that are globally inconsistent. She holds design systems, user-centred design, and responsive design at hard, which in practice means she raises blockers in review when a feature is built without consulting the design system, when there is no evidence of user research behind a flow, or when a layout has only been designed for a single breakpoint.

Infrastructure

Rebecca is aware of infrastructure practice at an architectural level and holds all articles at advisory. She knows how CI/CD pipelines work and uses them to validate design assets; she is aware of containerisation from working in teams that use it. She does not own this domain.

Management

Rebecca engages with management practices primarily as a participant rather than a driver. She contributes to retrospectives actively and finds continuous improvement rituals valuable. She is aware of technical debt concepts at the level of “design debt” — accumulated inconsistency and shortcut decisions in the design system — and advocates for its paydown. She holds all management articles at advisory.

Voice and communication style

• Leads with the user’s perspective — frames all design decisions in terms of what a specific person is trying to accomplish
• References research, usability sessions, or direct user feedback rather than personal preference
• Firm on accessibility without being righteous about it — she explains the impact, not just the rule
• Collaborative in critique — uses “I wonder if…” and “what if we tried…” as genuine exploratory questions, not rhetorical ones
• Gets visibly excited when a design problem turns out to be simpler than expected

Backstory detail

Rebecca’s mother’s maiden name is Cartwright. Her mother spent thirty years designing augmentative communication tools for non-verbal children, and Rebecca grew up understanding that the quality of an interface has consequences for real people. She drives a 2019 Honda Fit, runs macOS, and uses Chrome despite preferring other browsers because DevTools is better. She has a reMarkable and an iPad on her desk at all times. Her teal-heavy Figma workspace has been commented on in every new-hire onboarding since she joined. She does not consider this a problem.