Discord and Telegram visual assets: the day one kit

The community is the surface your most engaged audience stares at every day, and it is usually the one nobody designed. Here is the kit, and the order to build it in.

August 25, 2026 · 9 min read

The brand book gets signed off, the launch film gets approved, the site goes live. Then someone remembers the server. It gets set up in an afternoon by whoever is around, with the logo cropped into a square, role colours picked from a palette in a hurry, and a welcome graphic made at midnight by a moderator who was trying to help.

A week later that server holds the most attentive audience the project will ever have. They are in it every day. They screenshot it, they repost from it, they judge the project by it. And it looks like a different company from the one on the landing page.

The fix is not more design. It is deciding that the community surfaces are part of the identity, not an afterthought attached to it, and building the small set of assets that place actually needs before the doors open.

The server is the brand surface people spend the most time in

A feed post gets a second and a half. A launch film gets watched once. The server sits open in a tab all day, next to the other servers someone is in, and it is the only brand surface a person returns to on purpose several times a week.

It is also the surface with the most components. The icon in the sidebar, the banner above the channel list, the colour attached to every name in every message, the emotes people use instead of words, the pinned message someone reads before deciding to stay. Each one is small, none of them are hard, and together they decide whether the place reads as a project or as a group chat with a logo.

What each surface actually has to survive

These assets fail in ways feed graphics never do. They get shrunk to the height of a line of text, masked into circles, rendered on a dark background nobody tested, and shown next to content that is not yours. The spec is not a pixel size, it is a condition.

The last row is the one teams find hardest to believe. The preview image on your own site is a community asset, because most people meet your link inside a chat rather than in a browser. If nothing is set, the platform renders a blank card, and a blank card in a group of two thousand people is a worse first impression than a mediocre graphic.

Build the kit in this order

Most kits are built largest first, because that is the flattering way to present work. Community assets should be built the other way round, because the smallest rendering is the one that decides whether the rest is ever seen.

1. 01The mark at its smallest, first. Draw the icon at the size it will actually appear, in a circular mask, before touching anything else. If it needs a simplified variant, that variant is the real mark for every social and community surface, and the full lockup is the exception.
2. 02Colour, dark theme first. Pick the role colours and the accent against the dark background the app defaults to, then check they survive the light one. Doing it in the other order produces a palette that looks correct in the brand book and illegible in the product.
3. 03The emote and sticker set. Six to ten, drawn to read at text height, covering the reactions the community already uses in words. This is the asset members touch most and the one almost nobody briefs.
4. 04Announcement and update frames. Two or three locked layouts with the safe areas already fixed, so a moderator filling in a headline cannot break the composition.
5. 05Structure art. Channel category headers, role art, event covers. Cosmetic on their own, but they are what makes the channel list scan as a designed space rather than a list of nouns.
6. 06The handover file. The editable templates, the naming, and one page saying what may be changed and what may not.

Six items, and none of them require a new visual language. If the identity already exists, this is a translation job. If it does not, building the community kit is a fast way to find out which parts of the identity were never resolved, because everything vague collapses at small sizes.

Design for dark, then check it inside the app

Crypto communities live in dark mode. A mark built on white with thin strokes and a soft gradient will disappear, and a transparent export that looked clean on the presentation slide will show a grey halo against a dark panel. Both problems are invisible in a design file and obvious to every member.

So the review has to happen in the actual place. Put the icon in a test server, sit it beside real servers, post the emotes in a channel, send the link into a chat and look at the preview card. This takes twenty minutes and it catches the failures that a full page mockup is specifically designed to hide.

It is the same principle as designing a teaser for a muted feed instead of a boardroom screen, which we cover in the post on teaser video for app launch: the review context has to match the delivery context, or the approval means nothing.

Templates keep the volume honest

The kit is day one. The problem starts on day thirty, when there is an announcement every other day and no time for a design round on any of them. That is where communities drift: the first announcements are on brand, then a mod makes one, then someone screenshots a spreadsheet, and by month three the channel is a scrapbook.

Locked templates fix that better than a style guide does, because a template makes the correct output the fastest one. A moderator who can drop a headline into a frame in two minutes will use the frame. A moderator who has to read a fourteen page guide will open whatever tool is nearest. The weekly rhythm on top of those templates is its own subject, covered in our post on crypto community content.

There is also the moment when the announcement wants motion and nobody has a day to spend on it. We should be transparent, because the tool is ours: ShipTeaser was built by the same founder as this studio, and it turns a product URL into a 15 second 1080p motion graphics teaser made for muted feeds, with an optional music bed and the first one free without a card. It has no voice-over, no screen recording and no timeline to edit, and it will not give you the visual system the rest of the kit inherits from. For a pinned clip you needed this morning, that trade usually works. For the identity underneath it, it is not the job.

Hand the community the tools, and be clear about the boundary

The best outcome is not that every asset comes from us. It is that members make things that look like they belong. That only happens if the raw material is available: the mark in the formats people actually paste, the emote set as files, a frame that can be filled in, the fonts named, the colours listed as values rather than described in prose.

• Editable frames, not flattened exports, for anything a moderator has to fill in weekly.
• The icon and mark in several forms, including the simplified small size variant, so nobody has to improvise a crop.
• Named colours and fonts, listed as values, in the same file as the templates rather than in a separate brand PDF.
• One page of rules, short enough to read once: what can be recoloured, what cannot be redrawn, what must never be stretched.
• Source files and usage rights, delivered as part of the engagement so the team is not blocked when we are not around.

And the boundary, said plainly: we make the material, we do not run the room. Moderation, community management and paid distribution are not what we do, and a studio that offers all of it at once is usually thin at each. What we do is the identity, the kit and the ongoing assets, which you can see across the projects on the work and in the shape of each engagement on the service cards.