How does one approach leading a team in UX with no goals or roadmaps?



I’ve joined a company at the start of April. I am appointed as the Lead UX designer and I’ve been given a lot of information regarding the company’s goals and future plans, just before I started.

When I started, I realized that the team is a little different than what I was told. We are following the KanBan approach so we have no sprints. This is still fine but the problem comes in with our development cycle. We have no deadlines, no clear goals, no clear mission as to what we are trying to achieve.

No I’m caught up having to work on improvements or redesigning parts of a system where there is no measurable outcome or shared understanding as to what we are solving or what we want to achieve. There’s no real brainstorming any issue and when we meet up, we don’t document any action points or action plans.

The fact that there’s no common goal or expectancy, delivering the correct product seems almost impossible. I’m working with 2 analysts and mainly the head of development and everyone seems to have a different understanding of where we are headed. I followed a lot of Joe Natoli’s work and I’ve been trying to get that shared understanding and agreement between stakeholders but when I ask these questions, the answer is usually: “it’s complicated”. When it comes to UCD, it seems like the managers are more vigilant in having their needs met instead of the needs/frustrations of the users.

So at this point in time, I have to lead UX with very little input/collaboration from team members and without any clear goal or roadmap.

Has anyone encountered anything similar to this? I would LOVE some thoughts regarding this.


Argh, sounds frustrating.

First up, let’s call in @joenatoli :wink:

Secondly, have you addressed your concerns with anyone in the organisation? I’d set a clear precedent of speaking up in a constructive way from the very beginning.


Hi @brendin — I do have some thoughts on this but am very pressed for time right now, so I’ll give you my quick 2 cents.

The key thing that jumps out at me is the fact that your organization is using Kanban as a product development approach — which it is not and was never intended to be. Its creator has been speaking loudly about this since 2005, but organizations aren’t listening.

There are inherent issues in adopting this to design and build software because Kanban was developed for an assembly-line, manufacturing environment. It’s a well-defined process where the inputs and outputs to that process are (1) known and (2) repeatable. Like a manufacturing assembly line. Design and development, however, are filled the the brim with unknowns. From requirements all the way to final QA testing, you’re uncovering and validating, iterating and improving, testing, etc. repeatedly. Cycles. Not known, linear processes.

However, I don’t think all is lost. The key is going to be moving away from a strict, dogmatic approach to Kanban and adding some order to the chaos you’re experiencing. Adding in the missing parts of the process specific to more empirical endeavors like design and development.

I’ll add more here where I can. In the meantime, to at least get everyone on the same page, consider these exercises (if you haven’t seen/used them already). It’s a 7-part series and it highlights the things I force teams and stakeholders to do in training/consult situations :wink:

The very act of running through these exercises with the folks involved may change the conversation in a productive way:


FWIW, I’ll re-post the answer I posted when this quesiton was asked over at the UX StackExchange site earlier today.

I started working for a company as the first and only UX professional on-staff about a year and a half ago. At the time we were in a pretty similar position: while we had projects and deliverables, we didn’t have any real goals or mission.

Since I’ve started, I’ve been working hard to establish UX as part of the company culture. Here are some of my biggest takeaways.

##Above All Else, Establish a Process

The first and biggest step you can take towards gaining more focus on UX within any organization struggling to adopt it fully is to establish a clear process. Every UX designer seems to have their own UX process, myself included, and each process should be different based on context. However, by establishing and socializing your process, you set expectations about what the business can expect from you, and what you can expect from them.

At the feature level, having an established process will help provide a better understanding of timeline and progress among your team members and business partners-- transparency that appears to be sorely lacking. At the user story level, it will also help you establish goals and provide a more clear understanding of expected results of recent work.

To help with transparency, consider adjusting your team’s Kanban columns to reflect where your team is in the UX process. Rather than following the traditional “Backlog,” “Ready to Work,” “In Progress,” and “Complete” structure, create columns that reflect the steps in your process such as “Iterating,” “Low Res Design,” “High Res Design,” “Refined With Team,” “In Development,” “Deployed,” and “UX Testing.”

Critical to any Kanban team’s success is the retrospective-- taking time every so often to look back and discuss what’s working well with the team, what isn’t, and also to discuss upcoming work. If you don’t have occasional retrospectives, either post-release or at regular time periods throughout the year, make sure that you get this on the calendar as part of your overall process.

It’s worth noting that, whatever process you use, the process should be your own, based on your understanding of the needs of your company and goals. While it’s good to ask for feedback initially, don’t wait to set something in stone, even if your feedback on goals and direction is wishy-washy.

Set a meeting with your analysts, head of department, and managers to present your process, with a clear understanding that this is a presentation of what you will be doing and not an invitation for feedback. If nothing else, it’s a starting point for a process that can change in the future. In every journey, however, you need to take that first step.

##Socialize the Benefits Among Stakeholders

In order to gain buy-in to your process, you must be able to explain why that process is beneficial to your stakeholders.

Who are your stakeholders in this situation?

Your team will gain transparency and reduce friction/time to completion by having a clear understanding of what’s expected at each step along the way.

Your business partners will have a better understanding how your team works, and why it makes the requests that it does at different steps in the development cycle. They should also experience a boost in cross-team communication, as any good process places the UX professional in a unique position to coordinate efforts and facilitate communication across groups.

Your end users will experience a better product, gain clarity into the development life cycle and priorities, and have more input on the direction of your product. This is always a bi-product of greater customer engagement and UX testing.
Set Goals Around KPIs For Your Team

You wouldn’t go to the archery range without a target. Everyone needs something to shoot for, and it’s time you gave your team a mark.

Begin gaining goal orientation by establishing a few KPIs for your team. What you choose initially matters less than having a goals in the first place. Two easily understandable metrics to cherry pick might be lead time and cycle time. Do some research to find out how your team measures up and set small goals for improvement.

It might feel wrong to set the bar low, but doing so serves two main purposes. First, it helps give your team something to shoot for while getting used to an established process. Secondly, achieving even small goals feels like a win, rather than whiffing on larger jumps. It’s important to have wins early in the process to keep the momentum towards UX focus strong.

##Summing Up

Establish a process. Socialize the benefits. Set goals. If you can do these three things, you’ll develop a more focused UX culture and drive results in your organization.


Hey @joenatoli, thank you very much for you feedback. I’ve realized that some of the key things in the team seems missing. As I started to address these topics, I was informed that every decision and approach in the company has been defined intentionally. Nothing by accident. So at this point in time it’s been made clear that:

  • We won’t be moving to scrum or sprints,
  • We don’t want to incrementally improve our product - instead, huge chunks of complete redesigning,
  • We won’t be adding deadlines as “we will miss it anyway and it adds too much pressure on developers which makes them leave the company”,
  • We don’t want KPI’s or anything close to efficiency stats etc when it comes to the platform as optimization could result in “people being let go due to more tasks that can be done by less people”

These points make some of the pointers that I’ve been receiving, incredibly hard to just implement. Coming from a Scrum background and having experience in software- and product development, I knew straight away what questions to ask. So some of the feedback points me to the questions that I’ve already asked so I’m finding myself constantly questioning my competence.

I’ve been advised, if anything else, just establish a working process which would in turn potentially bring some order to the chaos so that will be one of my first objectives. I will be working through that 7-part series of yours and try, yet again, to bring shared understanding between stakeholders and team.

Thanks for your feedback. Appreciate it a lot!


Hey @HAWK, I’ve tried addressing some of these points, but as mentioned in my reply to Joe’s post, I was informed that some of these decisions were made very clearly and with clear intent. It’s been made quite clear that the team will not be adapting or changing it’s process in terms of approach and deadlines etc.

My next plan of action is to work through Joe’s 7 part video series in an attempt to try get everyone on the same page. Some of the stakeholders are already a little annoyed due to my persistence for shared understanding but hey, at the end of the day we need a great product as a team right!


It’s OK if they’re annoyed :wink: But one of the things you can do to move past that is to have a conversation that’s all about them: “What’s the outcome you’re after here?” “What thing that’s happening now would you like to see go away forever?”

Self-interest is a powerful motivator; if they feel like you being a pain in the ass is going to remove some things they’re hating right now, the road ahead may get smoother.


Excellent advice here, @brendin. Even if you don’t implement all of this, I think a chunk of what Doug suggests here could be implemented without changing the way everyone works. And without asking for permission to do so.

If you can’t get official sanction/approval, fine — do it anyway within your team, the part of the world you have control over. If stakeholders don’t want to talk about it, fine; figure out what you can do without them to impose order and get results, because those results will convince anyone who needs convincing. :wink:


So much this. Control what you can control, win when it’s in your power, and your results will speak louder than words.