UX Designer • Design Systems & Accessibility

Where modern code meets clean, timeless craft.

What I do

I move fluidly between design and engineering.

Most designers panic at the thought of managing a codebase, but my web design background provided a strong foundation for systems design, accessibility, journey optimization, and interaction.

  • UX / UI / product design

    Deep research, simplifying complex flows, strategic information architecture, and behavioral testing to eliminate ambiguity. (See: SAD Trials, NAR App)

  • Design systems

    Layered tokenization, component libraries, native theming, clean documentation, and the governance to keep them honest. (See: LINEAR)

  • Development and engineering

    Prototyped and coded for React, Angular, Webflow, headless WordPress, and Three.js—whatever the brief calls for. (See: ClienTell, Contour)

  • CRO, flow and journey mapping

    Strategic sequencing, conditional branching, friction reduction, proactive transparency, and conversion optimization. (See: SAD Trials)

  • Brand experiences

    Products, websites, and other projects with a brand-forward or mission-driven vision. (See: Kevin Popke Foundation)

  • Inclusive, accessible design

    Keyboard navigation, ARIA labels, screen reader capability, color contrast, semantic code, and scalable typography. (See: LINEAR)

  • Machine Experience (MX)

    Structured for a world where agents and LLMs are increasingly the primary user.

My Projects

Check out my case studies in UX, design systems, and web development, including the processes and results behind each.

About Me

Your Friendly Neighborhood Design Archaeologist

Select to learn more

Contact Me

Let's build the damn thing.

Looking for a partner or "sidekick" with capable hands to get you through a complex website or mobile app project? Or are you hiring for a UX or systems-related role? Shoot me a message.

Client Website • Headless

Kevin Popke Foundation Leads with the Man, Not the Mission

Redesigned the Kevin Popke Foundation's website around the namesake's story and built a custom headless WordPress CMS on a $2,000 budget. Scores 98–100 on PageSpeed and allows the team to log new grants without a developer.

Open case study

The site buried the man it was named for

The Kevin Popke Foundation turns First Sergeant Kevin “50” Popke’s memory into grants for Florida veteran organizations. The old site had been built to check a box. It led with the organization and buried the man it was named for, and every update, down to a single grant announcement, needed a developer.

Constraints: six weeks and a $2,000 fixed budget, for a site that told Kevin’s story and that the foundation could run themselves.

Five decisions behind the site

1. Person before organization

I studied memorial foundations that do this well, like the Murph and Tillman foundations, and they all follow the same order: who the person was, why it matters, and how donors or volunteers can help. That set the homepage structure: Kevin’s story first, then the foundation’s purpose, then programs and donations. The donate button moves further down the page, because a visitor who knows about Kevin has more reason to give.

2. Three concepts, one set of copy

I presented three visual concepts using the same copy and largely the same media, so the family was comparing design and nothing else. They chose the “modern community vibe,” which balances professionalism with heritage by incorporating the family tartan.

3. Featuring the marquee event

Most of the foundation’s donations come from one annual event, Songwriters 4 Vets. The Events page opens with it, followed by a partnership and fundraising inquiry, and only then the general events list. At the client’s request, smaller events get less prominence, so the page is organized around where most of their funding comes from.

4. Headless on a nonprofit budget

A headless build (WordPress → WPGraphQL → Faust.js) delivers speed, but it breaks many standard WordPress plugins, and the budget didn’t cover premium licenses. So I built two things: a trimmed, reorganized WordPress admin, and kpf-core, a single plugin that handles SEO, forms, image optimization, snippets, and back-end accessibility tooling, replacing up to 11 separate plugins. Both sit on top of WordPress, so the core stays untouched and still receives security updates.

5. A CMS shaped like the page

Every kpf-core field maps directly to a spot on the page: plain-text headings, paragraphs, and buttons, with nothing to style. Logging a new grant takes as little as one photo from the check presentation. The grantee, date, and amount go into three fields, the recipient’s logo gets uploaded, and the live donation total on the About page updates itself.

Results

98 / 100 / 100 / 100 +24% $2,000
PageSpeed on desktop (95 on mobile) Over target for Songwriters 4 Vets, a week after launch Fixed fee, in six weeks
Measure Result Source
PageSpeed, desktop 98 / 100 / 100 / 100 PageSpeed Insights, Oct 16, 2026
PageSpeed, mobile 95 / 100 / 100 / 100 PageSpeed Insights, Oct 16, 2026
GTmetrix Grade A (98% performance) GTmetrix, Aug 27, 2026
Budget $2,000 Fixed fee

Songwriters 4 Vets took place a week after launch and beat its fundraising target by 24%. A new website doesn’t raise money on its own, and I don’t claim it did. But the event had a proper home online while it was being promoted.

What shipped: six responsive templates (Home, About, Events, Contact, Blog archive, and Blog post), the custom WordPress build, kpf-core, and a CSS manifest that maps every Figma component to its classes, with tokens layered primitive → semantic → component.

Design System

LINEAR: The 15K Line Stylesheet That Became a Design System

An agency template with no theming, no dark mode, and over 1,000 spacing classes became a three-tier token system that works the same way in Figma and Webflow.

Open case study

15,209 lines of CSS, and no way to restyle it

LINEAR was VYNE Creative’s internal Webflow template, used as the base for a lot of client work, but it was extremely bad at that job because it was never intended for that purpose. In practice, it was one exported stylesheet of 15,209 lines with no theming and no upward scaling for larger screens. It carried 1,990 classes and variables, and more than 1,000 of them existed just for spacing.

For the system, the team wanted dark mode, embedded icons that are easy to reconfigure, and a new ultrawide breakpoint. It also had to map cleanly from Figma to Webflow, so the team could build in either without me.

Five decisions that turned it into a system

1. Delete, don’t translate

My first move was mapping every v1 class to a v2 equivalent. A few hours in, it was obvious that a 1:1 map just preserves the mess with new names. I ran a duplication audit, dropped the translation approach, and rebuilt from what the pages actually used. The first pass came in under 300 classes while covering over 90% of real usage.

2. Components read semantic tokens only

The token system has three tiers: primitives hold raw values, semantic tokens are named by role (like --radius-card and --color-surface-canvas), and components only ever read the semantic tier. That rule is what makes the theming work. Switch the radius mode, and every corner in the project changes at once. Across five axes (radius, icon stroke, stroke caps, shadow, and light/dark), that adds up to 360 combinations, or “skins,” for one set of components.

3. Naming for Figma and Webflow

Standard BEM naming clashes with Webflow’s base-class-plus-combo-class model. I switched to a hybrid convention (card_body, container is-default, u-hidden@tablet) where every Figma layer name matches its Webflow class exactly. After pruning, I added 543 classes and combos in Webflow so every component in Figma had a working counterpart. The cost: it isn’t pure BEM or pure Client-First, so new team members have one more convention to learn. In return, design and build never drift apart.

4. Semantics built into components

Each Webflow component carries its own semantics and ARIA out of the box. Switches are announced as switches, field errors are live regions, and decorative icons are hidden from screen readers. That structure serves two audiences: it’s what screen readers rely on, and it’s what AI agents use to understand a page, which is the core of my Machine Experience (MX) framework. On the color side, contrast fixes moved the system from 69 of 86 token pairings passing WCAG 2.2 AA to all 86, so pages built from LINEAR start accessible and machine-readable.

5. Icons drawn with strokes, not shapes

Early on, I went looking for a diverse icon set that used strokes instead of filled shapes. Lucide worked extremely well for the project, because the VYNE team can adjust the stroke and end-cap tokens instead of re-exporting every icon each time.

Results

266 tokens 360 skins 86 of 86
In three tiers, down from 1,990 classes and variables Across five theme axes, from one set of components Color pairings meeting WCAG 2.2 AA
Measure Before: Template (1.0) After: Design system (2.0)
Classes and variables 1,990 in one stylesheet 266 tokens in 3 tiers
Reusable components – 75+
Component variants (icons excluded) – 930+
Button variants 693 216
Theme axes – 5 (360 combinations)
Color pairings meeting WCAG 2.2 AA 69 of 86 86 of 86
Project ramp-up Long and complicated Considerably faster (reported)

Takeaways

The biggest win was ruthlessly cutting duplicates and giving every token one clear job. Next, the library expands past marketing and dashboard UI into ecommerce and more complex CMS patterns, following the 16 templates and 20 patterns I’ve already scoped.

Client Website

A Little Transparency for SAD Trials Cut Abandonment from 65% to 37%

Four past campaigns hid trial locations until after the medical screener. Moving them up front changed how many finished.

Open case study

Health questions before a single location

A Fortune 100 company’s clinical research team was losing most of its trial candidates partway through the pre-screener. Across four previous campaigns, abandonment averaged 65%, even with targeted, high-intent traffic. In every one of those campaigns, people couldn’t see where the trial sites were until they’d finished a medical screener. That meant answering sensitive health questions before knowing whether taking part was even realistic.

Constraint: six weeks to fall enrollment.

Three decisions behind the new flow

1. Show them where, up front

Reviewing the prior campaigns’ data, my theory was that people won’t hand over health information, or even spend the time, if they’re not sure a test site is within reach. I inverted the standard industry flow by putting a location directory first, so people could confirm the study was geographically feasible before facing the medical screener. It was a low-risk bet: if I was wrong, switching back to the old flow would take minimal changes.

2. Cities, not contact information

Operations pushed back hard at first. In the past, publishing facility details had turned test sites into makeshift support desks, with phones ringing all day from people who hadn’t even been screened. My recommendation was a directory of cities with active sites, keeping every facility unnamed until the final consent step. Users got the one thing they needed to decide, and the sites didn’t get the calls. Test sites reported no increase in premature contacts.

3. Three steps in plain language

I streamlined the flow into three steps (city directory → branching screener → consent and facility match), replaced clinical jargon with everyday labels, and added plain-language privacy notes like “We don’t store your information until you consent.” The branching screener changes which questions it asks based on earlier answers. I built the flow and brought in an engineer to pair with me on the clinical screener logic; with health data and a client this size, a second set of eyes felt like the right move.

Results

65% → 37% 35.3% 2 more studies
Screener abandonment End-to-end conversion, up from ~13.3% Have used the flow as their template
Metric Before: avg of 4 prior campaigns After: first 30 days (1,086 sessions) Change
Bounce rate 62% 44% −18 pts
Screener starts 38% of sessions 56% (608) +18 pts
Screener abandonment 65% 37% (225) −28 pts
Screener completion 35% of starts 63% (383) +28 pts
End-to-end conversion ~13.3% of sessions 35.3% (383 / 1,086) +22 pts
Average time on task (screener) 4:20 2:49 −1:31

Sources: Google Analytics, Mixpanel, form telemetry.

At its peak, the study ran across 94 facilities nationwide, and about a dozen hit their enrollment quotas early. The client has since used the flow as the template for two more studies.

Takeaways

  • The order was the problem. Following an industry standard to the letter wouldn’t have fixed this.
  • Find the minimum that answers the user’s question. When operations is worried about exposure, look for the least you can show: here, cities instead of contacts.
  • Make the case airtight. These results compare against past campaigns, not a controlled test, so with more time I’d A/B test where the location step sits.

Client Website • Design + Development

From Phone-Only to 8–19 Web Requests Daily

A website for a commercial truck repair shop on Chicago's South Side. Brought in 8–19 additional estimate requests a day with 37.3% of them becoming paid service orders.

Open project

A $14,000 average order, and no website

312 Truck Body Repair & Painting on Chicago’s South Side had new owners, a $14,000 average service order, and no website. Every quote happened by phone or walk-in, leaving the shop invisible to fleet managers looking for vendors online. I had six weeks to change that and bring in new estimate requests the shop’s marketing team could convert into service orders.

Four decisions behind the build

1. Design for the task, not the average

Mobile-first is the default, but what matters is what people come to the site to do. These visitors came to request an estimate on a commercial truck: VIN, make, model, year, fleet size, damage photos. I designed the site to be responsive, with the media galleries, service details, and estimate form flexing down to mobile portrait.

2. Proof before the pitch

Nobody approves a $14,000 repair from a paragraph of copy. Before-and-after galleries and a facility tour sit above the service copy. Heavy media and fast pages pull against each other, but the site held a 2.3-second load time through its first two months.

3. A complex form that’s easy to finish

A shop can’t quote a truck repair without the vehicle type, its age, whether it’s part of a fleet, and the damage. I worked closely with the client on a form with conditional logic, so each person only sees the fields that apply to their earlier answers, plus file uploads and fields for VIN, make, model, year, and fleet size. Over the first 60 days, 59% of people who started the form submitted it, against the 35% floor I’d set.

4. One lead, two teams

Every request lands in HubSpot as a lead and goes to two places: the service department, to build the estimate, and marketing, where the lead joins an email sequence with a first-timer discount. The shop quotes and nurtures in parallel, so a fleet manager comparing three vendors hears back from both teams, not just one.

What didn’t work

I first set up the CMS almost like a storefront, with services, service categories, specialties, and certifications, all cross-linked. That was a lot of IA for a catalog nobody needed: fleet managers aren’t browsing collections of sub-services between meetings. I cut the structure back to the main services and service categories and let the estimate form do the work.

Results

At launch, the client’s marketing team started paid ads targeting the South Side and sent social traffic to the site. By month two, the site brought in 8–19 additional estimate requests a day on top of phone and walk-in quotes.

+8–19 requests a day 59% form completion 37.3% close rate
On top of phone and walk-in quotes, by month two Of people who started the estimate form (35% floor) Of requests became paid service orders

Measured in HubSpot over the first 60 days. The site is still live, and about 60–70% of it is unchanged from my build.

Takeaways

The agency moved me to a new project at day 60, so the numbers stop there. Next time, I’d build the client a HubSpot dashboard before handing off (requests, close rate, and lead source, split by channel) so they could see which ads were actually paying off. I’d also add device tracking from launch, so the desktop-first call rests on their own traffic, not an industry assumption.

Client Brand • Website Design

A Brand and Website for a $100M Portfolio in 8 Weeks

A holding company with 40+ businesses had no logo, no brand, and no website with an investor conference coming up fast. Launched in 8 weeks on a $7.5K budget.

Open case study

40+ businesses, and no brand at all

Vedara Ventures holds more than 40 businesses across commercial automotive, hospitality, retail, and real estate. At that scale, they had no logo, no brand guidelines, and no website, and Q3 investor conferences were weeks away. I had eight weeks to build both the identity and the site.

Constraints: 8 weeks and a $7.5K budget.

Four decisions that made 8 weeks enough

1. Brand first, then web

Every web decision derives from a brand decision, which gets messy when none have been made yet. I gave the brand the first two weeks and the site the remaining six, and it paid off: with the visual system locked, the site sprint never stalled on “what color is this button?” The investor deadline helped too. The client approved the brand in 5 days because they had a date to hit.

2. One mark for five industries

The identity had to look at home on a commercial truck lot and a boutique hotel’s website. I designed a nested-V monogram with an architectural feel, so it reads as structure and stability rather than any single industry. The palette landed on plum and dusty khaki, but only after one wrong turn (see below).

3. A site that expands without a developer

Vedara would keep acquiring businesses, so they needed a site they could maintain quickly and easily. At the client’s request, I built a custom back end on WordPress, with Bricks Builder for page templates and Advanced Custom Fields. A headless build would have been faster but harder for a non-technical team to run. Their first two additions took 3–5 minutes each, with no training.

4. Speed as a credibility signal

Investors judge an operator by details, and a slow site is a detail. I lazy-loaded compressed images, inlined critical CSS, and loaded each page’s scripts only where they were needed. At launch, the site loaded in 1.9s in GTmetrix and scored 94 for performance and 99 for accessibility in Lighthouse.

What didn’t work

My first palette used navy and off-white, but a holding company spanning hotels and truck dealerships needed warmth as well as trust. After some discussion with the client, we settled on plum and dusty khaki.

Results

What shipped: a complete identity (nested-V logo suite, five-color palette, brand book) and a filterable portfolio website, on time and on budget.

1.9s load time 12 of 12 testers 3–5 minutes
GTmetrix at launch Found and filtered a business To add a new company, no training
Measure Result Source
Find / filter a business 12 of 12 testers Remote usability test (Hotjar, n=12)
Correct first click in navigation 10 of 12 Same test
Used industry filters before being asked 67% (8 of 12) Same test
Page load time 1.9s GTmetrix at launch
Lighthouse 94 performance, 99 accessibility Lighthouse (lab)
Adding a new company 3–5 minutes, no training Client, first two additions

Takeaways

A real deadline cuts the debating, but it doesn’t have to cut the process. The investor conferences turned what could have been endless taste debates into one question: “Is this ready for investors?” I’d sequence brand before web again on any project that needs both.

Mobile App

A Community-Shaped Companion App for People in Recovery

A nonprofit wanted a digital companion for people in recovery. Testing showed that scoring someone's sobriety felt like a report card, so the app changed course.

Open project

Support, not surveillance

Never Alone Recovery supports people living with mental health conditions and substance use disorders. They wanted an app where people could find nearby support meetings, track their recovery, and journal, with room to add sponsor linking and 24/7 chat later. The hard part wasn’t the features. It was making daily check-ins feel like support, not surveillance, especially for people already getting more than enough of the latter.

Three decisions behind it

1. Status, not scores

The original idea behind the Sobriety Tracker was to distill someone’s risk of relapse into a numerical score. In pilot interviews, journals, and surveys, people said it felt like being kicked when they’re down. I replaced the score with three status words: Stable, Cautious, and At Risk. The trade-off was precision: a word can’t show small day-to-day changes the way a number can.

2. Progress people can feel

“90 days sober” is an abstract milestone. “You’ve saved $___ on alcohol since March” is something tangible. The app pairs each person’s milestones with self-reported data (or national spending averages by default) to estimate concrete wins.

3. A meeting finder by location

A GPS-powered meeting finder shows nearby support groups, because the easiest meeting to get to is the one most likely to be attended. Phase 2 was planned around a pitch to state and local governments: a way to digitally document court-ordered meeting attendance. Location data tied to recovery is about as sensitive as data gets, and that feature would have needed careful consent and data limits. In the end, the funding never came through, and interested partners moved on before Phase 1 reached soft launch.

What didn’t work

Between the pilot feedback and one-to-one usability sessions with NAR’s community volunteers, the same thing kept happening: people scrolled up and down, unsure where to go next. My fix was a persistent dock at the bottom with one-tap access to the three core features (Sobriety Tracker, Meeting Finder, and Achievements) plus the dashboard. In testing after the change, more than 77% of first clicks from the dashboard went to one of the three other dock tabs.

Results

46% at day 120 77%+ “Gentle”
Of a 35-person pilot, with no incentives offered Of first clicks from the dashboard went to a core feature How NAR’s long-term community members described it

Pilot participants came through the nonprofit, so this isn’t app-store retention, but four months is a long time for anyone to keep opening a recovery app that isn’t working for them. The app launched on both Android and iOS, but development was paused shortly after when the nonprofit’s subsidy funding changed.

Takeaways

I now test navigation much earlier in the process. People scrolling around unsure where to go is a problem a five-person test would have caught months sooner.

Web Application • Solo Design + Development

Building a Searchable Archive for Hundreds of LinkedIn Posts

A content archive for my LinkedIn posts that helped me to reshape my content strategy. Automation wired but off on purpose.

Open project

Hundreds of posts, and no memory of them

Since late 2024, I’ve posted on LinkedIn every single day. But once I posted something, it almost always evaporated from my mind, given the sheer volume of topics I was covering. I couldn’t answer basic questions: Have I already written about this? Which topics actually travel? What did I pin under that carousel?

Scheduling tools are built for posting, not for archiving. I wanted an archive I could search and analyze.

Three decisions behind it

1. Library and data before scheduling

LinkedWin’s first job is looking back, not posting forward. Import scripts pull content, including links to individual posts, from LinkedIn’s analytics exports and Favikon’s CSVs into one record, tagged by topic and hashtag and refreshed every four hours.

2. A composer built around my habits

LinkedIn’s own composer is built for everyone. Mine is built for how I actually write. It has a palette of the special characters I use, saved footer templates, @mentions, and a staging area for the pinned first comment that goes out with almost every post. The pinned comment used to live in a notes app and get pasted in after publishing. Now it gets drafted alongside the post.

3. Built, but not wired, for automation

I wired the app to schedule and even publish posts through a third-party scheduling API, but I haven’t switched it on, for a simple reason: my LinkedIn account is a professional asset, and automated activity is one of the fastest ways to get an account restricted or banned. Since I can write and schedule right in LinkedWin, publishing by hand costs seconds of my day. Losing the account would cost me my audience.

Results

With 557 deduplicated posts in one place, I could finally audit my own feed, and the audit changed what I post. I identified three topic lanes that performed well for me and started optimizing for saves and dwell time instead of reactions.

557 posts 3 topic lanes Every 4 hours
Deduplicated into one searchable archive Found in the audit, and now the core of what I post The archive refreshes from my exports

Next steps

I’d like to run the publishing pipeline on a sandbox account, so I can test it before it gets anywhere near my real one.

Web Application

ClienTell: From Client Profile to Creative Brief to Signed Contract

A secure, PIN-protected web app built for my consulting business that lets clients seamlessly complete creative briefs, review modular scopes of work, and sign contracts directly in the browser.

Open project

One client, five tools, and a game of telephone

Every new client used to mean an intake form in one tool, follow-up questions over email, and a contract built by hand. I was retyping answers clients had already given me into contracts they then had to sign somewhere else. It was a mini-game of telephone where it’s easy to lose a detail here and there, and that inevitably came back to bite me. And if a client came back for a second project, I was basically starting from scratch.

Five decisions behind it

1. A PIN instead of an account

Clients typically use the portal only a few times per project, so asking them to create an account and invent a password felt like unnecessary friction. Each client gets an email invite to set a 6-digit PIN, and the pair, email and PIN, becomes their login. PINs are hashed with PBKDF2, so nobody, including me, can read them, and sessions use signed cookies.

A 6-digit PIN has a large but finite number of combinations, so attempts are limited. Three wrong tries trigger a 10-minute cooldown. Three more within 24 hours of that cooldown ending lock the account for a full day, or until the client contacts me to unlock it. A forgot-PIN flow covers the usual case, so a lost PIN is a self-serve reset, not an email to me.

2. Autosave is the client’s friend

Some brief questions ask for detailed answers, and nothing makes someone abandon a form faster than losing a paragraph to an accidental refresh. But people don’t trust what they can’t see, so a visible indicator counts down five seconds to each save.

3. Briefs feed contract drafts

ClienTell started as a simple brief builder; contracts came second, built on the same client profiles. As a client completes their brief, specific answers flow into a pending Design Services Agreement, Statement of Work, and optional confidentiality addendum. I still review and edit every contract before it goes out, because legal documents shouldn’t be fully automated. But I start from a draft that already knows the client’s scope, not a blank template.

4. Prewired for returning clients

Good clients come back. Each client profile holds as many briefs and contracts as they have projects, so a returning client starts from everything I already know about them, not a blank intake.

5. Client information kept safe

Migrations are additive-only, and the destructive db:push command is blocked by default. Cleaning up the schema takes more steps that way, which is a fair price for never wiping a client’s answers by accident.

Results

7 clients 1 place, not 5 0 passwords
Onboarded through ClienTell so far For intake, scope, and agreement Clients sign in with their email and a PIN

ClienTell has made quick work of onboarding so far, and it’s in active use with real clients.

Web Application • Solo Design + Development

Contour: Mapping the Shape of a Designer's Skills

A self-assessment tool for designers that charts their skills on a bar chart and assigns the appropriate shape with corresponding insights. Designed and launched in 3 weeks.

Open project

Not every designer is T-shaped

“T-shaped” became the default way to describe a designer’s skills: deep in one thing, broad across the rest. But plenty of careers don’t look like that. Some people go deep in two or three areas, and some connect disciplines more than they specialize. In fact, there are a number of different designer “shapes.”

Two decisions behind it

1. Honesty is the policy

Give people free sliders and most skills land at 8 or above. That’s a ceiling effect, and it turns every result into the same flat blob. Only one skill can score a 10, one a 9, and one an 8. Everything from 7 down is unrestricted. You can’t claim to be world-class at everything if you want to truly understand your shape. It was a tricky (and perhaps controversial) rule, but I saw it as the clearest way to make sure the final charted shape means something.

2. Nothing leaves the browser

People rate themselves differently when they think someone’s watching. All scoring and storage happen in the user’s browser. Contour logs no usage and has no back end storing results. The trade-off: no cross-device sync, and with only basic analytics, I can’t tell you how many people have used it.

How Contour reads a shape

Contour reads your ratings as a profile and looks at three things: how many peaks there are, how far the ratings spread, and where they flatten out. One deep peak with little around it is an I. One peak on a broad base is a T. Two peaks on a broad base make a Pi, and three or more make an M. An X pairs deep expertise with enough competency to lead in multiple other disciplines.

Built accessible from day one. Automated Playwright and axe checks run clean for keyboard and screen-reader support. Tooltips open on focus and tap, not just hover, and every animation respects prefers-reduced-motion. A manual VoiceOver pass is next: automated checks catch a lot, but not everything.

Results

~3 weeks 5 shapes 0 data stored
Shipped solo, from concept to live I, T, Pi, M, or X, with a growth guide Every rating stays in the user’s browser

Tool available here. It maps designers to I, T, Pi, M, or X shapes, with a growth guide and chart exports as SVG, PNG, and JPEG. Nothing leaves the user’s browser, so I don’t have usage numbers, on purpose.

Next steps

I’d love to expand Contour with other ways to visualize skills, like the Dreyfus model, radar (“spider”) charts, and treemap diagrams.