There's a Figma file sitting open on my second monitor right now. It has 2,347 frames. I know this because Figma tells me in the bottom-left corner, and I've been watching that number grow for four years. Not because I'm proud of it. It's just evidence of time. My Behance portfolio, which I haven't updated since 2021, shows a campaign microsite I built at Spacecode in 2017. Clean screens, gradient overlays, a case study that describes my "approach to user-centered design." It has a few thousand views. The VALK work, five years of actual enterprise product design, the design system that scales across a white-label platform used by 70+ financial institutions, isn't on Behance. And even if I tried to put it there, I wouldn't know what to show. The interesting parts don't photograph well. The stuff nobody posts on Dribbble If you scroll Dribbble for fintech dashboard inspiration, you will see the same things: dark mode analytics screens with glowing charts, clean onboarding flows, pill-shaped buttons with just the right amount of padding. Everything is populated with beautiful sample data. Numbers that fit perfectly in their containers. Names that are exactly the right length. You will not see the screen that shows when a user tries to initiate a token transfer but the counterparty's jurisdiction is flagged by the compliance engine, and the user has two of their own documents expired, and the transaction is above the threshold that requires additional review, and we're not sure if we should show one error or three or a combined message that explains the compound problem without creating legal exposure. That's a real scenario I spent two days on. The final design is four lines of text and a link to a support page. It looks like nothing. It will never be on Dribbble. The actual scope of a screen Here's a habit that took me a while to build: when I add a new screen to the design system, I now immediately create a column of states beside it. Happy path, empty state, loading state, error state, partial data state, permission-restricted state, deprecated feature state for old clients who haven't migrated. Sometimes the permission-restricted state has three sub-states depending on user role. In a typical case study, someone shows you one screen. That's one out of maybe eight. The empty states are actually the ones I find most interesting now, micro-UX moments that most products completely abandon. An empty portfolio isn't just a blank table. It's someone who just signed up and has nothing yet, or it's an admin who cleared a category, or it's a filter combination that returned zero results, or it's a user who had data and it's been archived. Each one needs different copy and different next-action guidance. Treating them all the same is a visible failure in the product. I've started writing the copy for empty states myself rather than leaving a placeholder for the content team. At our size, in our timezone situation, I'm in LA, the rest of the team is in London, if I leave a content placeholder, it might sit there for three weeks while we cycle through Slack threads about it. Better to write something decent and refine it than to block the build on copy. The timezone problem and what it does to documentation The eight-hour gap between Los Angeles and London changes how design work actually happens. By the time I'm fully awake and into focus, the London dev team has already had half their working day. If I send a message at 9am my time, they get it at 5pm theirs, end of day. This means every handoff note I write has to stand on its own. No "ping me if you have questions" as a safety net. If the annotation isn't clear, work stops or, worse, implementation happens based on a wrong assumption, and I find out the next day when I'm looking at the build in staging. I've become almost obsessive about handoff documentation as a result. Not in a precious way, just thorough. Every component in the Figma file has a sidebar annotation explaining the interaction, the constraint, the edge case. Every screen has a section for "implementation notes" that's separate from the design itself. Does the dev team always read it? Not always. But when something ships wrong, I can locate exactly where the communication broke down, and that's actually useful for improving the process. The annotations have gotten better over four years because I started tracking which kinds of ambiguity cause problems in implementation. Spacing is never the issue. State transitions are always the issue. File organization is design work A Figma file with 2,347 frames can be navigated in about twenty seconds if the organization is right. It can also be a complete nightmare that drives everyone away from using the file and back to "just building from memory." We have pages organized by product area, then by feature, then by component library, then by archive. Every deprecated design goes into archive with a label and a date. Every in-progress screen lives on a page called "WIP, [feature name], [my initials], [date]." When it's ready for review, it gets moved to the feature page and the WIP page is deleted. This sounds boring to describe. It took three separate Slack threads over two weeks to agree on this system. The naming convention debate is a real thing that happens at real companies, and it's not stupid, it represents genuine disagreement about how work should be organized and who the primary audience of the file is. Designers? Developers? Stakeholders? We ended up with a system that slightly annoys everyone, which means it's probably close to right. The file organization is a design decision. If developers can't find the right frame, they'll find the wrong one. If the component library is messy, people stop using it and start building one-offs. A chaotic Figma file has a real downstream cost in implementation quality, and that cost is usually invisible because nobody traces a misimplemented UI back to the file structure that caused the confusion. Accessibility annotations, the work after the design Here's one I didn't do well in the early VALK years and have since tried to get more disciplined about: accessibility annotations in the design file. Not just "make sure there's enough contrast." I mean the actual annotation layer that tells a developer the focus order of interactive elements on a complex dashboard, which elements need aria-labels and what those labels should be, how a screen reader should interpret a table with nested rows that represent different asset classes and their sub-holdings. Financial data interfaces have particular accessibility challenges because they're so dense. A screen that shows a client's portfolio isn't like a simple form, it's a hierarchy of relationships between entities, and the visual hierarchy is doing a lot of work that a screen reader can't replicate without guidance. I can't make those annotations exhaustive, there isn't time. But the key ones, on the key flows, matter. We've shipped screens where the developer inferred the wrong reading order because the visual layout was complex and I hadn't annotated it. Those are the bugs that take longest to notice and longest to trace. Maintenance as the main job At some point in the last year, I realized that the majority of my design work is now maintenance rather than creation. New features require touching existing components. A layout change in one area ripples into three other areas. The design system needs to absorb a new pattern without breaking the consistency of everything built before it. This is what the fifth year of a product looks like. I don't think anyone warns you about it. Agency work, which I did at Spacecode for several years before VALK, is almost entirely creation. You're always working on something new. The brief is defined, you design to it, you hand it off, it ships, you move on. I did this for projects with Kaspersky, with OTPBank, with a dozen other clients. The product I'm handing off is never my problem three weeks later. At a product company, you live with the decisions you made two years ago. That component I designed in 2020, I look at it now and I can see exactly what I was thinking and where I was wrong. The constraint I worked around in 2021 is now part of the furniture, and building anything new means working around it again. Maintenance is not lesser work. It requires a deeper understanding of the system than greenfield design. When I add a new state to an existing component, I have to know what every existing use of that component depends on, what will break, what will flex, what implicit assumptions developers have made based on the original design. This is harder than designing the component fresh. It just photographs terribly. What senior design actually looks like I've been thinking about what "senior" means in the context of product design, because I'm at an age and stage where I'm supposed to have figured it out. My best guess: senior design is characterized by exactly these unglamorous things. The documentation. The edge cases. The accessibility pass. The handoff so good that a developer eight timezones away can implement it correctly without a single clarifying question. The flashy part, the thing that gets portfolio views and Dribbble follows, is maybe 20% of what I actually do. And it's the 20% that requires the least accumulated knowledge. Anyone can make a beautiful empty-state illustration. Fewer people can design the logic that determines which of your six empty states the user sees and why. I'm not complaining. I'm mostly just noting the gap between what design looks like from the outside and what it is from the inside. The gap is bigger than I expected when I started. The portfolio problem My Behance sits there, quietly outdated. I look at it sometimes and feel a mild existential discomfort. The work I'm most proud of from my career is largely invisible. The tokenization platform I designed over five years has processed billions in transactions. The design system underpins a white-label product used by institutions across fifteen countries. None of this is postable in a way that generates Behance views. The agency work, the OTPBank app redesign, a few splash sites, some brand identities, those are the projects that look impressive in a scroll. They have before-and-after moments. Defined scope that fits in a slide. I don't have a solution to the portfolio problem. Maybe the people who hire senior product designers at serious companies understand that the visible portfolio is the least interesting part of the picture. Maybe they ask the right questions in interviews, how you handle edge cases, system maintenance, handoff documentation, and the Dribbble portfolio becomes almost irrelevant. Or maybe everyone just pretends the flashy work is the whole job and we all collectively agree not to post screenshots of our 47 error state variants. Either way, the work exists. The documentation is in the Figma file, annotated and organized, waiting for someone to implement it correctly. The edge cases are handled. The empty states say something useful. That's enough, even when it doesn't look like anything.

Figma

Slack

Nobody Serious Uses One AI Coding Model Anymore

Your Design System Doesn't Work: Here's Why

Portfolio

Hire Me

Blog

Read My Stories

Too Long; Didn't Read

The Design Work Nobody Posts on Dribbble

The Design Work Nobody Posts on Dribbble

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

10 Best Datasets for Time Series Analysis

12 Best Pre-Installed R Datasets Commonly Used for Statistical Analysis

Import JSON To Google Sheets - 3 Best Ways To Do It

How To Import External Data Into Google Sheets Without Copy/Paste

253 Stories To Learn About Data Analysis

Accessible Data Visualization in Fintech: Why It Matters

10 Best Datasets for Time Series Analysis

12 Best Pre-Installed R Datasets Commonly Used for Statistical Analysis

Import JSON To Google Sheets - 3 Best Ways To Do It

How To Import External Data Into Google Sheets Without Copy/Paste

253 Stories To Learn About Data Analysis

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps