Let's craft a compelling narrative from a Sketch UI component. We'll dissect its elements—colors, typography, dimensions—and translate them into a story for diverse audiences: visual, auditory, tactile. The goal? An engaging, easily understood, and memorable experience. Clarity and coherence are paramount.

My colleague, Katie, has selected a UI component. I'll annotate it (our primary tools are SCSS, Twig, and Craft, but the templating language isn't critical), and she'll provide feedback. Ideally, I'll get most details right, with a few errors to illustrate how information can be lost during handoff.

In white-label or framework front-end development, the priority is flexibility and adaptability. Content and style are kept largely agnostic (within product boundaries) because the code's ultimate destination and purpose are unknown. However, my recent transition to a web design agency has flipped this focus. Here, the emphasis is on bespoke, highly tailored designs deeply integrated with the client's specific needs and their target audience.

Collaborating closely with a graphic designer like Katie, working with meticulously crafted, pixel-perfect UI, rather than wireframes or initial narratives, is a learning curve. Yet, I bring valuable skills to the table: document design.

Document design—essentially the semantic web with accessibility at its core—involves treating graphic design as a communication system. We translate the underlying purpose of colors, typography, and layout into an accessible, linear, and navigable DOM. It's HTML, plain and simple. Yet, surprisingly, this fundamental principle often gets overlooked.

Katie provided a Sketch file brimming with artboards and clear design specifications. My analysis reveals six or seven components utilizing a similar card paradigm:

• A card presents metadata about a site page.
• It contains an image/media and metadata (a media object).
• It's displayed within a group of similar objects.
• This group is consistently typed (no mixing of search results, news articles, and classes).
• Each object has a single page link and no other actions.
• Each object includes a call to action (e.g., "Book").
• Optional elements: times, categories, badges.
• Required elements: media, title, link.

The card is the primary navigation element. Users traverse guided pathways, selecting from card sets based on top-level pages ("What's On," "Classes"). It's not interactive, but rather a guide, an index card leading users to their destination—in this case, purchasing a show ticket.

Consider this analogy: Describing a show flyer over the phone. You wouldn't recite the text verbatim, starting with irrelevant details. Nor would you just describe colors and fonts. You'd convey the essential information: "It's The Greatest Showman, Tuesday at 7:30 PM, Odeon on Oxford Street, near the tram." This is the essence of document design.

Count, Group, and Name

Let's structure each card within a list item. We need a countable group, which we'll introduce with a heading (<h3></h3>). This allows screen reader users to:

1. Identify the list in the headings overview.
2. See the item count upfront.
3. Navigate to the next list item/card.
4. Skip the group and proceed to the next page (pagination is the following labeled landmark).

=====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================

Anchor

Each card will be wrapped in an anchor element (<a></a>). This prioritizes the link, allowing users to click immediately upon identifying the relevant card. While a large clickable area is beneficial, it shouldn't become a usability trap. The card's generous gutter provides sufficient spacing to minimize accidental clicks.

Title

The show title will be a heading (<h3></h3>), reflecting its visual prominence. Users who quickly scan headings will easily locate this key information. The image will precede the heading; since image descriptions aren't available via the API, the alt attribute will be left empty.

Now for the metadata:

• Badge
• Date/Time
• Categories

Badge

The badge highlights venue-specific information. While its user benefit isn't immediately apparent, its visual emphasis warrants inclusion. To avoid it being missed during non-visual browsing, I'll place it directly after the title, either first or last for consistent accessibility. Instead of <abbr></abbr>, I'll use plain text since the brand color serves as a clear indicator of venue ownership.

<p>HAC Highlight </p>

The badging is organization-specific, clearly distinguishing in-house events from those hosted by external organizations.

Date/Time

Dates are crucial and will be placed in a <h4></h4> element, facilitating quick scanning for specific dates or times. The <time></time> element ensures proper date/time interpretation by assistive technologies.

Categories/Tags

Categories follow the badge and date, reflecting their visual de-prioritization. We avoid repetition by placing specific information before more general information. A simple tag precedes the category list for clarity. Hard-coded spacing prevents garbling even with text compression.

<p>Categories: {% for category in categories.all() %}{{category}}{% if not loop.last %} / {% endif %}{% endfor %}</p>

Color-coding of primary categories is handled in CSS, as it's a non-verbal cue not requiring verbal description. The primary category is placed first, but not explicitly labeled, as the pre-existing category filter provides a more efficient selection method.

Action

The call to action ("Book," "Learn More") is styled as a span, placed last to signal the card's end. This ensures that no data follows the action.

Conclusion

This markup prioritizes counting, grouping, and naming data, enabling both linear and non-linear interaction. The page is understandable when read sequentially or in parts, facilitating efficient navigation.

Katie's Feedback

Katie Parry, designer: Excellent article! The <time></time> element handling is particularly clever. However, assistive technology users receive information in a pre-determined order. Without filtering, finding specific events (e.g., dance events) requires navigating through title, badge, dates, and categories, which can be cumbersome. This isn't a coding error, but a limitation of the current web paradigm. Something to consider for future improvements.

My design process often begins with event cards, even before establishing site-wide typography. Visually, these cards should:

• Resemble a list for intuitive use.
• Provide sufficient information for user interest assessment (image, title, date, link).
• Include a clear call to action (link).
• Be easily scannable.

Visual scannability is achieved by consistent placement of information types and a clear visual hierarchy. Typography and spacing are key. Titles are highly prominent; dates are consistently styled but distinct from titles; categories have a different style. The spacing in the code sample needs adjustment for optimal scannability.

Users scan for different information. Some browse generally; others search for specific events or categories. Cards need to accommodate this diverse behavior. While conventions exist, card design varies across projects.

A balance must be struck between familiar interfaces and client-specific originality. Custom typefaces and color palettes contribute, but user discovery is crucial. I research clients and their audiences (review sites, social media) to uncover insights influencing design. Increased developer involvement in this discovery phase would be beneficial. Currently, I use extensive Sketch notes and sometimes spreadsheets to define functionality. A data populator would be ideal!

The above is the detailed content of Telling the Story of Graphic Design. For more information, please follow other related articles on the PHP Chinese website!