Writing about client work you can't fully show

Some of the best work a designer does never makes it into a portfolio. It sits behind a confidentiality agreement, inside a product that has not launched, or on an internal tool nobody outside the company will ever see. That is frustrating when you want to show what you can do, and it is tempting to post a few screens anyway and hope nobody minds.

Please don’t. But you are not left with nothing either. There is a lot you can write about client work without breaking a promise, and the writing is often more interesting than the screens would have been. This is how we would approach it. It is practical advice from the desk, not legal advice; when in doubt, ask the client or someone who knows your contract.

Read what you actually agreed to

Before you write a word, find the contract or agreement and read the parts about confidentiality and portfolio use. They vary a lot. Some forbid any mention of the client at all. Some allow you to show work after launch. Some allow a description but not images. Some say nothing specific, which is not the same as saying yes.

Make a short note for yourself of what is allowed:

• Can you name the client?
• Can you show images, and if so, from what point (after launch, after a set period)?
• Can you describe the problem and your approach in general terms?
• Is there anything specifically excluded, such as data, unreleased features or internal names?

If the answer to any of these is unclear, the simplest thing is to ask. A short, polite message to your contact (“I would like to write about the project in my portfolio; here is what I plan to include”) usually gets a clear answer, and often a more generous one than you expected.

Ask for permission early, not after you publish

The best time to ask about portfolio rights is at the start of a project, when everyone is optimistic. Many designers add a line to their own proposals: the right to show the finished work after launch, with any confidential details removed. Clients can strike it out if they need to, but at least the question has been asked.

If you are already deep into a project, ask anyway, and be specific. Send the draft post, or a list of the images you would like to use. People find it much easier to approve something concrete than a vague request to “share some of the work”.

Keep the reply. If someone later asks why the work is public, you will be glad to have it.

Anonymise properly, not cosmetically

If you are allowed to show the work but not the client, take anonymising seriously. Blurring the logo is rarely enough. Products are recognisable by their colours, their illustration style, their copy and the shape of their interface.

A more careful approach:

• Rebuild key screens with neutral content: invented product names, placeholder text, generic photography.
• Replace the brand colours with a neutral palette, and say in the post that you have done so.
• Remove every real name, email address, account number and piece of user data, including in small print and screenshots of tools.
• Describe the client by type rather than name: “a regional transport operator”, “a mid-sized software company”.

Never show other people’s personal information, even accidentally in a corner of a screenshot. Our guidelines rule that out for good reasons, and it is the kind of mistake that is easy to make and hard to undo once a post has spread.

Write about the thinking, which is yours

Even when you cannot show a single pixel, the way you approached the problem usually belongs to you. You can write about:

• The kind of problem: “simplifying a settings area that had grown over ten years of features”.
• The method you used and why: how you mapped the existing structure, how you tested ideas, how you worked with engineers.
• The principles you arrived at: “group by the question the user is asking, not by the team that owns the feature”.
• What you learned that applies elsewhere.

Illustrate these with diagrams you draw for the post rather than real screens. A simple before-and-after sketch of an information structure, drawn from scratch, can explain a redesign better than twenty screenshots. It also shows that you understand the work well enough to explain it from first principles.

This kind of write-up follows the same shape as a full case study: problem, constraints, decisions, outcome. Our guide to writing a design case study covers that structure; the only change is that the images become diagrams and the specifics become patterns.

Be honest about what you are leaving out

Readers can tell when something is missing, and a short note helps them read the rest correctly. One or two sentences near the top are enough: “This project is under a confidentiality agreement, so the screens below are recreated with placeholder content and a neutral palette. The structure and decisions are real.”

Be clear about your role, too. On a large client project, many people shape the result. Say what you did and what others did. Claiming the whole thing as yours is unfair to your colleagues, and it can come back to you when a future employer talks to someone who was in the room.

And keep claims about results modest. If the client has not published any figures, do not invent or estimate them. “The new settings area launched in the spring” is fine. A conversion number you cannot source is not.

When the answer is no

Sometimes the client says no to everything, and that is their right. You can still mention the project in a general way if your agreement allows it, describe the type of work in your profile, or write a post about a principle you learned there without connecting it to the project at all.

You can also make a small personal project that explores the same problem in public. A self-initiated redesign of an imaginary booking flow, built to show the method you used for a client, is entirely yours to post.

Finally, remember that what you publish on RyeType stays yours, and you can ask for a post to be taken down through the contact page. If a client later changes their mind, or you realise something slipped through, it can be removed. It is much better, though, to get it right before it goes up.