the client

2fifty Texas BBQ is a restaurant with two locations, one in Riverdale Park, MD and one in Washington, DC. Every week it sends a newsletter to almost 90,000 people, and that newsletter is one of its best sales channels.

This is a client case: a system we built for them and run inside their weekly work. The full write-up, with the method, the hours and the catch, is the fieldnote two days a week, now about two hours: a newsletter that writes from the website.

the problem

On a full week, putting one issue together took the designer up to two working days. The email is image-first: twelve to fourteen designed blocks, each exported as an image with its own position, file name, alt text, link and tracking tag, plus a subject, a preheader, a button and a footer. That's somewhere around 64 to 74 small fields per issue, every week, at the end of a long day of design.

Most of the newsletter's copy already lived on the restaurant's website. Someone had already written it, approved it and published it, and every week a person typed it again. The moving is also where the small things slip: a wrong link, a wrong date, an image no screen reader can describe. On a list this size, one wrong detail reaches a lot of people.

what we built

A custom skill the team shares. It is built around a block system we designed for 2fifty (a masthead, covers for each kind of issue, a specials menu card, day tiles, press, a review quote and more, each in a few colour themes) and around how this team already works. The pieces are designed once, by hand. Every issue snaps a set of them together and pours in that week's content.

the thanksgiving waitlist issue, top to bottom: masthead, thanksgiving cover, this week's specials, a saturday tile with its photo and price still in brackets, a sunday special, washington post press, nite bites from the smokehouse, a review quote, pair of the week, catering, order button and footer
fig. the first real issue, as the newsletter page builds it. a draft: [price] and [photo needed] are still in it, on purpose.

it starts from the brief, then reads the website

What the designer gathered from the client's brief goes in first: what to push, the context, when it should go out. Then the skill reads the specials, the seasonal page and the news on the restaurant's website and reuses the copy and the photos verbatim.

on the website · 2fiftybbq.com/news

the restaurant's blog post introducing nite bites: fries tossed in a steel bowl under the nite bites at the trailer logo

in the issue · from the smokehouse

the newsletter block: the same photo, the smokehouse byline and the title introducing 2fifty's nite bites, with a read the story bar
fig. the skill reads the post and reuses it: the photo, the title and the byline, word for word. nobody typed it twice.

one page to edit, one link for feedback

The skill publishes an editable newsletter page: reorder, hide or recolour blocks, edit every field, swap a photo, lock what's done. Then it builds a client preview with the email exactly as it will arrive. The client comments on any block, and round two updates the same link, so the comments stay where they were.

flow of one weekly issue: it starts from the client’s brief, then the client website (specials, seasonal page, news) is read, reusing copy and photos verbatim with brackets for gaps; the issue is composed on the block system; the newsletter page lets the designer reorder, hide, recolour, edit and lock blocks; the client preview shows the email as it will arrive with placeholders as questions, and comments loop back to the page as a change list after approval, on the same link each round. once approved, the export numbers the images in send order with alt text, metadata and tracking links; files go to the project folder and a shared drive with a build sheet; an upload helper lists every link, alt text and file with done ticks; the images are swapped into the email tool, still by hand. how the issue looks, the approval, the photos and the upload clicks stay with people
fig. the skill does the moving; the page, the preview and the approval stay with people. from the fieldnote.

everything ready to upload

The export gives numbered, search-friendly image files in send order, with alt text and metadata embedded, a tracking link per image and a build sheet, saved to the project folder and to a shared drive. An upload helper page puts every link, alt text and file at hand while the designer swaps the images into the email tool.

brackets, never invented

Anything the skill can't source from the website comes out as a placeholder in square brackets, like [price] or [event date]. It shows up in the run's report as something the website is missing, it looks wrong on purpose inside a designed block, and in the client preview it becomes a question.

decision flow for each field in a block, such as a price, a date, holiday hours or which location: does the website say it? if yes, the copy or photo is reused verbatim and goes into the issue. if no, the field becomes a bracket such as [price], never a guess, which looks wrong on purpose; it turns into a question in the client preview, the client’s answer goes into the change list, and it reaches the issue after approval. every bracket is also listed in the run’s report as missing on the website, probably what customers can’t find there either
fig. if the website doesn't say it, the issue gets a bracket, and the bracket becomes a question for the client. from the fieldnote.

the result

The first real issue went from the restaurant's website to a client preview in about 2.25 hours of person time, feedback round included. The designer's own estimate for an issue before was about 16 hours, so that is about 13.75 hours back per issue. Over about fifty weekly issues a year, that adds up to roughly 690 hours, about four months of a full-time designer's year. The before column is an estimate and the after column is one real issue, so all of it is an estimate for now.

paired bars of hours per weekly issue, before (the designer’s estimate) and after (measured on the first real issue): gather and copy from the website 2.5 plus 2 hours, now 0.25 to run the skill and read what is missing; build blocks in figma 5 hours, now 0.75 to review and edit in the newsletter page; export and name files 0.5, now 0.1; client preview and revisions 3, now 0.35 for one feedback round on one link; email tool upload, links and alt text 2.5, now 0.75 with the helper, still by hand; test send and fixes 0.5, now 0.05. per issue: 16 hours, about two working days, down to 2.25 hours, about 13.75 hours back
fig. hours per weekly issue, by step. before is the designer's estimate, after is the first real issue.

The hours are half of it. The small fields that get skipped when someone is tired now get done every time: real alt text for each image, file names that mean something, a distinct tracking link per image so the next issue can be planned on what people actually clicked, and a subject and preheader that get checked instead of typed at the last minute.

The designer still decides what the issue looks like, and the client still approves it. Nobody types a menu twice.

limits

  • The upload into the email tool is still by hand. The helper page makes it faster and harder to get wrong, and it is the biggest block of time left.
  • Photos still need a person. The skill reuses the photos already on the website; someone still has to shoot new ones, or pick them.
  • One issue isn't a trend. The first weeks of anything are the weeks you pay the most attention.
  • It only knows what the website knows. If something on the website is out of date, the newsletter starts out of date too, and a person still has to catch it in review.

read the fieldnote

How it was built, the step-by-step hours table and the yearly math are in the fieldnote.