Building a design function that doesn't depend on one designer

I joined as a designer. The role kept getting bigger.

I joined NeenOpal, a data and analytics company, in 2020 as its first designer, working on visual and communication design. Within two years, the work had grown to include product design, data visualization, websites, branding, marketing and content across NeenOpal and its two in-house products, Mokkup.ai and GAfix.ai.

As the company and products grew, design became less about delivering individual pieces and more about making them work together. A dashboard needed to communicate complicated data clearly. A product needed to solve a user's problem. Marketing needed to explain why it mattered, while content and SEO brought the right people to it. All of it had to feel like it came from the same company.

At first, I could manage the work myself. Then it grew beyond me. Client work had deadlines; marketing didn't. When both landed in the same week, marketing slipped, because there was always another client deliverable behind the last one. We were building products nobody outside the company had heard of, because the person producing the collateral was also the person delivering client design.

The problem wasn't a shortage of design capacity. The company was structured around one designer being the capacity. Changing that took four years and around 20 permanent hires, 15 of whom are on the team today.

The scope I had to ask for

When I started building the team, design and UI sat under two different managers. Content didn't exist at all. The functions worked in silos, and it showed: the company didn't sound or look like one company.

I went to the founders and proposed that both design and UI report to me. I also proposed building a content team from nothing, which was beyond my skill set at the time, and I said so.

The pushback

Their objections were reasonable. How would I allocate my time across three disciplines? What would it cost the business if I got it wrong? Why would consolidation solve what looked like a coordination problem? And why did a data company need a content team? It took a month and at least ten conversations before they agreed.

My argument was that these were three core pillars of NeenOpal and its products, and that the sequence between them was fixed. The UI team knew what was shipping, which told design what collateral was needed, which told content and SEO what had to be on the site to bring in the right traffic. Split across three managers, that sequence ran on meetings. Under one function, it could be a single conversation.

I wasn't asking for a bigger team. I was asking to be accountable for two functions I didn't run and one that didn't exist.

Why it works

The three teams now coordinate among themselves without waiting for me to hand over information, and launches go out with content and marketing already in place. When we launched Mokkup in 2023, the design team was already releasing teasers and trailers, the UI team was designing the product, and the content team had blogs ready to drive organic traffic.

The point wasn't to have more meetings. It was to let work move between disciplines without waiting for a manager-to-manager handoff.

Building the team around the work

My role gradually moved from executing the work to building the team that executes it. The function now spans graphic design, UI/UX, content and SEO, working across all three companies. Each discipline has its own seniors and juniors. I set direction and standards; my seniors run the work and review it before it reaches me.

I keep track of everything in the design pipeline and what ships from it. Roughly six in every ten pieces of work now ship without my direct review. Senior designers review the rest before it reaches me. That has freed up time for product strategy and decisions for Mokkup and GAfix, and for the decisions that can't be delegated yet.

I also work with NeenOpal's frontend, backend and AI team leads on product direction for Mokkup and GAfix, and on the AI solutions we're building. Much of that role is deciding direction with those teams and the founders, then defending it.

How I built the function

01. Hiring

Most of our work depends on understanding data, or at least being willing to. Neither design school nor content training teaches it. I didn't arrive with that knowledge either, so a strong portfolio alone tells me very little about whether someone will succeed here.

Every candidate, whether in design, UI or content, completes an assessment before reaching an interview.

How it works

For design and UI hires, I ask candidates to build a dashboard for a fictional marketing agency. I deliberately leave out some details. They choose which metrics a marketing manager would need, have free rein over the design, and explain their choices and what each metric means. Content hires get an equivalent brief on a technical tool or process.

The explanation matters more than the dashboard. I'm testing whether someone can reason about what a number means and defend their choices. That's the trait that separates people who succeed at NeenOpal from those who don't, and a portfolio rarely shows it. Candidates submit the task alongside their portfolio, so I can see both their work and how they think.

What it costs

of candidates are screened out before interview, so interviews go to people who have shown they can reason about data

70%

is added to the hiring process, the tradeoff

~1 week

Since we started hiring, more than 50 candidates have made it through to an interview with me.

02. Developing domain knowledge

Designers and writers rarely arrive understanding data. I didn't either; I built that knowledge over time by working alongside my peers at NeenOpal. Rather than expecting every new hire to figure it out alone, I turned that path into something repeatable.

How it works

New hires start with the brand guidelines for all three companies, then spend three days exploring Mokkup and GAfix and come back with observations. That doubles as user feedback. Early on, a new hire flagged that Mokkup's onboarding asked too many questions, and we cut it down without losing what we needed.

They then start with simpler work, like social posts, pitch decks and brochures, which gets them familiar with data terminology and encourages them to look things up. Seniors teach them the tools the company runs on, Power BI, Tableau and Google Analytics, peer to peer. After that, they take on work across all three companies. A junior usually takes less than six months to work across all channels.

Where it works

I first used this path with an intern I hired in 2022. She came from a non-design background but showed a real capacity to learn. She is now one of my most senior designers. She oversees client projects that need design input, trains junior designers and contributes significantly to Mokkup, particularly to how elements behave in Mokkup and destination tools like Power BI and Tableau. She's one of around 10 people on the team who have been promoted, some of them twice.

03. Maintaining a quality bar

When I was the only designer, quality was whatever I accepted. As the team scaled, that standard had to hold whether I reviewed the final output or not.

I built a design checklist that every project follows, especially client dashboards. About 200 client dashboard screens a year ship against it. Since we introduced it, clients have asked for fewer design revisions and brought us more work; around 20 have returned for repeat engagements.

Senior designers are the review layer before anything reaches me, freeing me for strategy and coordination. I also run recurring internal workshops: on design principles and thinking outside the box for the design team, and on designing better dashboards for the analysts and managers we work with.

What it costs

When a senior designer repeatedly fell below the quality bar, I spent six months trying different allocations, coaching and closer reviews before concluding the role wasn't working. I let them go rather than lower the standard for the rest of the team.

04. Allocating capacity

Client work and two in-house products all compete for one team. Constantly reassigning people would create a permanent cycle of knowledge transfer, so I allocate work by capability rather than by who asks loudest. People stay in areas that match their strengths, which I identify during their learning path.

I own the design pipeline: which tasks get picked up, in what order, and whether they need a senior or junior designer. Requests come from other managers and the founders, and a large part of the job is pushing back when something isn't as urgent as the person asking believes.

What it costs

When a client product comes in, I move a senior UI designer off Mokkup or GAfix to lead it, and the juniors take the lead on the in-house product. The tradeoff is less senior oversight on that product while the client project lasts. The return is around five client products designed without pausing our own, and juniors who get real ownership early.

What the company can do now

NeenOpal is a data consultancy. Before this function existed, almost all of its work was dashboards, and design was one person fitting in around them. Three things are different now.

• A new line of work. After seeing what the team built with Mokkup, NeenOpal started taking on product work for clients: full products with data engineering underneath, which the company hadn't pursued before. The team has designed around five of them, with three more in progress for clients in the AI space, and product design is now a paid service alongside its core dashboard work.
• An organic audience for all three companies. The content team writes blogs, templates, landing pages and client case studies for NeenOpal, Mokkup and GAfix. Content is now how each gets found. For Mokkup alone it brings in about 2,500 new users a month organically, 1,600+ of them through template pages.
• Dashboards at volume. Dashboards remain NeenOpal's core business. The team designs around 200 client dashboard screens a year against one quality bar.

What changed

people across three disciplines and three companies

1 → 15

of design work ships without my review

~60%

client dashboard screens a year, supporting NeenOpal's core business

~200

client products designed, with 3 more in progress, a paid service NeenOpal hadn't offered before

~5

What still doesn't scale

The function runs without me on execution. It doesn't run without me on judgment.

Every decision that requires translating the founders' intent into what the teams build still comes through me. That's a single point of failure, and it's the same gap I've noticed in my own profile: I manage senior individual contributors, not managers.

What I'm building next is a layer of leadership. For the past six months, I've been bringing my senior-most designer into product decisions, explaining the reasoning rather than just the conclusion, and gradually handing over decisions I previously owned.

It's early, and the reasoning is the hard part to transfer. But it's the last thing standing between a function that scales in execution and one that scales in judgment.