D-Tier to S-Tier: A Practical Ladder for Design Responsibility

Written by gamedesignbites | Published 2026/02/05
Tech Story Tags: product-management | design | game-design | creativity | career-advice | leadership | designer-levels-framework | ownership-in-design

TLDRIn the world of product and game design, 'seniority' is a vague term. Is it about tool proficiency? Or is it something more abstract? Ishan Manjrekar breaks down the 'Framework for Responsibility'—a tiered system that categorizes designers not by their job titles, but by the complexity of the problems they are capable of solving. Whether you're an 'Order Follower' or a 'Visionary,' understanding these tiers is the key to navigating professional growth.via the TL;DR App

As you gain experience as a designer, the nature of your responsibilities evolves. When you're starting out, things might seem more straightforward, but "Design" as a concept is inherently vague. This makes career progression in design feel even more ambiguous.

Given that vagueness is a defining feature of this role, I've tried to distill it into a tiered framework.

As you advance in your career, I believe you grow by identifying the tasks you're capable of handling at each stage. This list isn’t a strict measure of seniority, but rather a tool to help you gauge your readiness based on the responsibility you’re prepared to take on.

That said, this is just my perspective. The way one approaches design is personal, and the role itself is so open-ended that there’s no one "correct" way to do it. So, take this framework with a grain of salt, and feel free to completely disregard it if it doesn’t resonate with you.

🛠️D tier

The Order Follower

“I follow clear instructions and get the job done.”

At this level, you're looking at a complete beginner. No need to know the tools, the jargon, or the processes in depth. As a D-tier designer, your job is simple: follow instructions.

You’ll be told exactly what to do — whether it’s updating a document, entering data into a tool, or supporting tasks across different parts of the project. These might seem like low-level jobs, but they’re a goldmine for learning. You see how things actually work. You start understanding the moving parts of a team.

The more willing and proactive you are, the more you’ll grow. Not just in skills, but in becoming a reliable team player who’s ready to move up.

⚖️C tier

The Self-Starter

“I know the task — how do I move forward with it?

This is the next step up. You’re still focused on execution, but now you’ve got a bit more room to move.

At the C tier, you are allowed figure out some of the how. You don’t need to be spoon-fed every step. You can plan your next moves, ask the right questions, and follow through with minimal hand-holding.

It’s also where you start showing real awareness. You spot ways to improve things—maybe a clearer process, a better document, or a smoother workflow. You’re not making the big calls yet, but your small decisions matter. They help the team run better, and they set you up for the next level.

🛡️B tier

The Executor

“The solution is clear — how do I bring it to life?

This is where real ownership begins. At the B tier, the solution is already chosen, but how it comes to life is up to you.

You're responsible for execution. You decide the details, the flow, the experience. You’re trusted to make calls on how the feature should be built, even if you didn’t choose what to build.

Let’s say the team’s decided to add a login calendar to the game. As a B-tier designer, your job is to shape it:

Where does it show up?

How does it work?

What rewards does it offer?

Who sees it, and how often?

You may not have picked the feature itself, but your decisions shape how players experience it. And if you can justify your approach, deliver results, and take up more responsibility for the outcomes, you’re on track to level up.

🔥A tier

The Problem Solver

“I have the problem — now I need to find the right solution.

At this level, the tasks get fuzzier, but your ownership gets sharper. You’re not just handed a solution to build. You’re handed a problem, and it’s your job to figure out how to solve it.

The problem could come from anywhere — product, design, tech. It might be:

  • How do we increase monetization for a specific player cohort?
  • How do we get more players to return each day?
  • How do we reduce the game’s download size without hurting the experience?

As an A-tier designer, you're expected to understand the product deeply and craft solutions that make sense. But that’s only half the job. The other half is bringing your team along with you.

Ownership here means alignment. You need to justify your thinking, get buy-in from stakeholders, and keep the team focused, even as people rotate in and out of the project. Sometimes your solution is a small fix. Other times, it’s a long-running initiative with multiple moving parts.

Either way, you're the glue. You provide clarity, direction, and momentum. You’re not just solving problems, you’re leading others through the solution.

🌟S tier

The Visionary

Which problem is worth solving?

This is the final form of a designer. At the S tier, you're no longer waiting for problems to land on your desk, you’re deciding which problems are worth solving.

Every product has countless challenges. You can't solve them all. The real skill at this level is choosing the right problems to tackle. And often, there’s no obvious answer.

That’s what sets an S-tier designer apart: the ability to define meaningful, high-impact problems based on a deep understanding of the product, the team, and the player. You’re not just reacting, you’re steering.

In a space this uncertain, your decisions won’t always be “right.” And that’s okay. What matters most is that you make decisions. Inaction is worse than a wrong call, because at least with a wrong one, you learn and adapt.

Everything you’ve built up in earlier tiers, the craft, the execution, the collaboration, comes together here. That foundation gives you the confidence to operate in ambiguity and drive the product forward, one smartly chosen problem at a time.

🌈A Spectrum

I’ve broken things down into tiers based on tasks and responsibilities, but in practice, it’s rarely this clean. Real teams, real products, and real timelines often blur these lines.

Personally, I’ve found myself working across the whole spectrum. Sometimes I have to do some D-tier duties. Other times, I’m shaping A-tier solutions. And occasionally, I’m making S-tier decisions today that hand off a trail of work for future me to follow through.

So, this isn’t a rigid hierarchy. It’s not about putting yourself or others into fixed boxes. And it’s definitely not a ranking of seniority.

For me, this framework is just a way to understand the goal of a task—what’s expected, how much ownership is needed, and how to approach or delegate it accordingly.

📜TL,DR

  • Design responsibilities evolve as you gain experience — from task execution to problem definition.
  • This tiered model isn’t about seniority; it’s about the level of ownership you take on.
  • D-tier: You follow clear instructions. Great for learning the ropes and observing how teams work.
  • C-tier: You’re told what to do, but decide how to do it. Shows initiative and improves processes.
  • B-tier: You’re given a solution and own the execution. You shape the details and user experience.
  • A-tier: You’re handed a problem. You craft the solution, align the team, and drive it forward.
  • S-tier: You identify the problems worth solving. Your decisions guide the product’s direction.
  • You’ll often operate across tiers depending on the task — that’s normal and expected.
  • Use this model as a way to clarify your current role, delegate effectively, or plan your growth.

Agree, disagree, or have other thoughts? Drop them in the comments below. And if you have questions about my profession, feel free to ask.

---

🤝If you like reading such posts, do subscribe for FREE to receive new posts and support my work.




Written by gamedesignbites | Game Design Bites is a newsletter breaking down the thinking behind game design and how modern games are built.
Published by HackerNoon on 2026/02/05