No meetings.
No handoffs.
No waiting.

You can go from idea → implementation in minutes.

That’s what I thought would make me faster.

But I started noticing a pattern.

Midway through building a feature, I would pause and rethink:

• “Should this behave differently?”
• “What happens in this edge case?”
• “Do we actually need this part right now?”

The problem wasn’t execution.

It was that I was making decisions while building instead of before building.

So I started doing something that felt unnecessary at first.

This wasn’t new to me.

As a PM, I’ve written PRDs for years to help teams build.

But this was different.

Now I wasn’t just responsible for clarity.

I was responsible for the outcome.

There was no handoff.
No engineering buffer.
No one else to resolve ambiguity later.

If something were unclear in the PRD, I would feel it immediately during execution.

That completely changed how I write PRDs.

I began writing a PRD for every feature.

Even the small ones.

So far, I’ve written 20+ PRDs while building Travelae. Some take 5 minutes. Some take 30. But every single one turns an open problem into something structured.

Over time, I realized this:

PRDs aren’t documentation.

They’re constraint systems.

And unexpectedly, they became one of the fastest ways for me to build.

Why PRDs Matter (Especially When You Think You Don’t Need Them)

When you’re working alone or in a small team, it’s easy to assume you don’t need formal structure.

You already know what you’re building.

Until you don’t.

Without a PRD, most features exist in an open-ended state:

• The flow isn’t fully defined
• Edge cases are ignored
• Scope expands quietly during implementation
• There’s no clear “this is done” boundary

You start building with intent, but you finish with compromise.

A PRD changes that.

It forces you to:

• Define the user journey upfront
• Anchor the feature in a real problem
• Set boundaries on what is not included
• Think through failure states before they happen

The biggest shift for me was this:

A PRD turns an open problem into a closed system.

This becomes even more obvious when you’re both defining and building the feature.

In a team setting, gaps in thinking can get absorbed across roles.

As a solo builder, they don’t.

Every missing detail shows up as friction during execution.

That feedback loop is immediate.

And it forces a higher level of clarity upfront.

Once that system is defined, execution becomes straightforward.

Not because the work is easy.

But because the decisions are already made.

It also becomes your single source of truth.

Not just for a team, but for:

• Coding agents
• Future iterations
• And your future self revisiting the feature weeks later

The PRD Template I Use (And Why Each Section Exists)

This is the exact structure I use for every feature

If you want to use this yourself, I’ve shared the exact template and system prompt here: GitHub Repo Link

But the goal isn’t to be strict.

The goal is to be specific.

Earlier in my career, “specific” meant making things easier for engineers.

Now it means making things buildable for myself.

That shift changes the quality of thinking.

You stop writing for communication.

You start writing for execution.

Each section exists to eliminate a certain kind of ambiguity.

1. Objective

This forces clarity.

If I can’t explain what I’m building in 2–3 sentences, I’m not ready to build it.

It answers:

• What are we solving?
• For whom?

2. Problem Statement

This grounds the feature in reality.

Without this, it’s easy to build things just because they “feel useful.”

This section makes sure:

• There is a real user problem
• The feature is not just output

3. Functional Requirements

This is the contract.

Not how the feature works internally, but what it does externally.

Example mindset:
Instead of:
“Use X library with debouncing.”

I define:
“Users see updates reflected consistently across devices.”

This keeps implementation flexible while keeping behavior fixed.

4. Technical Notes

This is where context lives.

Not implementation instructions, but:

• Data considerations
• System interactions
• Constraints

It helps guide engineering (or AI agents) without dictating architecture.

5. Edge Cases

This is where most features break.

Examples I think through:

• Missing data
• Conflicting inputs
• Partial states

If it can break, it will.

Better to define it now than debug it later.

6. Non-Goals

This might be the most important section.

It defines what we are explicitly not building.

This is how I prevent scope creep.

It gives me a simple response during execution:
“That’s v2.”

7. Success Metrics

How do I know this worked?

Even if it’s simple:

• Completion rate
• Reduced friction
• Fewer user errors

This keeps the feature tied to outcomes, not just output.

8. Security / Permissions

Who can do what?

This prevents issues later when:

• Multiple roles exist
• Data access matters

9. Dependencies & Blockers

This makes sequencing visible.

What needs to exist before this works?

Without this, you risk building something that can’t function yet.

10. Open Questions

This is underrated.

Anything unclear gets listed here.

Because if it’s unclear now, it will break later.

A Small but Important Detail: Markdown

All my PRDs are written in markdown.

Not for aesthetics.

For reasoning.

Technically:
Structured markdown improves how LLMs interpret and process context.

Simply:
Clean structure = better output.

This becomes important when PRDs are used directly with AI systems.

A Real Example: Expense OCR Flow

One feature where this structure made a clear difference was the expense of the OCR flow.

The feature sounds simple:
Upload a receipt → extract data → create an expense.

But without structure, this quickly becomes messy.

So I defined the flow clearly:

Draft → Extract → Confirm

This is also where I felt the difference most clearly.

As a PM, I would have written this PRD and aligned the team.

As a builder, I had to live with every decision inside it.

If something was vague, I couldn’t delegate the ambiguity.

I had to resolve it.

That forces better systems.

Key Decision

Extraction is on-demand, not automatic.

This was enforced in the Non-Goals section.

Why?

Because automatic extraction:

• Adds unpredictability
• Creates background processing complexity
• Reduces user control

Edge Cases Considered

• Multiple totals on receipt
• Missing currency
• Blurry images
• Foreign currency formats

Without defining these upfront, the system becomes inconsistent.

With them, the behavior is predictable.

What This Changed

Instead of building and adjusting later, the system was:

• Defined before implementation
• Clear for both human and AI execution
• Easier to extend later

This is where PRDs become more than planning.

They become execution constraints.

Common PRD Mistakes I See (And Have Made)

1. Writing HOW before WHAT

Jumping into tools and implementation too early.

This reduces flexibility and violates clean execution boundaries.

Define behavior first.

2. No Boundaries

If everything is included, nothing is prioritized.

No Non-Goals = built-in scope creep.

3. Too Vague to Implement

“Improve experience” is not a requirement.

Specific flows are.

4. No Problem Statement

This leads to feature factory behavior.

Output without purpose.

5. Ignoring Edge Cases

Happy paths don’t survive real usage.

A simple pattern I’ve learned:

Open-ended inputs → open-ended outputs.

PRDs fix that.

PRDs as Content Artifacts (The Unexpected Benefit)

This part I didn’t plan.

But it turned out to be one of the highest leverage outcomes.

Every PRD already contains:

• The problem
• The system
• The decisions
• The tradeoffs

That’s already 80% of a case study.

So the workflow becomes:

Write PRD
→ Ship feature
→ Extract learnings
→ Publish

The work doesn’t increase.

It compounds.

For example:

• A trip progress system, defined as a weighted model, became a publishable framework
• A booking model PRD became a story about schema evolution

The PRD isn’t extra work.

It’s the foundation.

I’ve also made the exact PRD template and generation system available here if you want to adapt it: GitHub Repo Link

How I Use PRDs with AI

This is where things become even more interesting.

Instead of prompting from scratch, I use the PRD as the input.

Flow looks like:

PRD → AI plans implementation → I review against constraints

My role is not to dictate how something should be built.

This is very different from how I used PRDs earlier in my career.

Before, PRDs were alignment tools between PM and engineering.

Now, they are execution inputs for AI systems.

That raises the bar.

Because AI doesn’t interpret ambiguity the way humans do.

If something is unclear, don’t push back.

It just produces inconsistent output.

This makes clarity in the PRD even more critical.

It is to ensure:

• Business logic is preserved
• Constraints are respected
• Complexity is controlled

One practical rule I follow:

Minimize unnecessary integrations.

If one system can handle multiple concerns, prefer that over stitching multiple tools together.

Example:
Using a unified Firebase layer instead of building multiple custom abstractions.

The PRD ensures:
The system remains intentional, not accidental.

How to Use This Template

You don’t need to follow this rigidly.

Some PRDs take 5 minutes.

Some take 30.

Not every section needs depth every time.

But every feature should have:

• A clear objective
• Defined behavior
• Boundaries

A short, specific PRD will always outperform a long, vague one.

PRDs are often seen as overhead.

In practice, they remove friction.

They:

• Reduce decision fatigue
• Prevent scope creep
• Make execution predictable
• Improve collaboration with both humans and AI

You don’t need more tools.

You need better constraints.

Learning Resources

If you’re interested in improving how you think about building products, design, and execution, these are some people and communities worth exploring.

Product Thinking

• Lenny Rachitsky / https://www.lennysnewsletter.com
• Akash Gupta / https://www.news.aakashg.com/
• Waqas’ Musings / https://waqaswrites.substack.com/

Design Thinking

• Dan Mall / https://danmall.com
• Dive Club by Michael Ridding / https://dive.club
• Beyond UX Design By The Great Jeremy Miller/ https://www.beyonduxdesign.com

Creating your first design portfolio?

A mentor who had a meaningful impact on my early career is Aneta Kmiecik.

She created a thoughtful course on building strong UX portfolios that has helped many designers structure their work and tell their story better.

If you’re early in your design journey or improving your portfolio, her course is worth exploring:

https://www.uxportfolio.co/

Abdullah Qureshi

Product systems, AI execution, and product thinking.

Exploring better ways to build products.

I’m curious:

If you’re building with or without PRDs today, where do things usually break?

Before implementation, during it, or after shipping?

Travelae is a group travel planning app I’m building to simplify how people make decisions together.

Instead of fragmented chats and spreadsheets, it brings planning, expense tracking, and coordination into one shared space.

If you’ve ever tried planning a trip with 4–5 people, you already know the problem.

It was simple on the surface.

A group travel planning experience. Something that could help people coordinate decisions, manage shared expenses, and move faster as a group.

I had done this before.

Not this exact product, but similar workflows.

PM defines the problem.
Design structures the experience.
Engineering builds and iterates.

It works.

But it takes time.

And this time, the question was different.

How fast can we go from idea → something usable → real feedback
If we use AI properly?

Not casually.

Properly.

That question changed how I approached the entire process.

The Problem Was Not Building. It Was Translation.

In most product environments, the real cost is not writing code.

It’s a translation.

• Idea → PRD
• PRD → Design
• Design → Engineering
• Engineering → Output
• Output → Feedback

Each step introduces a delay.

Each step introduces interpretation.

Even in fast teams, this loop takes days or weeks.

So the hypothesis became simple:

What happens if we compress the translation layer?

Do not remove thinking. Not skip structure.

But reduce the number of handoffs.

The Shift: From Low-Cost Design → Low-Cost Development

Earlier, design iteration was relatively cheap.

You could sketch, wireframe, and iterate quickly.

Development was the expensive step.

That has flipped.

With coding agents improving rapidly, development has become significantly cheaper.

You can go from:

Idea → working UI → basic integration

in a very short time.

But only if the input is structured.

That’s where most people get it wrong.

They assume:

Prompt → Output

In reality, it’s:

Constraint → Structure → Prompt → Output → Refinement

How I Actually Built a Feature

One of the early features in Travelae was:

Scan a receipt → extract data → create a draft expense → assign it to trip members.

On paper, this touches:

• OCR
• Data parsing
• Expense logic
• Multi-user mapping

Traditionally, this would involve:

• Design flows
• Backend setup
• Integration planning
• Multiple iterations

Instead, I approached it differently.

I created a structured PRD that included:

• User flow
• Functional requirements
• Edge cases
• Engineering considerations (OCR + LLM parsing)
• Design constraints aligned with existing patterns

Then used that as input.

Not a vague prompt.

A structured one.

It took around 1–2 iterations and under 10 prompt cycles to get something usable.

Manual work still existed:

• Firebase setup
• API key handling
• Some cleanup

But the core feature moved from idea → working state in under an hour.

That’s not normal.

And it changes how you think about building.

Sneak peek to the feature in build mode: https://www.youtube.com/shorts/xcvOT_iqOU0

Where It Broke (And It Did)

This wasn’t smooth.

One failure stood out.

I was switching between coding agents due to limits.

Claude → another agent → back again.

There was no structured progress tracking.

So every time:

The agent had to re-read the codebase
Re-map it to the original intent
Reconstruct context

At one point, I ended up with:

80 broken files in a branch
Inconsistent rewrites
Lost structure

I had to drop the branch entirely.

That’s not a small failure.

That’s lost time.

What Changed After That

That failure forced a shift.

I stopped relying on memory and context windows.

And introduced:

1. Feature-level progress logs
Every feature had a tracked state:

• What’s done
• What’s pending
• What assumptions exist

2. Engineering and design guidelines as references
Instead of:
“Read the codebase.”

It became:
“Follow these constraints.”

3. Structured PRDs as the source of truth
Not optional. Mandatory.

This reduced:

• Re-reading overhead
• Context loss
• Inconsistent outputs

The system became more stable.

Not perfect.

But predictable.

The Real Skill Is Not Prompting. It’s Framing

Early on, my prompts were lightweight.

They didn’t work well.

Now, every meaningful input includes:

• Clear problem definition
• Constraints
• Edge cases
• Functional and non-functional requirements
• Design considerations
• Engineering considerations

This is not overkill.

This is what allows AI to behave predictably.

Without this, you get noise.

With this, you get direction.

The Hardest Part: Knowing When to Stop

This is where things get dangerous.

Because it’s easy to keep going.

You can always:

• Improve UI
• Add features
• Refactor flows

The system will keep responding.

But more output does not mean more value.

The rule I’ve started using is simple:

If the feature delivers the intended business value
and is usable enough for real users

Stop.

Ship.

Validate.

Everything else is a rabbit hole. And with AI now, you can easily go down this path.

What does this change for PMs

This is not about turning PMs into engineers.

It’s about reducing dependency on translation.

You still define:

• The problem
• The outcome
• The constraints

Engineering is still defined:

• Architecture
• Performance
• Scalability

But now:

You can validate ideas before full engineering involvement.

That changes your role.

You move from:
Spec writer

To:
System framer

What This Changes for Teams

In a traditional setup:

PM → Design → Engineering

Now, early-stage validation can bypass parts of this.

Not permanently.

But temporarily.

Once something works:

• Design refines experience
• Engineering strengthens systems

The order changes.

Not the importance.

There’s a Larger Shift Here

I haven’t fully tested this at team scale yet.

But there’s a direction forming.

If:

• PMs structure inputs properly
• Designers define interaction constraints
• Engineers define system boundaries

And all of this is captured as reusable inputs

Then:

You don’t just build features.

You build systems that help you build faster next time.

This is still evolving.

But it’s where this is heading.

What Still Feels Unresolved

A few things are still unclear:

• Switching between coding agents creates inconsistency
• Style and structure can drift
• Velocity can compromise long-term structure
• Scaling beyond early users is still untested

Right now, this works well at:
10–15 users

The next step is pushing it further.

That’s where real constraints will show up.

The Actual Takeaway

This is not about React Native.
Or Firebase.
Or any specific tool.

It’s about this:

If you reduce translation layers
and increase structured inputs

You can move from:

Weeks → Hours

But only if you stay disciplined.

One Line I Keep Coming Back To

If a PM is using AI without constraints, they are not accelerating execution.
They are just generating noise.

I’m still experimenting with this.

Still refining how much structure is enough.
Still figuring out what breaks at scale.

But one thing is clear:

The bottleneck is no longer just engineering.

It’s how clearly you can define what needs to be built.

Travelae is currently in development and getting ready for its first Android release.

If you’d like early access or want to follow along as it evolves: https://travelae.co/

I’m especially interested in feedback from people who actively plan trips in groups.

I hope you found the story and the learnings useful.

If it resonated with you, consider sharing it with someone who might benefit from it as well. Thoughtful ideas travel further when people pass them along.

Thanks for taking the time to read all the way through.

More experiments and learnings are on their way.

I’m curious:

If you're experimenting with AI in product work, where has it helped you the most so far?

Research, planning, execution, or something else?

Learning Resources

If you’re interested in improving how you think about building products, design, and execution, these are some people and communities worth exploring.

Product Thinking

• Lenny Rachitsky / https://www.lennysnewsletter.com
• Akash Gupta / https://www.news.aakashg.com/
• Waqas’ Musings / https://waqaswrites.substack.com/

Design Thinking

• Dan Mall / https://danmall.com
• Dive Club by Michael Ridding / https://dive.club
• Beyond UX Design By The Great Jeremy Miller/ https://www.beyonduxdesign.com

Creating your first design portfolio?

A mentor who had a meaningful impact on my early career is Aneta Kmiecik.

She created a thoughtful course on building strong UX portfolios that has helped many designers structure their work and tell their story better.

If you’re early in your design journey or improving your portfolio, her course is worth exploring:

https://www.uxportfolio.co/

Abdullah Qureshi

Product systems, AI execution, and product thinking.

Exploring better ways to build products.

A few months ago, a founder sent me a document.

It wasn’t really a document.

It was a mix of ideas.

• Google Docs notes.
• Email threads.
• A FigJam board.
• Some old metrics in a spreadsheet.

Half-formed thoughts about what the product could become.

Nothing about it was wrong.

It just wasn’t structured.

And that’s where most of the real work in product begins.

Turning fragments into something a team can actually execute.

Vision → Strategy → Value Modules → Function-aligned task skeleton

That translation layer usually takes time. Days, sometimes longer.

So I started experimenting with something simple.

Not using AI to write documents.

But using it to compress what comes before them.

The messy layer.

• Where ideas are still forming.
• Where assumptions are unclear.
• Where direction exists, but structure doesn’t.

What followed was a constraint-driven workflow that helped turn early product thinking into structured MVP roadmaps much faster without losing clarity for engineering or design.

It didn’t work perfectly at first.

But the parts that held up under real projects became the foundation of what I’ll share today.

The Hypothesis

AI can compress strategic translation work.

But only if:

• You define constraints clearly
• You enforce boundary conditions repeatedly
• You break large contexts into controlled loops
• You review outputs as a thinking partner, not a passive consumer

If you ask for everything in one go, it drifts.

If you constrain it step-by-step, it becomes useful.

Where It Broke

Early attempts failed.

Large chats hallucinated.

The model would:

• Add features we never discussed
• Inflate scope
• Drift into exploration
• Lose discipline on constraints

Bigger context windows didn’t help. Smaller, structured chunks worked better. So I changed the approach.

Instead of asking for summaries, I asked for:

“Perform a detailed audit. Extract governing principles, constraints, assumptions, and working rules from this discussion.”

Then:

“Turn this into a reusable system prompt so I don’t redefine everything in the next session.”

That was the turning point.

I stopped re-explaining context.

I started carrying forward structured rules.

Drift has been reduced significantly.

Why Markdown Became the Thinking Layer

I experimented with spreadsheets early.

It didn’t work well.

Spreadsheets/docs are excellent for the final structure.

They are not good for reasoning.

Markdown (.md) worked better.

Hierarchical.

Clean.

Constraint-friendly.

Technical:

“Hierarchical markdown improves reasoning continuity across model context windows.”

Simple:

AI thinks better when the structure is clean.

So the rule became:

• Think in .md
• Finalize in Sheets/Docs

GPT models handled structured continuity well.

Gemini 3/3 Pro generated better-formatted sheets.

So the flow evolved:

• GPT → reasoning layer
• Gemini → formatting layer
• Manual review → authority layer

Multi-model validation > single-model dependency.

The Framework

This has been applied across 3–5 product directions:

• New product exploration
• Feature expansions
• Strategic pivots
• Agency consultations & costing
• Data-backed optimization

It works for both zero-to-one and existing products.

For existing systems, we add a data layer.

Instead of validating assumptions,

We define measurable deltas.

Mini Example

Let’s say the founder says:

“We want collaborative credit allocation between lenders.”

That sounds simple.

But it’s not a feature.

It’s a vision fragment.

Step 1: Vision Clarification

Why does this exist?

Maybe:

• Reduce manual allocation time
• Increase lender participation
• Improve facility utilization

Step 2: Strategic Entry

Where does it sit in the current system?

Does it:

• Modify an existing credit workflow?
• Introduce permission layers?
• Affect reporting logic?

Step 3: Outcomes Mapping

Higher-level goals:

• Reduce allocation time by 30%
• Increase multi-lender participation by 20%
• Improve operational visibility

Now we move to structured modules.

Module: Credit Collaboration Layer

Now functional task skeleton (not engineering implementation):

• FE: Build lender allocation interface
• FE: Display facility utilization metrics
• BE: Create allocation logic API
• BE: Implement validation rules for facility constraints
• Infra: Configure permission and role controls

Important:

This does not define architecture.

It defines operational outcomes and ownership boundaries.

Engineering decides how.

Product defines what and why.

That distinction matters.

Especially for PMs early in their career.

Over-specifying is dangerous.

Under-specifying is also dangerous.

This framework helps define value clearly without dictating implementation.

What Changed

Vision structuring: Week → Hours

Roadmap skeleton: Days → Minutes

Estimation for agency setups: Turnaround within a day

Engineering clarification loops: Reduced significantly

Backlog maintenance overhead: Reduced

More time shifted toward:

• Execution support
• Outcome tracking
• Refinement

Less time spent: Translating chaos into structure

Automation Layer

This can be automated via:

• n8n workflows
• Custom AI agents
• Google Docs and Sheets integrations

I’ve explored using Claude Code with custom agents that have access to everything.

The throughput is extremely fast. Almost too fast.

It becomes addictive. And the terminal is not ideal for collaborative review.

Reading large structured outputs reduces clarity.

For this kind of strategic translation work, semi-automation is better.

• Side-by-side review.
• Readable formats.
• Controlled pacing.

Speed without discipline creates new chaos.

The Real Lesson

The mistake is expecting AI to solve everything in one prompt.

For non-trivial work, it doesn’t.

It works best when treated as:

• A structured thinking partner.
• A constrained system.
• A reusable workflow.
• Not a content generator.

Once your system prompts are defined,

you don’t start from zero each time.

You refine.

I am working on publishing a repository of the system prompts that have held up in practice.

If they help your workflow, please reuse them and share how they’ve helped.

Still Evolving

This framework is not final.

As I experiment more:

• with custom agents,
• with model improvements,
• with larger context windows

I’ll continue refining it.

And I’ll share what survives real usage.

No hype.

Just what holds up under execution pressure.

I hope you found the story and the learnings useful.

If it resonated with you, consider sharing it with someone who might also benefit. Thoughtful ideas travel further when people pass them along.

Thanks for taking the time to read all the way through.

If you’re experimenting with AI in product work, I’d be curious to hear what’s working for you or what hasn’t worked so far.

Learning Resources

If you’re interested in improving how you think about building products, design, and execution, these are some people and communities worth exploring.

Product Thinking

• Lenny Rachitsky / https://www.lennysnewsletter.com
• Akash Gupta / https://www.news.aakashg.com/
• Waqas’ Musings / https://waqaswrites.substack.com/

Design Thinking

• Dan Mall / https://danmall.com
• Dive Club by Michael Ridding / https://dive.club
• Beyond UX Design By The Great Jeremy Miller/ https://www.beyonduxdesign.com

Creating your first design portfolio?

A mentor who had a meaningful impact on my early career is Aneta Kmiecik.

She created a thoughtful course on building strong UX portfolios that has helped many designers structure their work and tell their story better.

If you’re early in your design journey or improving your portfolio, her course is worth exploring:

https://www.uxportfolio.co/

Abdullah Qureshi

Product systems, AI execution, and product thinking.

Exploring better ways to build products.

How I Built a Constraint-Driven AI Framework That Turns Product Vision into an MVP Roadmap in… was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

How’s it going? So recently, I transitioned to a new role as a PM. And while I was excited about the transition. I missed the design side of things. Since it’s something I am passionate about. It was an opportunity that was handed to me and I had to make do with what I had. It’s been a rollercoaster but a good learning experience so far.

And while I was going through this transition I had a course that I had enrolled in some time ago for learning more about the mindset of a designer. It had been on my wish list for a long time. And finally, over the last few weeks, I put in the time to complete it. How did I find the course? I happen to have stumbled upon a post from one of my favorite design people. The course was How to train your designer’s eye by Krisztina Szerovay.

This is a reflective summarization of the content of the course. I created the article from my notes to help organize and reinforce the concepts. While it has been a truly great learning experience for me. I am hoping that it will be for others as well.

The course had been nothing but insightful. But a thought here is that at first, I found the course to be very slow. And that is because I defaulted to truth and judged the book by its cover. I assumed that the course would be only on the visual aspects of things. And it was not only that. It emphasizes how to get into that mindset and train the eyes to be visually analytical. Not just digitally but all around us.

And before I share my thoughts and learnings. I just want to give a shout-out to Krisztina Szerovay for making this amazing course. And to Jeremy as well for recommending it on LinkedIn.

Here’s a quick overview, the course starts with the “why” of collecting design inspirations. The value and importance. Then we moved on to “what” we should collect. “How” collecting and analyzing good and bad design needs to be a practice. Knowing about the power of sketching we sought the value of research. After we had understood the why, and how. We emphasized the practice of analyzing design. We started with how we should analyze our design inspirations. By using the power of “why” we try to figure out what we could have done better and what’s good in the experience. Krisztina discussed a lot of new concepts. At least they were for me. Which unknowingly I might have been doing. One particular such is block framing. Then we moved to design critiques and a comprehensive example of all the steps involved in the practice:

• Finding design inspirations
• Collecting and organizing inspirations
• Analyzing the good and the bad things
• Using “why” to find opportunities
• Working on design solutions

And this just keeps coming back to me “Practice makes permanent”. This is one of the quotes that people go on emphasizing and so was in the course. It’s not enough to be collecting and analyzing design inspirations. We need to put our training of our designer’s eye through experimentation. And it should be a consistent habit, nothing bests deliberate practice.

While there was a lot to learn from the course, here are some of my key takeaways with my thoughts.

Continuous efforts of collecting design inspiration

One of the main focuses of the course was on collecting design inspirations. And how it should be a continuous effort. It not only helps us to stay up to date with new trends. But also enables us to have the habit of seeing the good and bad examples in designs. And how we as designers can learn from them. And know how we can use those learnings when we face challenges with our problems.

Getting in the mindset of a designer

Another interesting thing I learned from the course. That is while we at most times associate UX with digital products it’s not always the case. We are surrounded by things that are all designed. In the course, Krisztina shared how she while making breakfast analyzed the packaging of the milk. And that realization of seeing things from a perspective of how they’re made. Gets us in that designer’s mindset. I know that subconsciously as designers we all do that. We critique everything, the menus, the posters and all that is designed around us. But to have it done deliberately is a different practice. When we get into this practice. We become analytical. And try to understand the what, why, and how of the decisions behind the creations.

Using 3 levels of designs for analysis

The levels of assessing designs were fairly new to me. Having created interfaces for some time now, both as an engineer and a designer. I never looked at and provided feedback with them in mind. They are from the man himself, Don Norman. According to him, we have 3 levels of design and how we should use them to assess our designs.

• Visceral
• Behavioral
• Reflective

The first interaction we have with the design is a visceral one. Where we analyze the design by appearance, first impressions, and initial impact. Then we see how it behaves. The usability of the design, how performant it is and what’s the flow of the experience. Finally, we reflect on how meaningful the experience is. And how it helps, and creates an identity of the product for the users. These are just the higher-level abstractions of how the levels go. You can read more about them here. And there is a super cool sketch from Krisztina

Critiquing everyday designs helps

Following the habit of collecting design inspirations. And analyzing them based on 3 levels of design we must critique them as well. And by that I mean not only the bad examples but also the good ones. What works and why? Making notes and trying to understand why the decisions were made to have it that way. This enables us to rationalize and see how experienced designers and design teams think. And we can use these notes and apply them when we work on our solutions. While the context and the use cases can be different. The small details such as the UI elements, behaviors, and usability remain the same in most cases. And having a design that’s easy to learn through repetition is not just good for the experience. But other experiences contribute to the learning of our experience making it easy for the users to use our designed experience.

Power of getting ideas down on paper

I am big on just getting stuff on the paper, Idk but the feeling of just writing something down is different. Having a pencil, eraser, and paper to just think and act is powerful. I think we can explain more of our ideas if we draw them out and re-draw them until we make something of it. And this was another great thing that came up in the course. So while I prefer an old style. It necessary doesn’t have to be it. That’s where I learned about “Block framing” from the course. It is the activity of analyzing the designs based on layouts and content structures. It’s like a skeleton but more so that it’s a high-level low wireframe. Where we see the layout and content structure but do not get lost in the details of things. And that’s quite interesting and good advice. The way to go about it is through focusing on one area and building up the complete idea.

Habit of design experimentation

Another great way to train our designer’s eye is through design experimentation. The idea is that we try to copy the design of the existing solutions. And in doing so try to come up with variations of designs that could work as well. Making this a habit can be great. As it would help to see how good design solutions work and why. And how variations of the same design can still work. The variations could include many different aspects. Such as visual hierarchy, UI elements, colors, and typography. And while the course had its practice activities. I learned about this more through my practice of taking the daily UI challenge. While I know, not all outcomes were good some turned out to be okay as well. You can check them out here.

Being around design inspirations

Another important learning from the course. Was that we surround ourselves with good design inspirations. And it should not only be limited to examples, apps, and products. But also with great people. Krisztina mentions that in the right way. “Leveraging the power of the design community”. We often fail to do just that. I have been too a failure at this for a long time. However, I am trying to position myself better in the design community. And have met so many awesome people who are enabling me to learn more stuff each day. Their experience helps in navigating not only the design aspects of things. But other aspects as well. And I am very grateful for that and them. And just to solidify the advice here, I woundn’t have even known about this course. If it wasn’t from someone I interact & learn from on a weekly basis on LinkedIn.

Practicing to train the designer’s eye

And as all things go, the key to all learning & training is practice. Yes, practice. There is a saying that practice makes perfect. I feel the more apt thing would be that “practice makes it permanent”. It could be from the way the course tells us or we could come up with our system. But as a direction goes, we should collect design innovations frequently. Analyze them. Think about applying them in specific contexts. Create our design variations, conduct research, and repeat all this. Hopefully, with enough practice, we will have formed a habit and it comes to us naturally.

This course was a great learning experience, I hope it can be for you as well. Here’s a link to it, you should check it out.

I also recommend following Krisztina, she has some amazing work. And I like her short-form articles and love the sketches. Going to practice making a few of those for myself as well. You can check them out here.

I hope you liked the story and my learning. If it was helpful, I’d appreciate you share it with others who can learn from it. Thanks for reading till the end. 🙇🏻‍♂️

More learnings are on their way! 🚀

Want to level up your design knowledge?

Here are some resources for you to look at. They will surely help you out in your UX journey. They focus on more than just design:

• https://www.instagram.com/ux.aneta/
• https://www.beyonduxdesign.com/
• https://www.dive.club/
• https://danmall.com/

Are you creating your first design portfolio?

You can use Framer to do that, it can be a great choice:

• It’s easy to set up and start with.
• Is very similar to Figma, so there is a minimal learning curve.
• And there are a ton of free templates & resources to get you started.

I made my portfolio on Framer. You can check it out here.

If you’re ready, use my link to get started. It’s a referral link. So if you use that. I might make some quick bucks. No extra charges from you. And if you use the promo code: partner25proyearly for the yearly subscription. You get 3 free months on the Pro annual subscription.

Hey Everyone 👋🏻

How’s it going? Following my learning on low-maturity software teams. We discussed already what’s meant by a low-maturity software team. What happens in there, and how do things get affected? We touch points on it from a general perspective. A UX designer’s perspective.

But today, let’s expand on the topic and highlight it from a product/project manager’s perspective. And in case you haven’t read the last stories, you can do from the links below 👇🏻

→ A general understanding

→ A designer’s battle

→ A PM’s responsibilities 👈🏻

In a low-maturity software team, the operational maturity of the team is low as well. There are matrixes for “how” to work, but not as prevalent. There are few processes for accountability.

As we discussed in the last story. In low maturity software team. There are no clear:

• Goals & Objectives
• Roadmaps
• Clear communication
• Strategic Vision
• Metric for success

As a product manager, it’s our job to enable the team to do their best work and manage the stakeholder influence. And that can only happen when we have clarity on the product vision and goals. And “how” we can get this? By involving the team in the discovery part of the process. Discovery is one of the most important aspects of the product development life cycle. It’s unbiased. The design and engineering teams should be part of this step. They help to bring clarity to the user’s perspective and the technical challenges. Add value to the roadmap planning. Align the team with product vision and goals. I believe that adding the stakeholders to the discovery process helps us to make them understand the:

• User needs
• Pain points
• Expectations
• Behaviors

And when we are clear on product vision, we can create effective timelines. Plan a realistic roadmap. Make achievable milestones.

How to work in a low operational maturity team as a product/project manager

Understanding the team players is the most important aspect of team management. As product managers, we must find who works well with whom and with whom they don’t. Build and foster relationships through shared trust. Having regular 1:1s to understand them better. By doing all this we can enable our team to work together and help them grow individually as well.

Setting an accountability matrix for the team is also an important one. It not only helps them to understand their roles and responsibilities. But also helps us to set acceptance criteria for their work and in return the product. The matrix also helps to create a framework of self-accountability that everyone can practice in their workflow. The RACI matrix is a good example here. It can be set up at project kickoff. It defines roles, responsibilities, and expectations for the team. And it also serves as a great onboarding document. My take here is that I go beyond this. While having a RACI matrix, I defined the tools & guidelines for communication. So that everyone uses the same methods. This helps the team to stay in sync and also if someone needs help they can figure it out together.

As the one leading the product team. It is our responsibility to understand and elaborate on the product features. We have to pair up with the design team to understand the users and what they need to achieve. That means making designers our allies. Because while we focus on the product their focus is on the user and user only. They help us to help themselves and that in turn helps the whole team.

Communication is the key here. As the leader, it is our job to help conversations among the team better. It helps them to understand each other better, the needs and break silos. And why is that important? Because “To build great software, we need to build great relationships”. ~ Jeremy Miller

Have an open door policy, as the point person on the product and the leader of the team. We should always be ready to provide clarity to the team on the product and its application. We need to enable the team to ask questions. More questions can lead to a clearer picture of the end outcome. And it’s not always about the clarity, maybe they have a blocker that they need help with or it’s more a personal thing. And it’s not always that we might be able to assist them but just be open to sharing ideas and in some cases direct them to the right path. That helps a lot.

One of the most important aspects of the job is to manage the stakeholders. It’s the most exciting and the same time the most challenging. The way of dealing with a stakeholder also depends on the stakeholder's maturity level. But as the person who has to, directly collaborate with them. We can try our best to do so. We need to understand that stakeholders can bring great value to the team. They have insights on the business that we can’t think about.

But what to do when stakeholder influence starts to dictate? We should always steer towards advocating for the users. Using user-centric data we keep having rational discussions. It’s important that we set up boundaries from the very start. This helps to manage expectations and keep their influence in check. We need to make their role clear and understandable. They can share as much about the business as they want. But let us handle the intricacies and the technical implementation.

The term stakeholder maturity is also a thing. High-maturity stakeholders have effective collaboration with the software team. Trust the team and their expertise. Low-maturity stakeholders are the opposite. They disrupt the entire process, they:

• Overstep roles
• Dictate terms
• Micromanage things outside of domain expectations
• Push own agenda
• Compromise on quality

There are a lot of matrixes to check the stakeholder maturity. And help us to plan how we can work with them. The two mentioned in the “CHOAS to CLARITY ” series were SEAM and SAM. They both have their significance. But both act as a guiding compass in stakeholder management. And how they do that can be another story. But in summary, the stakeholders that are of high interest are the ones we need to engage and keep happy.

The us vs them narrative. It’s a cliché term. But it’s quite common and one way or another it happens at some point. And how we can overcome this? We can “Learn to speak the language their language.” This adds credibility to our work. And what does this language involve?

• How the business does the business?
• How does the business earn money?
• Why we’re doing what we’re doing?

Making them part of the team ~ stakeholders. When they are part of the team. We can have more active communication and feedback loops. Help them see how we work, the processes, and the decisions. Educating them on the user challenges, our solutions, and their impact. Involving them from the get-go makes them feel part of the team. They have an understanding of what’s going on and have less resistance. It’s not about giving them free rein but constructively involving them.

So while we know about low-maturity software teams. Some important responsibilities as a PM. How do we, the PMs enable such a team to do great work? Manage the stakeholders and their influence. With good empathy for the team, we understand what they're good at, and what are their struggles. Build relationships with our teams. Find our allies. And be open to hearing them out and sharing ways on how they can work more effectively. And most importantly “build great relationships to build great software”. And lastly have patience, it’s a long game. Change happens with time.

I hope you liked the story and my learning. If it was helpful, I’d appreciate you share it with others who can learn from it. Thanks for reading till the end. 🙇🏻‍♂️

More learnings are on their way! 🚀

Want to level up your design knowledge?

Some resources for you to peak at. They will surely help you out in your UX journey. They focus on more than just design:

• https://www.beyonduxdesign.com/
• https://www.dive.club/
• https://danmall.com/

Creating your first design portfolio?

You can use Framer to do that, it can be a great choice:

• It’s easy to set up and start with.
• Is very similar to Figma, so there is a minimal learning curve.
• And there are a ton of free templates & resources to get you started.

I made my portfolio on Framer. You can check it out here.

If you’re ready, use my link to get started. It’s a referral link. So if you use that, I might make some quick bucks. No extra charges from you. And if you use the promo code: partner25proyearly for the yearly subscription. You get 3 free months on the Pro annual subscription.

PM’s responsibilities in low-maturity software team👨🏻‍🏭 was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey Everyone 👋🏻

How’s it going? Following my learning on low-maturity software teams. We discussed already what’s meant by a low-maturity team. What happens in there, and how do things get affected? We touch points on it from a general perspective. But today we’re going to expand more on the topic and highlight it from a UX designer’s perspective. And in case you haven’t read the last story. You can do that here.

→ A general understanding

→ A designer’s battle 👈🏻

→ A PM’s responsibilities

In a low-maturity software team, there is no real UX process. There is no discovery and research. There are no metrics to check results. And when all these steps do not happen. It makes the job of a UX designer most difficult. We do not have anything to go on with. And this leads to building a crappy software with a frustrated team.

As we discussed in the last story. In low maturity software team. There are no clear:

• Goals & Objectives
• Roadmaps
• Clear communication
• Strategic Vision
• Metric for success

When all this happens. And there are no clear expectations. We have a divergent product vision and design experience. UX is not present in meetings. Designs are not followed. This gives rise to some common issues for us UX designers working in such a team:

• There are no defined processes. Changes happen without research.
• There is a little culture of collaboration with the design team.
• There is an overemphasis on speed and no usability tests.
• Technical limitations override the UX.
• The focus is on what’s easier to implement than what’s better for users.
• Prototypes get ignored and designs are not followed.
• Over-emphasis on handoffs and features rather than user needs.
• There is a limited understanding of UX across the team.

As I understand, the value of UX is proportional to the value of good engineering. And what I mean by this is that good collaboration yields great work. And how can we achieve this? When product teams and engineering teams work together in sync. They need to have the same operational maturity. This helps with gathering requirements. These requirements are then to build and execute ideas.

So now we know what’s it like being a designer in a low-maturity software team. How we get affected and what the value of UX and engineering is. Let’s see how we can navigate in such an environment.

How to work in a low operational maturity team as a UX designer

Reflecting on what we highlighted in the earlier story on low software maturity teams. You can refer to it here.

“Work with what we have”

As a designer, it’s not our job to fix everything, especially not the team and the company. Our job is to advocate the best we can for the users and align the team with the business. It’s not our focus to change the level of maturity but to figure out how to work with such a team.

Another interesting thing, I heard in the “CHOAS to CLARITY ” series was by Jared Spool, you can check him out here. He’s a veteran UX designer. He says that “product teams should worry about the features an app can do. As UX designers, our focus is not on features but on the outcome that a user can achieve with those features.”

It’s a simple one, but quite meaningful. Right?

Discovery is one of the most important aspects of the product development life cycle. It’s unbiased. And designers should be part of this step. They help to bring clarity to the user’s perspective. Add value to the roadmap planning. Align the team with product vision and goals.

So as UX designers, we have to work together with the product teams. To understand the users, their needs, and what they want to achieve.

And doing all this in a low-maturity team is quite hard. So to work in such a team. We should have clear communication, and be proactive in collaborating. Help the team in understanding the user goals. Find allies and help them to help yourself.

Inspire people to want to do better

As designers, we have to build bridges and not walls. Making allies with the PM and leadership. And help them understand the UX perspective that can help them towards realistic timelines and deliverables.

A concept that I liked from the series was that we have to “Think Globally, Act Locally”. This means that we always look for a broader perspective. And when it comes to action, take to the immediate problem with the big picture in mind. And this is so important. Because, in the grand scheme of product life, everything connects to one thing or another. Not thinking about the ripples and going on can lead to a cascade of failures. And that’s not bad for the user experience but for our work and the engineering teams. It’s better to have a few updates than to have the whole experience redesigned.

Design is more than the fancy UIs despite the stereotype. As designers, we’re problem solvers at the root. To have an empty canvas and paint it with a user’s journey is quite something. It takes time, thought, support, and focus. We should be part of all the sprint planning. Share the value of our work and how it can help others. To have fewer changes in development. We should have frequent design sessions to get feedback. And iterate on what’s best for the user and then the business. Design bears a low creation cost as compared to development. So we enable and help our team to leverage this superpower as much as they can.

Engineers are not all anti-social, despite it being the stereotype. We are smart, brilliant people. And like everybody we care about the work we do. Here’s an interesting one as well. “Research trips or stakeholder sessions should have at least one engineer take part in them. They not only provide technical insights but also understand the users. And having reflected on this. It’s a solid insight. It makes a lot of sense. Because when new requirements are being thrown or added to the conversations. Having a direct insight into how it could impact. Not only the previous work but have a rough idea of what the new effort could look like. Makes the stakeholders or the key people value impacts, time, efforts, and resources.

And continuing from the previous insight. “Collaborating early and often” with the engineering teams. Not only helps to save time but also to get to the right thing. It also helps the engineers build a good solution. Because they already knew how we envisioned solving the problem.

We can also add value to our team by documenting the UX process and the design process. Creating a consistent and cohesive design system. Having a clear tone, usage, and proper documentation is very helpful. And it should be a practice if the team can support it. It adds pace and productivity to the team’s workflow.

Attend and be part of all the scrum meetings. If you have time, I’d suggest being part of the engineering meetings as well. My take is that sometimes engineers overcomplicate stuff. And guys before you point out that’s not true, I was an engineer in a past life so I know. It happens. But in reality. Things are quite simple. And we as the designer can provide clarity that can help them overcome their blockers. And sometimes it’s a small change in design that helps them out. Of course, we never compromise on the user experience. But if the change does not have a greater impact it’s good to make the change and help the team out. This builds trust, understanding, and synergy in the team.

As designers, we are responsible for the users. But we should also try to manage stakeholders’ influence as well. And when the stakeholder’s influence dictates, we have to always advocate for the users. There are levels of stakeholder maturity as well. And that’s another learning. But as a designer, we need to work with constraints of low stakeholder maturity and do great work. An insight here is. The stakeholders bring great perspective to the team as well. They know about the business more than us. And that makes their suggestions quite valuable. So find a way to work with them by understanding their language that is the business.

So while we know about low-maturity software teams, how UX comes into play, and how as a designer we can work in such a team. But it’s not the case that low UX maturity is always bad. As I understand, It does have an impact on product development. And things are not ideal. But that does not mean that people do not want to do good work. It just makes the job harder.

But with an assumed positive intent, and good empathy for the team we can improve the way we work with our core team. When we understand what they like, we can get them to do what we like. Build relationships with our teams. Find our allies. Educate the team on UX value and be open to trying different things. Improve our work one step at a time. Involve the team in UX activities. So that they see the value. And most importantly have patience, it’s a long game. Change happens with time.

I hope you liked the story and my learning. If it was helpful, I’d appreciate you share it with others who can learn from it. Thanks for reading till the end. 🙇🏻‍♂️

More learnings are on their way! 🚀

Want to level up your design knowledge?

Some resources for you to peak at. They will surely help you out in your UX journey. They focus on more than just design:

• https://www.instagram.com/ux.aneta/
• https://www.beyonduxdesign.com/
• https://www.dive.club/
• https://danmall.com/

Creating your first design portfolio?

You can use Framer to do that, it can be a great choice:

• It’s easy to set up and start with.
• Is very similar to Figma, so there is a minimal learning curve.
• And there are a ton of free templates & resources to get you started.

I made my portfolio on Framer. You can check it out here.

If you’re ready, use my link to get started. It’s a referral link. So if you use that. I might make some quick bucks. No extra charges from you. And if you use the promo code: partner25proyearly for the yearly subscription. You get 3 free months on the Pro annual subscription.

A UX designer in a low-maturity software team ⚔ was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey Everyone 👋🏻

How’s it going? Abdullah here, a product designer with an engineering background. Currently treading the slippery slopes of product management. I am writing after some time. And It’s great to write about another learning.

Some time ago, I was curious to know more about UX maturity. The idea came from an interesting talk I took by Jonathan McFadden at Disco Conf. The talk was about how to be inflexible as a designer. And while it is an interesting take on “why” we need to be inflexible as a designer. And in what situation? Do we have to be one? Early on, I had a wrong understanding of the talk. But it was about what to do as a designer when faced with adversity. The key insight from the talk was that as a designer, we should always:

• Have a personal risk analysis.
• Be strategic and tactful.
• Accept what we cannot control.
• Disengage when necessary.

But as I dove more deeply into this, I got steered in the right direction by the one and only Jeremy Miller! the creator of the Beyond UX design podcast. It is one of the best out there. And that’s maybe my bias here. But Jeremy has been super helpful the past couple of months. His experiences have helped me build my understanding of a lot of stuff on design & beyond. If you already haven’t checked out his podcast. You’re missing a lot. Be sure to give it a look now. Shoutout to Jeremy here! Thanks for making the Beyond UX design podcast and being an awesome silent mentor.

So in one of the weekly LinkedIn threads. Jeremy pointed out that when decisions from above in an organization are not the right ones, it is about having low maturity. And being adaptable and flexible are two essential skills a designer can have. And it’s not about rolling over and building the wrong thing. But to build great software.

And to my surprise, he already had a podcast series. Where he talks about low-maturity teams. “From CHAOS to CLARITY” → sounds a bit too much right, but believe me the name does justice with the insights. While I was listening to it I was like oh, this is what’s happening, okay I have done this and it works, and many more Aha moments. If you want to learn more by yourself, take note of your “Aha moments” You can check out the series here.

Before we get into my learnings from the series and understanding the whole topic. I thought I’d break it down so that it’s easier to digest. And it’s for me. So when I reflect on it later, I can do so with ease. Hoping the breakdown helps you too. There were lots of things in there.

But I wanted to understand it from different perspectives. So I divided the findings and my thoughts into three parts, understanding it from:

→ A general understanding 👈🏻

→ A designer’s battle

→ A PM’s responsibilities

So let’s start with understanding what is low maturity. And to do that let’s understand another term first that I found the most appropriate. “Software Maturity”. I liked the term, and like you, I thought it had to do with software right? But it’s not with software with a context here it’s about the software maturity of teams.

We can say that the PM/UX/design/engineering team’s maturities are a subset of this big term. So let’s understand it.

Software maturity is how a team operates together as a whole. It’s how they collaborate, understand, and build software. As simple as that. So what’s the crack here?

Teams with low software maturity tend to be pretty dysfunctional. And the chance of growth is low in such a place. And most of the time we don’t know if we’re doing things right.

People in low software maturity teams:

• Have short-term vision
• Are super reactive
• Build silos
• Have few super-heroes

All these characteristics can lead to:

• Burnout
• Loss of interest in work
• Low growth

Now let’s pivot to “Operational Maturity” which is how things work. It relates to the software maturity. It includes:

• Day-to-day operations
• Team allocation
• Team leaders → PMs and Managers
• Team players → Designers, Engineering, Product

And why this was important? because in low software maturity teams, none of these things are present. The team’s functions as a whole are not defined. And that impacts how they work and reach their goals. In a low operational maturity team, there are no clear:

• Goals & Objectives
• Roadmaps
• Clear communication
• Strategic Vision
• Metric for success

And what happens is that when there are no clear goals and vision. There is chaos. Management says yes to all the stakeholder needs. And this leads to a dysfunctional product vision. This affects all the teams from designers to engineers. Believe me when I say it’s real chaos and it takes a lot of time and effort to make sense of things.

Contrary to this is high operational maturity, and while it’s not the focus here let’s talk about it. In an operational software team, we have realistic:

• Deadlines
• Milestones
• Research

A team like this operates like a well-oiled machine.

Understanding of the concept of software team’s maturity. We have discussed low maturity and connected that with a team’s operational maturity. Compared to what’s it like to be in a high operational team.

Let's discuss strategies for collaborating effectively with a software team that has a low level of maturity.

“Work with what we have”

It’s not our responsibility to change the whole company/org or a team. Especially if we’re at a junior level. And even as seniors we can’t have that big of an impact. In a small company, we can change things with time but in a larger org, it’s not possible.

So what to do? Work with the team you have and see how you can improve things together.

To quote the BUX creator here “And while it may sound odd, it’s quite alright to get the hell out of there. If you can afford to quit then quit. Don’t ruin your mental health trying to make an impossible situation.” For all the suckers like me, emphasis on if you can, don’t quit. In today’s world, everybody has some sort of responsibility. Some have more than one. So think it through. And this I think could be another story → Extent of planning ahead, for life, a job, or anything. Going to write about it soon.

Coming back to how to work well in a low-maturity software team. We have to understand that everybody wants to do great work. Understand your team, and who you work well with and start from there. Foster relationships and build trust. See how you can help each other out. Doing this can inspire other teammates around you to do the same. This can help bring a change in the way things should be. And like everything, nothing is a sure shot. There still be people that are going to be a pain for you.

Communication plays a critical role here, as it does everywhere. But in a low-maturity team if the communication is clear and done. We can salvage a lot. If something is missing we should not wait for others to tell us. We have to put in the effort and connect the dots. Why is this important? because low maturity does not mean that the team can’t operate well it’s that they do not know how to. But with good communication, we can work on the “how” together and find a system that works.

Plugging in one of the key resonating points from the series. The concept of Practice followership. It’s the idea, that we do not follow everybody but a particular leader. That tries to take initiative, support, and raise concerns when needed. And this way we emulate a behavior that can be good for us and help people around us. If you’re interested, the idea is from Dr. David Lightner, you can check him out on LinkedIn.

Asking the right way. Is also one way that helps to navigate in a low-maturity team. But the trick here is to expect things, and not ask. Phrase it in a way that you expect that. What happens here is that it brings clarity that to go from A to C, we need to have B. Talking about it in a way that makes it normal is the right way to ask.

And a very obvious one, showing more is always better than telling more. When we have tangible things to present, we have better conversations. They lead to insights based on actual work rather than talking in the air on the fly.

Even with all this understanding. And ways to work in a low-maturity software team. Things might only sometimes go your way. So we have to remember that it’s a long game and change takes time. We can try to do our best and work with what we have. And most importantly build “great relationships to build great software”.

I hope you liked the story and my learning. If it was helpful, I’d appreciate you share it with others who can learn from it. Thanks for reading till the end. 🙇🏻‍♂️

More learnings are on their way! 🚀

Want to level up your design knowledge?

Some resources for you to peak at. They will surely help you out in your UX journey. They focus on more than just design:

• https://www.beyonduxdesign.com/
• https://www.dive.club/
• https://danmall.com/

Creating your first design portfolio?

You can use Framer to do that, it can be a great choice:

• It’s easy to set up and start with.
• Is very similar to Figma, so there is a minimal learning curve.
• And there are a ton of free templates & resources to get you started.

I made my portfolio on Framer. You can check it out here.

If you’re ready, use my link to get started. It’s a referral link. So if you use that. I might make some quick bucks. No extra charges from you. And if you use the promo code: partner25proyearly for the yearly subscription. You get 3 free months on the Pro annual subscription.

Low-Maturity Software Teams: Understanding & Survival 🧗🏻‍♂️ was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there! 👋🏻

Ever felt like you’re swimming in a sea of information but struggling to make sense of it all? I know the feeling. In a world where we’re bombarded with content from every direction. Maximizing our learning and problem-solving abilities has become more critical than ever.

Whether you’re juggling a hectic work schedule, navigating the challenges of college life, or trying to level up your learning game.

This article might help. It all began with me trying to find a solution to my high-context switching in my job. Also, how I can maximize by learning. It led me to a course by Barbara Oakley & Dr. Terrence Joseph Sejnowski on Coursera. It helped me to learn how to learn, techniques that help, and habits to overcome.

So let’s begin with thinking.

Thinking

Is the process of considering or reasoning about something. Seems simple enough and we all know this but did you know there are types of thinking?

Yes, like you, I was thinking about it for a while. But as it turns out we have two major modes of thinking. They intertwine with one another. They help us to process information and plan thoughts.

1. Focused Mode
2. Diffused Mode

Focused mode is when we have an organized thinking style. It is stimulating, structured, and mannered.

For example, focused mode is like when we’re doing a jigsaw puzzle, and we organize the pieces by color and shape. We carefully fit each piece together, just like a librarian neatly arranging books in a library.

Diffused mode is when we have a relaxed thinking style. It is broader and provides a big-picture perspective.

For example, In diffused mode, our mind is like a calm wanderer in a park, appreciating the whole scene without getting caught up in small details.

In a single instance, we can be in either of the thinking modes. We can’t be in both. When we are in the diffused mode we are in auto-brainstorming mode and we have thoughts all over the place. This allows us to get as much thought on something as we want. After switching to the focused mode we can take all our ideas to make sense of something.

Quick Brain Facts

“The brain consumes about 10 times more energy by weight than the rest of the body.” ~ Whoa that’s alot I need to eat more.

“The most complex thing known in the universe.” ~ 🎯

So we have heard the phrase that practice makes perfect. In the case of the thinking, it’s like practice makes permanent. The more abstract something is more the time we need to practice and master it.

For us to learn new things we need to build strong neural structures. And how we can build these? We need to create a focused learning pattern. They help us to be concise, organized, structured, and refined. Cramming all at once helps in the short term and what we keep is scattering, formulating, and raw.

For example, the Pomodoro technique can help us to create a focused learning pattern. It is a time management method based on 25-minute stretches of focused work broken by five-minute breaks.

1. Set a goal; define a learning goal
2. Choose a time interval; 25 minutes
3. Work Intensely; During each Pomodoro interval, concentrate solely on your learning task. Avoiding all distractions.
4. Take short breaks; Take a 5-minute break. Relax, stretch, and recharge.
5. Repeat & Review; After completing a Pomodoro, start a new one. Also, review what you’ve learned.
6. Stay Consistent; Consistency is key to creating a focused learning pattern. Stick to your Pomodoro sessions regularly to build a habit.

By using the Pomodoro technique, you break your study time into manageable chunks. This keeps you concentrated, avoids burnout, and helps you remember the important facts. It’s like running short sprints to reach your learning goal, with mini-breaks to catch your breath along the way.

Now we know about types of thinking. And how we can build strong neural structures to learn new things by using techniques such as Pomodoro. Let’s talk about one of the key ways our brain stores and learns something ~ Chunking

Chunking

It is the vital essence of how we grasp and master key ideas. It is a concept tied to our memory. And we have two types of memories.

1. Long-term memory — LTM
2. Short-term memory — STM

Our long-term memory is strong and can store more than a billion items. Remember when someone talks about your childhood? And you remember what they are talking about? Yes, that’s your brain getting information from our LTM.

We have a working memory and we call it our short-term memory. It is immediate and concise. It can hold information for a short span.

So in short we can consider our working memory to be like an efficient mental blackboard. Where we form chunks and move the information into the long-term memory which is like a storage warehouse.

Chunks are the mental leap that lets us unite bits of information together. They create a neural loop that creates a memory trace. They help the brain to learn more. We plan chunks around mental ideas by focusing attention and practicing understanding.

“Normal people can hold 4 chucks in the brain at a single time and geniuses can hold up to 7”

Not that big of a difference right? But it is. It means having to have 7 active things in the working memory at a time. And who would not want to have more information in their arsenal at an instance, I would. But don’t worry I am not a genius and am still doing pretty fine.

For example, think of a jigsaw puzzle from before where we have many pieces that make up a picture. Chunks are like putting those puzzle pieces together to form a complete image. When we group related information into chunks, it’s easier for our brain to remember and understand, like connecting the puzzle pieces to see the bigger picture.

Context is one of the most important aspects of learning. With a clear context and undivided attention. We can create chunks that create new neural networks. These new neural networks connect with the old ones. Then we have new memory traces that link to other memory traces.

Understanding a problem solution does not create a chunk that we can recall later. We often fall trapped in believing that we saw it and now we can do it.

Seeing + understanding ≠ You can do it.

To gain knowledge and build expertise, we need to have a mental library of chunks.

We need to create several chunks. They hold valuable bits that can pieced together in creative ways. When we group one chunk with related chunks we call this process a Transfer.

Training our brains to recognize chunks helps us understand specific concepts. But also different types and classes of concepts. The process leads to auto-solving and creates a pattern that enhances problem-solving.

Procrastination

Procrastination is a form of mental relaxation. It happens when we can’t do anything and shift our focus to something that we can do and bring us relief. It’s the brain’s coping mechanism for pain. It shares features with addiction.

It is a keystone bad habit. And happens when we are unhappy. Our brain deals with it by sending us to a happy place which is a momentary relief.

For example, We have a big project to complete, but it feels overwhelming, and we start avoiding it by checking our social media or watching funny videos. That’s procrastination — our brain’s way of seeking relief from the stress of the task.

How to deal with procrastination?

“We need to master our habits and not let our habits be our master”

So we now know what is chucking and how it helps us to learn new things. But chunking is a habit. And habits can be both good and bad for us.

While performing a habit our brain launches into a preprogrammed mode. Acting as an “energy saver” and allowing us to free our minds for other types of activities. These habitual actions are comically referred to as “zombie modes”.

A habit is formed by sequences of habit loops. It has four parts.

1. Cue ~ the trigger that launches you into zombie mode. It could be a text reminder, an item on a “to-do” list, or the act of cleaning up your desk.
2. The Routine ~ is the habitual response your mind is falling into when it receives the cue. It is your zombie mode. Zombie responses can be useful, harmless, or destructive. Thus creating good or bad habits.
3. The Reward ~ the pleasure that rewards us as habits develop and continue. It’s the emotional payoff for the “neurological cravings” while following a routine. It could be a sense of satisfaction or an indulgence, such as a piece of chocolate.
4. Belief ~ the underlying, subconscious thinking that closes the habit loop. And the reason why habits are so powerful. Negative thinking such as: “I will never be able to do this” or “There is way too much on my plate”. Should be replaced with positive, affirmative statements such as: “I can do it” or “I am the master of my ship”.

The best way to tackle procrastination is to look for a cue that triggers the habit and work on that. The key to rewiring our brain is to have a plan, to develop a new ritual. This helps us to overcome neurological cravings with a reward. And to have a positive mental attitude, a belief that our new plan is going to work.

We need to understand the difference between process and product. The process is the flow of time whereas a product is like a result or an outcome. We should always focus on the process.

The power of zombie mode is that it’s a habit that helps us avoid procrastination while minimizing willpower.

We don’t have to fullscale change of habits but we need to practice how we react to the cue. This way we develop new habits and override the bad parts of old ones. Belief is fundamental in changing our habits. Another way to fight procrastination is to be around friends and like-minded people. Create a weekly to-do list and break it down into a daily list. Switching between focused and diffused modes of thinking.

Mental Roadblocks

A mental roadblock is a psychological obstacle or limiting mindset. It prevents us from completing important tasks and achieving success. Mental blocks are invisible barriers standing in the way of our productivity.

There are a lot of mental roadblocks, let’s talk about a few of them here.

Einstellung is mindset. It is a sort of mental roadblock that helps us think that the solution we have is already the best.

For example, Imagine we always tie our shoes with a double knot, even when a single knot would do, because it’s become a habit. This is like Einstellung, where we stick to a familiar way of doing things, thinking it’s the best, even if there’s a simpler method. This example was a “wow” for me, I never thought of it like this!

Overlearning is practicing something over and over again during the same learning session. It happens when you keep repeating a skill long after you’ve mastered it — that is, recalling it. It can lead to automaticity which is very helpful. But can be a waste of a lot of time as well.

For example, It’s like practicing shooting basketball hoops even after we can score perfectly every time. Or like overeating at a buffet, thinking more food will make us healthier.

The illusion of competence is when we know more than we do. Looking at a solution and thinking that we got it is one of the most common illusions of competence.

For example, Imagine we watch a cooking show and feel confident we can recreate a fancy dish, but when we try, it turns into a mess. That’s the illusion of competence, where you think you understand something just by looking at it, but real understanding requires practice and hands-on experience.

How to override mental roadblocks?

There are a lot of ways to overcome mental roadblocks let talk about two of them here.

Deliberate practice refers to a special practice that is purposeful and systematic. While regular practice might include mindless repetitions. Deliberate practice requires focused attention. And is conducted with the specific goal of improving performance.

For example, Imagine a pianist who spends hours practicing a challenging piece, focusing on specific parts that are tricky, rather than just playing through the whole song. This is deliberate practice, where we purposefully work on improving specific skills to become better at the overall task.

Interleaving is another great way to learn. It is when we juggle problems/situations that need different techniques/strategies. It is a technique that involves mixing different forms of practice, to help learning.

For example, Think of a student who alternates between practicing math problems, science questions, and history facts during study sessions, rather than sticking to one subject at a time. Interleaving is like mixing different topics or skills in your practice to help you learn and remember them more effectively.

How we can learn better?

To move things from our working memory to long-term memory we need to train our habits to help our learning. To have an idea move from Short Term Memory to Long Term Memory. It should be memorable.

Learn using metaphors and analogies. We can take help from visual and auditory hooks to learn more. Associating something with a visual cue can help us recall and keep that information. Practicing interleaving is the key to learning better.

Spaced Repetition

It is one of the ways that helps the brain to learn better. Rather than revising something again and again over the same session. We can recall the information over spaced intervals.

The idea behind spaced repetition is that we allow your brain to forget some of the information. This ensures that the active recall process is mentally taxing. The psychology suggests that the harder your brain has to work to retrieve information. The more likely that that information will be encoded.

For example, It’s like reviewing new words in a language over several days, with each review spaced apart, instead of cramming them all at once.

Learn by doing

Learning by doing is an active learning method. Based on the experience of assimilating concepts through actions. It also encourages us to learn from our mistakes. And to conclude after analyzing the practice in a clear spirit of continuous improvement. We always learn by doing and this should be a belief.

For example, Think of riding a bicycle — we learn best by actually getting on the bike, balancing, pedaling, and experiencing how it works. Learning by doing is about gaining knowledge and skills through hands-on practice and real-life experience.

Active Engagement vs. Passive Listening

Active Engagement is participating in a learning experience. Such as discussions or problem-solving, to deepen understanding. At the same time, Passive Listening is receiving information without active involvement.

We learn more through Active Engagement. Because it encourages critical thinking, application of knowledge, and deeper retention. Whereas Passive Listening often leads to superficial understanding and limited retention.

Our reflective mode enables us to do our best work.

Environment

Enriched and nourishing environments improve our learning. They stimulate our senses. By reducing stress, and fostering active engagement, social interaction, and emotional support. They create an optimal backdrop for effective knowledge acquisition and retention.

The more enriched and nourishing an environment. The more new neurons are formed. And having more of them is always better.

Exercise

Exercise enhances learning by increasing blood flow to the brain. It releases neurotransmitters that improve mood and motivation. That helps to reduce stress, promote neuroplasticity, and improve memory and cognitive skills. Regular physical activity can benefit cognitive function.

Memory Palace

The Memory Palace technique aids memory by associating information with familiar locations. Leveraging spatial organization, vivid visualization, and strong mental associations. It enables us to recall a wide range of information. This happens with the help of structured, personalized mental maps.

Now I can be Sherlock as well!

What are neuromodulators and how do they control us?

Neuromodulators are chemicals that influence our neurons to respond. There are several but let’s talk about a few that affect us the most.

Acetylcholine

Acetylcholine is crucial for memory and learning. It facilitates communication between nerve cells. And supports the formation of new memories and cognitive functions.

Serotonin

Serotonin influences mood and emotional well-being. Its balanced levels mean that we have a positive, focused mindset. Conducive to effective learning.

Dopamine

Dopamine plays a key role in motivation and reward. And its release during learning can enhance engagement and reinforce the learning process.

You must have heard about them in some way or other but now you know how they impact our learning.

Sleep and Its Importance

Sleep isn’t about resting. It’s a time when our brain does some important work that helps us learn and remember things better. One crucial job it does during sleep is cleaning up the mess in your brain. When we’re awake, our brain produces waste, like toxins. Sleep is like a cleaning crew that comes in to sweep away this waste, keeping your brain healthy.

Tidy up Ideas/Concept

When we sleep, our brain also sorts through all the stuff we learn during the day. It’s like organizing our thoughts and putting them in the right place. It keeps the important stuff and gets rid of the less important stuff. This organizing process is super important for learning and remembering things.

Solidifies Memories

While we slumber, our brain transitions to the diffused mode. Dreams, in particular, play a fascinating role in this process.

When we dream about what we’ve been learning. It’s like our brain is practicing and getting better at it while we sleep. So, it’s essential to get a good night’s sleep to help our brain be a super learner!

Conclusion

Learning how to learn teaches us that we need to get involved to understand things better. It’s not about listening; it’s about thinking and trying to make sense of what we learn.

Having a positive attitude, like “Change how you think to change your life,” helps a lot. It means seeing problems as chances to grow.

But the most important thing to remember is not to trick ourselves. As Richard Feynman said, “The first principle is not to fool yourself — and you are the easiest person to fool.” Sometimes, we make things seem easier than they are by fooling ourselves.

Starting with a tough challenge can help us learn better because it makes our brains work harder.

Being disciplined means sticking to a plan and not giving up. It is super important for learning. If we keep practicing and don’t give up, we can get better at anything. So, remember these ideas as you learn new things in life, and you’ll be on the right track!

Note: This is a reflective summarization of the content of the course. I created the article from my notes to help organize and reinforce the concepts. While it has been a truly great learning experience for me. I am hoping that it will be for others as well.

I hope you liked the article, more are on their way! 🚀

Seems simple enough? Right to be able to sort the data, what comes to mind to have an intuitive experience? Drag and drop? But what if there are 100s and thousands of items to arrange? Would now the drag-and-drop experience be the optimal and the best experience?

Value of Understanding 🧠

So rather than working on the feature request, we needed clarity on the problem. We asked the stakeholders some simple questions such as:

• Why is there a need for such an experience?
• What does the business achieve with this specific feature?

These questions enlightened us to understand the need and goal for this request. So the idea was that as the app would grow, some content may be preferred over others. One item might be more viewed, and accessed than others. So we needed to be able to show the best content first in our app and then the rest.

Now to the next questions.

• What can be the best content? All the 1000 items, 100 items?
• And would these changes over time?

Not all the content is the best and yes things change over time.

So we had an idea to define a limit to the number of items that could be the best in each section.

Power of constraints ⛓

So building on the idea, we zoomed out and then zoomed back in. We needed to present the best content to our users first and then all the others. Since we have 2 device types, mobile, and tablet we started to explore how many items could fit the screen. We wanted the users to see the best things with the least number of scroll actions.

The Challenge

The app will use analytics to identify users’ favorite content. So we need to best serve the users without them knowing. And also since our users are going pre-schoolers, we needed to provide them with the best content on first viewing.

Content View

After some research and design experimentation. We determined the optimal amount of content for the screen view. The max items in the screen on the list layout were going to be 3 items, and for the tablet 6 items.

The reason for diving deep into this was that on the first two scrolls, we could show the users the best content. Since we have a very young audience their attention span and usability of the app are going to be very limited. So we need to serve them with the best content with the least amount of interaction.

Working with the constraints and having clarity on the problem. We brainstormed some ideas and came up with a solution. The solution was that were going to have a list of favorite items and we can sort and rearrange from that list only. And these favorites will be present first in the app in the respective list and then the others.

We presented our idea to the stakeholder, explaining our understanding of the problem, and the way we think we should best serve our users. We discussed the solution and the optimal number of items that could help with the business need as well.

Binding constraints to the problem to build the experience ⚒

Understanding the problem, and evaluating constraints. We started to work on designing the experience. Our goal was to make the experience intuitive and user-friendly.

We designed an experience where we have a list of 15 favorite items from each content section. The limit was optimal for us. It fulfilled the business need and also helped with serving a good experience. In the content view of large devices, we could see the whole list and on smaller screens, we could see most items. The admin has the capability of swapping indexes to sort the list. Dragging and dropping to rearrange items was also present and was more favorable. The limit to the number of items helped with keeping the list minimal. The admin can perform any action without compromising on the experience. No need to worry about pagination and sorting all the content.

The flow in the experience

Favorite items -> Go to favorites -> Sort through the favorites -> Save -> See the sorted list in the app!

Conclusion

This feature request highlighted the value of understanding the problem. The power constraints can have over a design solution.

Stakeholder discussions revealed the true essence of the request. Which was to present the most relevant content to users.

Our solution involved focusing on 15 favorite items per section. We curated a list, providing a mechanism to sort through the specific content.

We learned that intuitive design requires clear problem comprehension and thoughtful constraints. The resulting experience serves both business goals and user needs.

I hope you liked the story, more are on their way! 🚀

How would you have solved this? Let me know in the comments!

The value of understanding and the power of constraints in design! was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unleashing the Potential of Developer Experience (DX) as a UX Designer 💡

As a UX designer, I've always been driven by the desire to create exceptional user experiences. Recently, I stumbled upon a hidden gem that holds immense power in shaping not only the products I design but also the efficiency and collaboration within our team: developer experience (DX). Recognizing the significance of a good developer experience, I embarked on a journey to understand how it can propel our team's success and add value to our overall product management efforts. Let's dive into the transformative potential of DX together!

Measures for a Stellar Developer Experience: Illuminating the Path 🌟

To harness the true potential of DX, I discovered several key measures that can elevate collaboration and efficiency within our team:

1. Design Systems: Fostering Collaboration through Consistency🌈

Implementing a robust design system lays the foundation for seamless collaboration between designers and developers. By providing a centralized library of UI components, design patterns, and guidelines, we cultivate a shared understanding and language. This consistency not only streamlines workflows but also fosters collaboration and empowers developers to bring our design vision to life with precision.

2. Clear and Detailed Design Documentation: Bridging the Gap 📚

Design documentation serves as the bridge that connects our design vision with the developer's implementation. By crafting clear and detailed specifications, annotations, and design assets, we provide developers with the necessary guidance and context. This ensures that our design intent is accurately translated into code, minimizing misinterpretations and facilitating a seamless handoff.

3. Iterative Feedback Loops: Nurturing Growth and Innovation 🔁

Embracing iterative feedback loops is the secret sauce for continuous improvement. By creating an environment that encourages open communication and fosters collaboration, we unlock the full potential of our team. Regular design reviews and iterations provide opportunities for designers and developers to exchange ideas, tackle challenges together, and drive innovation, resulting in a product that surpasses expectations.

Facilitating Developer Experience: The UX Designer’s Role as a Catalyst 🎨

As a UX designer, I recognized my pivotal role in facilitating a good developer experience, thereby enhancing team collaboration and efficiency. Here's how I embraced this role:

1. Collaboration from Inception: An Inclusive Approach 🤝

From the very beginning of a project, I embraced an inclusive approach, involving developers in the design process. By seeking their valuable insights and technical expertise, we established a collaborative mindset and nurtured shared ownership of the product. This inclusive approach became the breeding ground for effective problem-solving and innovative solutions.

2. Clear Design Handoff: Empowering Developers for Success 📤

A seamless transition from design to development is crucial for a good developer experience. I made it a priority to provide a clear and structured design handoff, ensuring that developers have the necessary resources and context to bring our design vision to life. Annotated design files, style guides, and design specs became the backbone of a smooth collaboration between designers and developers.

3. Cross-functional Communication: Breaking Down Silos 📣

Breaking down silos and fostering cross-functional communication became a cornerstone of our team's success. Regular meetings and informal discussions brought designers and developers together, encouraging the exchange of ideas, perspectives, and insights. This collaborative environment built empathy, trust, and a shared sense of purpose, leading to seamless collaboration and efficient problem-solving.

The Benefits of Good DX: Supercharging Collaboration and Workflow 🚀

Embracing a good developer experience delivered a plethora of benefits for our team and the products we created:

1. Enhanced Collaboration: Orchestrating a Symphony of Skills 🎵

A good developer experience transformed our team into a harmonious symphony. The collaborative mindset and shared understanding between designers and developers created an environment where ideas flowed freely. By leveraging each other's skills and expertise, we unlocked new dimensions of collaboration, resulting in innovative solutions and optimized workflows.

2. Accelerated Efficiency: Propelling Toward Success⚡️

Efficiency became our driving force. With a solid DX foundation in place, our developers were equipped to translate the design into code swiftly and accurately. The reduced back-and-forth, increased clarity, and streamlined processes elevated our team's velocity, allowing us to deliver high-quality products faster, without compromising on user experience.

3. Improved Product Quality: A Refined and Polished Experience ✨

A good developer experience ensured that our design vision was implemented with precision and consistency. The seamless integration of design and development resulted in a product of exceptional quality. The attention to detail and cohesive user experience garnered positive feedback from users and contributed to our product's success in the market.

4. Empowered Innovation: Igniting Creativity💡

When designers and developers collaborate effectively, innovation flourishes. By fostering a good developer experience, we created an environment where creativity and technical expertise converged. This synergy allowed us to explore new ideas, push boundaries, and deliver unique and delightful experiences to our users, setting our product apart from the competition.

In conclusion, as a UX designer, I have witnessed firsthand the transformative power of a good developer experience. By implementing measures such as design systems, clear documentation, and iterative feedback loops, and by embracing my role as a facilitator, I have seen our team’s collaboration soar to new heights. The benefits extend far beyond efficiency and workflow; they manifest in the quality of our products and the satisfaction of our users. So, let us continue to prioritize developer experience and unlock the full potential of our team and the products we create! 💫

I hope you liked the story, more on their way! 🚀