You’re the first UX designer in your organisation, a new breed that comes with so many possibilities. The future’s exciting but it can get quite scary if you don’t have a plan.
I’ve been the first UX hire for an organisation or project a few times but what do you do when you’re the first? The pioneer? It can be quite scary and daunting but also incredibly rewarding. I’ve had success in creating and managing practices but can’t say if my method is the optimum way only that it works for me and the organisations who engage me.
I’ll start by stating that establishing a practice is not something you do in a few weeks, it’s something I believe never really ends as you’re forever maturing and improving as a professional, team and organisation. Much like evolving a product through iterative development, when you’re building a practice you build it piece by piece learning from both your successes and failures.
Full disclosure, I’m a process nerd and an engineer at heart so I always start with the groundwork, ensuring your foundations are firm and strong is essential if you’re going to reach dizzying heights later on. I treat the process as I would any other piece of design which means starting with research. It’s critical you understand why you were hired, what was the need that wasn’t being met previously and who was feeling the pain? I recommend having interviews with all your stakeholders, not just the person you report into. This of course means knowing who your stakeholders are and in larger organisations this sometimes takes a bit of work to discover. My tip would be to make a beeline for any senior managers or leaders of any team that interact with your customers; sales, service, product management and engineering are good places to start. But what do you discuss? I treat these interviews like a user interview. We all know recollection is easier than thinking up new things so I start by talking about their past experiences... For example, what pain do they feel in their roles? What user pain points are they aware of? What do they think of the product or service being offered today? What is their relation like with the other teams? I then move on to understanding what they think my role is and what their expectations are of me. Knowing all this helps you understand the size of the hole you’ve been brought in to fill. It will also give you some clear guidance on the capabilities you’re expected to bring to the organisation.
OK… You’re beginning to understand who’s who in the zoo and where you fit in. I recommend building up an understanding of how you’re going to work on a day to day basis. Will you be embedded in a single squad or will you interact with multiple teams? It’s also really important to build up an understanding of the scale of the work. Is it a one person job or will you need to hire more people. If it’s the latter, how can you demonstrate this and is this in the longer term plan?
You should be able to list out the expectations for your new UX practice and begin to formulate processes and activities that will start to answer the organisation’s expectations but don’t forget why you were hired. You’re the expert! It’s really important to add into the mix the benefit of your experience, what do you think a good UX practice should look like. For me, having a strong research focus to a UX practice is key, I believe without knowing your users you will never succeed.
Building a successful UX practice requires you to be adept with short term and long term plays. You need to figure out how to work productively quickly but also be looking how to enrich and elevate business strategy and business direction through greater user-centricity but be warned, this is a long play and requires significant research and trust building.
I recommend focusing on the here and now in the short term until you’ve bedded in. It’s critical to have really strong relations with those people you interact with the most not only to make work fun but also to understand their design maturity and perspective. Are these people you’ll need to lead by the nose or are they already familiar with the value of design? You’ll need to work out how to communicate and interact with each member of your team(s) in a productive fashion. This alone can take some time to get right and it’s really important here to be humble and patient, you can’t manufacture trust, it has to be nurtured and grown organically so I’m always prepared for a long and winding journey when it comes to establishing relationships.
But here’s the rub, you’re highly unlikely to be given the time to do all these things, you’ll no doubt be thrust into the maelstrom to address the specific need you were hired to answer so you’ll need to carve time out to do these things which can be tricky when you’re just getting started in a new organisation. I’ve learnt that if you don’t give yourself time, no one else will. It may be as simple as booking 30 minutes three days a week to begin to address these tasks.
Your first project is the first time you get to demonstrate your design process but you’ll first need to understand the project structures and constraints already in place. I always strive to make my process overt and obvious to start with so I normally double down on documenting and socialising my plans and encouraging collaboration at every stage.
My preferred way of working is basically the familiar double-diamond process where we examine the problem space to understand the problem that is to be solved and then examine a variety of ways to solve that problem. Be careful though, with such an approach it’s easy to fall into the trap of waterfall design and development so I always strive to understand how to get the user’s input as early and often as possible so as to learn as we go.
I try to bring as much user research into my process as is feasible. At worst, doing basic guerilla testing but ideally aiming for a validated learning program based on experimentation that is built into the release cadence. My goal here is to understand the users motivations and capture them in a format that is consumable by my team. I like to use the Jobs To Be Done framework and build job stories and timelines to help explore context. You may need to experiment with different artefacts to find what resonates with your stakeholders. No doubt the scale of projects you’ll be asked to collaborate on will vary so there isn’t a one-size-fits-all solution I’m afraid. As a base level I recommend always having:
I firmly believe good design is a team sport so try to build inclusive processes that bring the whole team on the journey. As it’s your first project you’ll also really need to be building those relationships with your teammates so be sure to share early and often to find the balance of what level of engagement is just right for your team.
Remember this is an experiment, you need to find what resonates with your team and stakeholders and which artefacts bring the most business and user value. Feedback is the key to accelerating this process.
Once you have completed your first project or your first couple of releases (if you’re doing it properly) you’ll begin to have the skeleton of your core process. From here you can iterate, try things out and most importantly document it! Until it’s written down it’s hard to argue you have a process at all. This also massively helps when you start to scale the team. Treat your process as a product, get feedback from your team and stakeholders. Find out the bits they like and the bits they draw value from.
If you’ve got this far then you’re doing amazingly well but at some point you will need to work out how to break free of just designing to feed the development machine and begin to work on more future focused and less project-based initiatives like getting to know your users better, designing a vision or implementing a design system. This can be a real struggle, especially if you’re still hands on most of the time. My tip is start small but sell the vision. For example, maybe you have a couple dozen user interviews captured across lots of projects, could you pull them all together and produce more detailed personas or could you do a survey to find out what your users most value in your product? These both would probably be a couple days work which you can fit around your normal work over a couple of weeks. Make sure you really sell the value of this work and work with other departments to see what they would find useful. Doing a couple of these side projects a year really helps you to start to get ahead of the machine. If you find yourself in a supervisory role or management role as your team has grown then you have more time to dedicate to projects like this. If you’re in this position be sure to delegate tasks to you teammates so they feel like they’re building the practice too.
As I mentioned earlier, I’m a process nerd. I like to design processes for a host of reasons:
I’ve led the creation of several processes and frameworks to help teams and departments work better. I have had successes and also some misses but my biggest learning is that a process is not a collection of artefacts, it’s a group of people working together in an organised fashion. The artefact is the enabler, nothing more. Don’t put your energies into building the Encyclopedia Processica, no one will thank you for something no one uses and watching something fail to get traction can be soul destroying. Keep it light, keep it small and iterate. Don’t plan the whole kit and kaboodle, just focus on the first bit and work hard to drive adoption. Once something is in the wild it’s much easier to spot which bits need work.
Two recent examples of how I create processes would be the formalisation of our product development process and a new experimentation framework.
The product development process project was started as we transitioned from capability-based teams into cross-functional squads and had adopted dual-track agile but every squad was working in a slightly different way with different artefacts and processes which meant it became really difficult for senior managers to understand how each team was performing. I worked with the head of product and referenced product books like Marty Cagan’s Inspired to draw up a relatively simple high-level process that was detailed enough to give us the level of uniformity we needed but not heavy and bureaucratic. It had two simple goals:
I worked with the engineering managers and product managers to understand how they were working today and find a common pattern that could be adopted without too much disruption. We workshopped ideas and were able to pull a strawman process together fairly quickly. I spent a day or two documenting it so we had something visual to point to and then we presented it to the leadership team to see if they thought it made sense. I gave walkthroughs in townhalls and all hands and delivered coaching sessions for each triad. I then helped each team to set up their backlogs and coached designers and product managers on documentation. Did I mention I was a process nerd ;)
For the most part, adoption was a bit of a non-event as the process pulled on what was already being done within the department. The progress was quickly recognised though, suddenly meetings like scrum of scrums suddenly became much quicker and easier to follow as we had a common language and framework to reference.
I carried on holding regular catch ups with each triad to see how they were tracking and what problems they were running into. I held regular catch ups with the head of product and other senior stakeholders to see if they were finding it easier to understand how the squads were working. It’s been in place for a year now and we’re just beginning to make our first major evolution of the processes to address some of the bigger and common issues we’ve observed.
I complemented this work by helping create an experimentation framework. The aim of this work was to make how we conduct experiments more consistent and also help us to mature quickly in this area. Prior to this point, the main problem we were observing was that we consistently “over baked” our experiments so they became really big and slow to deliver. This impacted the pace of our learning so the product evolved at a glacial pace. We also didn’t plan very well and had a less than scientific approach to defining success. This often resulted in experiments that were deemed “successful” to simply be left out in the wild to become part of the product. I led a cross-functional squad made up of data scientists, marketers, product managers and engineering managers to come up with a framework that redefined our philosophy on experiments.
The work had three goals:
We interviewed product managers to understand how they had built experiments in the past to capture the lessons learned. We then interviewed stakeholders from outside of Product to understand what they needed in terms of experiments and we also did lots of desk research to try and understand that things are considered best practice.
We created templates for documentation, Jira boards for tracking, wrote guides on topics such as how to structure an experiment, how to report on experiments and deciding whether an experiment was a success or not.
Our squad provided coaching and guidance to triads, their squads and management to understand their impression of the material we had created. We then held regular check ups with each triad to triage any issues coming up and making changes to the framework. It’s now six months later and I’m proud to say we’re well on the way to becoming a more mature product organisation. We’re not quite up to the fifteen experiments Marty Cagan says you should have running at any one time but we’re much further along the journey than we were. We’ll continue to iterate and improve but the journey never ends.
One of the most important lessons I’ve learnt over time is giving your team space to grow into really encourages them to grow and accommodate the new space. This may be taking on new responsibilities, doing more strategy leadership or conducting more visionary and future-focused work. I have also found this is one of the quickest ways of getting design or UX “a seat at the table” and a say in business direction.
When I first started with my current team we were classed as a service, something to be used to achieve a very simple outcome, make a development better or prettier. Like I suggested, we initially focused on the day to day stuff and built our processes that met our stakeholders’ expectations. Once we had our day to day processes working well we began to engage senior leaders within the organisation to understand how business strategy and direction were created and what problems they experience when doing the work with the goal of selling in supporting work that the design team could do to make this process easier. This allowed us to begin to get exposed to more strategic work and gradually begin to produce work that helped set direction. Just like how we evolved the practice from a service into a centre of excellence, over time we were able to grow the strategic work we did from background and supportive to leading conversations. This allowed the practice to become more influential within the organisation and helped us grow the practice in terms of the strategic work we did. An example of this is that we built the company’s first product vision to help get more internal alignment within the organisation and provide more stability for growing the product.
I sometimes feel like I’m standing on the boundary of two worlds, the intra-team world centred on evolution, development and mentorship, the inter-team world focused on understanding how best to serve and interact with the business. I have to keep the two worlds in balance, growing the team in a way that’s both good for the business and good for the team. Maintaining this balance is at the core of successfully managing a design / ux practice.
Cover image by Simon Berger on Unsplash
https://unsplash.com/photos/twukN12EN7c
Contact
Jules Munford
Phone: 0431 414322
Email: julian.munford@googlemail.com
Twitter: @julesmunford
© Julian Munford 2020