A UX designer in a low-maturity software team ⚔
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 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.
