Greg Wolanski

Imaginary design services

I know how it feels to not know what you want to do in life. That’s why I find the ideas I’ve described here valuable and wanted to publish them online.

Providing services as a freelancer is hard. I can’t imagine going back to the days of chasing clients for payments. Yet, I admit that I sometimes fantasize about what it would be like to focus on providing one service in a productized way.

Brand book to Storybook adaptation

Several years ago, branding companies needed people to create templates for Microsoft Word and PowerPoint (sometimes Apple Keynote) based on their brand books. These days, a missing addition to brand books seems to be a Storybook with Tailwind CSS configuration and essential components: buttons, text fields, preloaders. Maybe with sample forms, a login screen, a landing page. Maybe with tests.

The hardest thing about design systems is maintaining them and building them over time, but that doesn’t mean that creating them is a simple job that anyone can do.

Not having a design system or creating a hasty design system at the beginning of a project can be costly. It makes work slower. It takes more energy to maintain good team morale. There is never a good time to stop and do the groundwork in, for example, the seventh month of a project.

If you’re a designer who can code, you’re predisposed to provide such a service. And predispositions, I think, are worth leveraging.

Search engine design

There is something magical about search engines. And we live in a time where—thanks to companies like Algolia—even startups can afford a well–designed, high–performing search engine.

At the same time, search engine design is not popular. It’s not the hottest area of design.

Moreover, search engine design is often limited to the interface, without regard for the data structure, indexes and their configuration, performance, synonyms, and the cost of data operations.

I’ve had the opportunity to design search engines a few times in my life, to a degree far beyond the interface. It’s fascinating, rewarding work:

Take valuable content through which people want to search, enable people to find what they need, and oversee the quality of the search results over time—doesn’t that sound wholesome and graceful?

Offline design

I live in an online world. There’s a good chance you do too. But the world is full of people who don’t have such privileged access to the internet. Imagine designing software for those people.

Offline design is a big challenge. Very. Much. Against. The grain. Most tools and libraries assume you’re online. You’re offline, or your internet connection is unstable or slow? Well, you’re out of luck. Most of the knowledge out there about building software is about building online software. Want to develop offline software? Huh, good luck with that. That’s why this topic is so interesting.

With that said, the barrier to entry seems relatively high. This topic requires not only learning but also potentially researching beyond one specific project. If someone wants to work on offline design long term, they need to work for organizations that need more than one offline product. If someone wants to design offline, they need to work for organizations where offline is one of the key competitive advantages.

Phone‐first design

There are still places in the world where people have no email addresses, just phone numbers. A surprising amount of software excludes such people.

A place for a phone number in your app and integration with Twilio doesn’t cut it.

Text messages are like emails: seemingly simple but hellishly complicated in practice. If your organization wants to send messages and notifications via SMS, you need someone to come up with what messages to send, someone to draft the message templates, and someone to keep them updated. Text messages may or may not reach their recipients (what then?). Sending text messages costs money—generally more than sending an email. And don’t forget the SMS character limit. Instead of sending an SMS, you may want to send messages on a popular instant messenger—what limitations do their APIs have for developers? A multitude of design challenges.

Invisible design

In my experience, clients can be divided into those with small budgets and those who think that a) they have big budgets and b) that big budgets are good.

The problem with “big” budgets is that they come with:

  • high expectations that are very difficult to manage
  • high hopes that are hard to bring down to earth
  • big (ambitious, aggressive, unrealistic) deadlines
  • high tension in the project
  • a lot of noise
  • big changes that are difficult to manage

No one wants to spend a big budget to make a series of enhancements to an existing product or project that will improve metrics over several months.

By changing many things at once, we can’t easily see which changes work (and which ones need more work). Even when we succeed, it costs a lot more energy and takes a lot more time than when working in small steps.

By changing many things at once, we dump a large portion of the cost of handling the changes onto the end users of the project or product (customers, employees, partners).

By changing many things at once, we’re stacking the cards against ourselves.

How do you eat an elephant? Bite by bite.

I dream of being hired as a designer to improve business metrics in ways that are invisible to end users. In as few moves as possible. One experiment after another. No big presentations. No conferences or press releases. No mailings. No social media posts. Maybe just a sentence in a changelog.

Head down. Eyes and ears close to the people using the product and the people co–creating the product. Releasing designs to the world every six weeks at most. Invisible design.

April 2021

See also: How to design software that uses security keys


  • design
  • code
  • branding
  • storybook
  • tailwind
  • css
  • search
  • offline
  • lie–fi
  • phone
  • mobile
  • responsive
  • invisible