Ethanium Design Direction

Intent

Ethanium should feel calm, capable, and unusually clear. It helps teams make complex business work easier to understand, so the interface should never add noise, decoration, or uncertainty.

This is an original design system for Ethanium. It takes inspiration from three complementary points of view:

• Apple Human Interface Guidelines: purposeful simplicity, clear hierarchy, familiar patterns, direct language, and carefully considered details.
• Katie Dill’s product-design leadership at Stripe: meticulous craft, reviewing real user journeys instead of abstractions, and treating quality as a shared responsibility across design, product, and engineering.
• Taste Skill (anti-slop frontend rules): a catalogue of the patterns that make a site look templated or machine-generated, and a mechanical pre-flight check that catches them before publishing.

The result is not an imitation of any of them. Apple supplies the restraint and usability standard. Katie Dill’s quality practice raises the bar for the details that earn trust. Taste Skill names the specific clichés to keep out. This does not mean copying Stripe’s visual identity. For a B2B software studio, clarity always wins when tradeoffs are required.

Design read

Every page, section, or redesign starts from one line stating what we are building. For the site as a whole:

Reading this as: a B2B custom-software studio site for operations leads and business owners, with a calm, trust-first language, leaning toward native HTML and CSS, the system font stack, and restrained motion.

If a new page reads differently (for example, a long-form case study or a campaign landing page), write its own design read before building it, and adjust the dials below on purpose rather than by drift.

Dials

Taste Skill describes layout, motion, and density as three 1-10 dials. Ethanium sits deliberately low on all three:

Blog and editorial pages use the same values. Raising a dial requires a written reason in the change description. Never raise one just because a pattern looks impressive.

Brand qualities

Core principles

1. Start with the job to be done. Each page should make its purpose, primary action, and next step obvious without explanation.
2. Create hierarchy before adding style. Use grouping, alignment, scale, whitespace, and contrast to establish reading order. Decoration is never a substitute for structure.
3. Make complexity legible. Break workflows into meaningful stages and use plain labels. Show enough context for a person to move work forward.
4. Use craft to build trust. Spacing, copy, image crops, focus states, and responsive behavior are part of the product, not polish for later. Hold details to the same standard as the main feature.
5. Review journeys, not isolated parts. Walk a meaningful path as a visitor would: arrive, understand the offer, assess the work, and make contact. Fix the friction in that flow before adding a new component.
6. Give the work room to speak. Portfolio screenshots and case studies are evidence. Present them cleanly, with concise context rather than competing visual effects.
7. Reach past the defaults. If a pattern is what any generated landing page would do (eyebrow above every heading, three equal feature cards, centered hero over a gradient), assume it is wrong for us until it earns its place.

Foundations

Stack

The site is Jekyll with hand-written HTML, one stylesheet (assets/css/site.css), and one small script (assets/js/site.js). Keep it that way. Taste Skill’s React, Tailwind, Motion, and GSAP guidance does not apply here. Translate its intent into plain CSS instead:

• Use CSS Grid for multi-column layouts, not flexbox percentage math.
• Use min-height: 100dvh rather than 100vh for any full-height block.
• Use IntersectionObserver or CSS for scroll-linked effects. Never attach a scroll event listener.
• Do not add a dependency, framework, or icon library without a design reason that this document can record.

Color

The palette is intentionally narrow and content-first. Use blue only for interactive elements (links, buttons, focus). Never use it to highlight non-interactive text: visitors read blue as “clickable” (Jakob’s Law), and keeping it rare is what makes the primary action stand out (Von Restorff Effect).

Rules:

• One accent, locked. Blue (--coral) is the only accent on every page. A section never introduces its own color for a badge, status, or button.
• One gray family. The grays above are cool neutrals. Do not mix in warm grays, cream, or beige.
• No gradients, glows, gradient text, decorative color fields, or a second accent without a specific communication purpose.
• Never use pure black (#000) for text. #fff is used as the page background on purpose, in the Apple manner; do not use it for text on light surfaces.
• Never use color as the sole means of communicating status or meaning.
• Theme: the site is light-only by deliberate choice. Sections never invert to a dark band mid-page. If dark mode is added later, it is added for the whole site at once, through the same tokens under @media (prefers-color-scheme: dark), and every page is checked in both modes.

Contrast must meet WCAG 2.2 AA: at least 4.5:1 for body and small text, and 3:1 for large text (24px+, or 19px+ semibold), icons, control borders, and focus rings. --muted passes on both --paper and --white, but only just, so don’t place it on anything darker or use it for essential information.

Typography

Use the platform system stack for both headings and body copy:

-apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif

This keeps the site fast, familiar, and highly legible. Headings are semibold, not extra-bold, and use tight line-height (1.08-1.2). Body copy is regular weight with comfortable line-height (1.45-1.75). Keep prose concise and prefer sentence case.

Limit reading lines to about 45-75 characters (max-width: 68ch or roughly 680px at 17px). Longer lines make the eye lose its place and add cognitive load.

Recommended hierarchy:

Text must stay readable and usable when zoomed to 200% (WCAG 1.4.4).

Type rules:

• No webfonts, no serif. A serif display face is the most common sign of a generated “premium” site. Ethanium stays on the system sans.
• Emphasis stays in the same family. Highlight a phrase with weight or color (as the hero’s <span> does), never by switching to another typeface.
• Control hierarchy with weight and color before reaching for raw size. An H1 that needs four lines is a font-size error, not a copy error.

Shape

One radius system, applied everywhere:

Do not introduce square buttons, 8px cards, or a new radius without updating this table.

Space and layout

The frame follows apple.com’s measurements and breakpoints, set as tokens on :root (--content-width, --gutter, --section-pad):

Blog and article pages use a 692px reading column at every size above mobile, and prose inside it follows the line-length limit above. Change the tokens, not individual sections, when the rhythm needs adjusting. Layouts must reflow at 320px wide with no horizontal scrolling (WCAG 1.4.10).

No borders or divider lines. Like Apple, separate content with whitespace and with alternating section backgrounds (--paper and --white), never with hairlines. Adjacent sections must not share a background; when a section is added or removed, re-alternate the sequence. Media tiles sit on the opposite surface to their section (white tiles on a gray section) with the 16px radius instead of an outline.

Group related things so the structure is visible at a glance (Gestalt principles):

• Proximity: items that belong together sit closer to each other than to anything else. Space between groups must be clearly larger than space inside them.
• Similarity: items that do the same job look the same. Anything that looks different should behave differently.
• Common region: use the opposite surface (--paper on --white, or the reverse) when spacing alone doesn’t make a group clear enough. Never a rule.

The current system uses four columns for process steps (two below 1068px, one below 360px), two columns for case studies, and a single-column reading flow for articles. Collapse grids before their content becomes cramped, and write the narrow-screen fallback for every multi-column block in the same change, not later. Keep sections to a handful of chunks: people hold only a few items in working memory (Miller’s Law).

Layout rules borrowed from Taste Skill:

• No two sections share a layout family. The process section, the portfolio grid, the foundation section, and the contact block should each look structurally different.
• No zigzag runs. At most two consecutive image-and-text splits.
• No three equal feature cards in a row. Use a list, a two-column split, or an asymmetric grid instead.
• No split section headers (big headline on the left, small floating paragraph on the right) unless the right column holds something real. Stack heading and body instead.
• Exact cell counts. A grid has exactly as many cells as there is content. Never pad with a blank or filler tile.
• Long lists change shape. More than five items become grouped columns or a card grid, not a long list with a line under every row.

Components and behavior

Navigation

The header mirrors Apple’s global nav: 44px tall, sticky, a translucent rgb(250 250 252 / 80%) background with saturate(180%) blur(20px), and no bottom border. Its content spans up to 980px with 22px side padding (16px on mobile) and does not narrow with the tablet content column. Links are 12px with -0.01em tracking, 8px horizontal padding, and a 44px tall hit area.

Limit primary navigation to the few destinations that matter, since every extra choice slows the decision (Hick’s Law). Labels should be familiar nouns or verbs (Approach, Portfolio, Contact), not marketing language. Follow conventions people already know: logo top-left linking home, navigation in the header, and Contact last, where the end of the list makes it easy to find and remember (Jakob’s Law, Serial Position Effect).

Footer

The footer mirrors Apple’s global footer: --white background, 12px text at line-height 1.33337 and -0.01em tracking in --muted, 17px top and 21px bottom padding, the same content width as the page, and no top border.

Hero

The hero is one moment, not a feature list. It must fit in the first viewport at desktop with the primary action visible without scrolling.

• At most four text elements: an optional kicker, the headline (two lines max), supporting text (20 words max), and actions (one primary, one optional secondary link).
• No trust strips, client logos, pricing hints, or taglines under the buttons. Those belong in their own section below the hero.
• Top padding stays modest (around 96px max at desktop). If the hero feels empty, grow the type or the image, not the padding.
• A hero needs a real visual: actual product screenshots or photography, never a gradient blob or a mock UI built from <div> boxes.

Kickers

A kicker is the small label above a heading (.eyebrow, .section-kicker). Generated sites put one above every section, which produces a templated rhythm.

• At most one kicker per three sections. The hero counts as one.
• If a section has a kicker, the next two do not.
• A kicker names the topic in plain words. No numbering (01 /, 002 ·), no version stamps (BETA, v2), no poetic labels (“Field notes”, “On the bench”).
• When in doubt, delete it. The heading alone is enough.

Buttons and links

Use one visual primary action per area. Primary buttons are blue, fully rounded, at least 44px high, the touch-target size recommended by Apple’s HIG (larger, closer targets are faster to hit, per Fitts’s Law), and their label fits on one line at desktop (three words or fewer is ideal). Every other clickable target, including text links in dense lists and close buttons, must be at least 24x24px or have equivalent spacing around it (WCAG 2.5.8). Secondary actions remain text links. Link labels should explain the destination or outcome; avoid generic labels such as “Click here” or “Learn more.”

One label per intent. Every action that leads to contacting Ethanium uses the same label across the page and the site (header, hero, sections, footer). The same applies to “see the work” actions. Two different labels for the same intent read as indecision.

Button text must pass WCAG AA contrast (4.5:1) against the button, and a pressed state may use a subtle transform: scale(0.98).

All keyboard-focusable controls must retain the visible blue focus ring:

outline: 2px solid var(--coral);
outline-offset: 4px;

A focused element must never be hidden behind a sticky header, a modal, or other overlapping content (WCAG 2.4.11). The header is sticky, so html keeps a matching scroll-padding-top: 44px.

Forms and feedback

Ask only for what’s needed to start a conversation; every extra field costs completions. Accept input in whatever format people naturally type it (Postel’s Law), for example phone numbers with or without spaces or dashes. Use visible labels (never placeholder-only), correct type and autocomplete attributes, and error messages that say what went wrong and how to fix it, placed next to the field. Confirm success clearly: the moment after someone makes contact is the end of their journey, and people remember endings strongly (Peak-End Rule).

Sections and cards

Sections should have one clear subject: a kicker is optional (and rationed), a heading is required, and supporting copy earns its place. Default content shape: a heading of about eight words or fewer, a paragraph of about 25 words or fewer, then one visual or one action.

Prefer open layouts and spacing-led groupings over boxed cards. If a card is needed, reserve it for a distinct object or action, not a way to fill empty space. When a whole card is clickable, make the entire card the target, not only its title. Shadows are rare; when one is used it is soft and low-opacity, never a hard black drop shadow.

Curate rather than list everything: a few strong case studies persuade more than many average ones, because too many options discourage people from choosing any (Choice Overload).

Images and portfolio work

Screenshots are displayed on the soft neutral surface with object-fit: contain so they are not cropped into ambiguous fragments. Use accurate, descriptive alt text. Allow only subtle hover feedback (scale(1.01)), never dramatic zooms, parallax, or autoplaying media.

• Use real screenshots of real work. Never stock placeholders, never fake dashboards assembled from styled <div>s.
• No labels, pills, or tags laid over images, except the existing on-hover preview hint. Context goes in a caption below or beside the image.
• No decorative photo credits or pseudo-catalogue captions (“Plate 03”).
• No hand-drawn decorative SVG illustrations.

When new original photography or art direction is introduced, favor one confident image with a clear focal point over a collage. Treat every image, caption, and crop as part of the visitor’s decision-making journey, keeping the portfolio informative and professional.

Motion

Motion should orient, not entertain. Every animation must answer “what does this communicate?” with one of: hierarchy, sequence, feedback, or a change of state. “It looks nice” is not an answer.

• Interaction feedback (hover, press, open, close) takes 100-300ms; entrance animations take no more than about 700ms. Animate only transform and opacity.
• The homepage uses a single, small upward entrance. Do not add looping animation, marquees, parallax, scroll hijacking, custom cursors, or magnetic buttons.
• Never make content, navigation, or an essential control depend on animation. Content must be visible even if an animation never runs.
• Respect prefers-reduced-motion for all animations, transitions, and smooth scrolling.

Performance

Speed is part of usability. Respond to every interaction within 400ms (Doherty Threshold) and keep pages light: optimize and size images, lazy-load anything below the fold, and avoid blocking scripts. Store images in assets/images/ as JPEG (quality ~82, at most 1440px wide, ideally under 700KB); use PNG only when an image needs transparency. Reserve space for images so content doesn’t jump while the page loads (target CLS < 0.1, LCP < 2.5s).

Content voice

Write like an experienced partner explaining a practical decision.

• Lead with a real business outcome: “Organize project data in one place.”
• Use concrete language: “Map the work,” “Structure the data,” “Build the portal.”
• Prefer short sentences, active verbs, and specific nouns.
• Explain the benefit before the implementation detail.
• Do not overpromise with claims such as “revolutionary,” “seamless,” or “best-in-class.” The same goes for “elevate,” “unleash,” “next-gen,” and “game-changer.”
• Write for skimmers. Most visitors scan before they read (Paradox of the Active User), so put the key point in the heading and the first sentence.
• Persuade honestly. Use real client outcomes as social proof; never use dark patterns such as fake urgency, guilt-trip wording, or hidden steps.
• No em dashes or en dashes in visible copy, including headings, buttons, alt text, and captions. Use a period, comma, colon, or parentheses. Ranges use a plain hyphen (2024-2026).
• Ration the middle dot. At most one · in a line of metadata; never use it as the default separator for lists of words.
• No scroll cues (“Scroll to explore”), weather, local-time, or decorative location strips. A single address or location in the footer or contact block is fine.
• No invented numbers. Every figure must come from a real project or be clearly marked as an example.
• Quotes are three lines or fewer, attributed with a name and role.

Accessibility and quality bar

Every addition must work with keyboard navigation, have a visible focus state, and remain understandable without color, motion, or images. Use semantic HTML first; provide meaningful alt text; preserve a logical heading order; and test at narrow widths as well as desktop.

Pre-flight check

Run this before publishing any page or material change. If one box cannot be honestly ticked, the change is not done.

Purpose and structure

• The design read is stated, and the dials have not drifted upward.
• The primary purpose and action are obvious.
• The hero fits the first viewport: headline two lines or fewer, supporting text 20 words or fewer, action visible, no extra strips.
• Kicker count is at most one per three sections.
• No two sections share a layout family; no three-card rows; no zigzag runs; no split headers; no empty grid cells.
• Every multi-column block has an explicit narrow-screen layout and reflows at 320px without horizontal scrolling.

Visual system

• Blue is the only accent, used only for interactive elements, the same way on every section.
• One radius system, as listed under Shape.
• No borders or divider lines; adjacent sections alternate backgrounds.
• Light theme throughout, with no inverted sections.
• Images are real work; nothing is laid over them; no <div> mock UIs.

Actions and copy

• One primary action per area, label on one line, contrast at least 4.5:1.
• Every target is large enough (44px buttons, 24px minimum elsewhere).
• One label per intent across the page (contact, view work).
• Zero em dashes or en dashes in visible text; middle dots rationed.
• Every string re-read aloud: no broken grammar, no cute filler, no invented numbers, no banned buzzwords.

Behavior and access

• Every animation has a stated purpose and is disabled under reduced motion.
• Hover effects are also available on keyboard focus, or are unnecessary.
• Text meets AA contrast against its background at every width.
• The page still feels precise after removing anything nonessential.

Journey review

For a material page or interaction change, review the path a prospective client takes rather than judging the new element in isolation:

1. Start from the page entry point at desktop and mobile widths.
2. Confirm the visitor can identify Ethanium’s offer, review relevant work, and find the contact action without hunting.
3. Complete the same path with a keyboard and with reduced motion enabled.
4. Record any friction as a specific observation, then fix the highest-impact issue before pursuing visual refinement.

This is a small-site adaptation of Katie Dill’s quality-review approach: the experience must be useful and error-free first; the extra care should make it feel trustworthy and considered.

Reference inspiration

These references guide principles, not visual copying:

• Apple Human Interface Guidelines: Design principles
• Apple Human Interface Guidelines: Layout
• Katie Dill on product craft and quality at Stripe
• Katie Dill: Quality Control
• Laws of UX
• roadmap.sh: UX design
• Nielsen Norman Group: 10 usability heuristics
• WCAG 2.2
• Taste Skill: anti-slop frontend rules (the taste-skill and minimalist-skill variants)