Designing Agile: When deadlines are short, budgets are tight and the client thinks design is simply colouring in

In an ideal world, designers would be able to follow each and every step of the user-centered design process. In reality, when we’re working in an agile team, where product updates need to ship quickly and efficiently, following a perfectly thought out design process can become untenable. As the sole designer on an agile delivery team, how can you instill user-centered design across the team, conduct regular user research and get buy-in from the organisation?   

As a designer on numerous agile delivery teams, I can empathise with the challenges that designers face today. Research by Marcin Treder, CEO of UXPin (one of the world’s leading user interface design platforms) highlights these challenges, and at the top of the list is a lack of understanding of the design process from non-designers, which makes team engagement even more challenging. Tight budgets often force designers to skip important, but costly research and despite the effectiveness and low costs of guerrilla research, many mature organizations are hesitant to try it. Marcin’s research also shows that many designers are not using lo-fi prototypes as the idea is still not popular with clients. 

Every project I’ve been involved with has meant finding ways to overcome these challenges. I’ve had to develop my go-to ways and sometimes pivot when things aren’t going to plan. I’ve summarized these below.

Building your team

When you have tight deadlines and you’re the only designer on a large delivery project in an organisation that has never adopted a user-centered approach, you need to scale and multiply. Working in a delivery team rather than as a siloed designer has many advantages including teammates to help take the load. To reduce wasted effort and increase your chances of success, you need to understand who you’re designing for and test your designs with real customers.

On a recent project, I was the only designer and needed to conduct user research across our identified cohorts for an MVP (minimum viable product). The research and findings needed to be completed within one iteration (two weeks) and I was only working four days a week (I entertain my toddler on the fifth day). Within 8 days, we managed to conduct 19 one-on-one customer interviews, make 305 observations and run a co-design workshop. That was only possible by identifying people on my team and within the organisation who could help. I’ve always found people are happy to help out if I explain the process and walk them through everything they need to do. Generally, the teams I work with are very happy to help as they want to create software that customers love too and people from other departments are often keen to find out more about customer research.




I find it helps to create a framework that people can follow with customer questions and simple exercises that can easily be conducted during interviews. I also think a training session can help, even if it’s just to go over some basic things like how to correctly frame a question.  While I created the exercises and content for the research, one of the BA’s on the team organised the interviewers and interviewees. I enlisted the help of the customer engagement team to send out emails and placed adverts on Airtasker to obtain users in our identified cohorts for the interviews. I then used Doodle for people to select what sessions they could attend which reduced a lot of the admin burden. 

Being inclusive

Finding ways to effectively communicate with diverse teams and customers requires empathy and trying different things until you find something that works. I’ve been in situations where quieter members on my team didn’t feel comfortable conducting customer interviews but I needed them to get on board all the same. I wanted them to start seeing the product from a user's perspective rather than the same lense they’d had for the last 10 years of developing the old product we were replacing. I individually spoke to them and emphasised that I wanted them to be involved and asked if they would be comfortable to simply sit in the interview and observe. They not only agreed but I saw how they viewed the product we were creating from a different perspective, and got excited about solving a problem they’d seen a customer have and started thinking with a different mindset. In later user-testing sessions one of them even volunteered to take notes.  

 



It’s not always that smooth sailing. I was running a problem-solving, gathering and co-design session with a group of customers. They were the hardest group of people I’ve had to work with so far. They hated sketching, couldn’t see the value because they didn’t care about design and saw it as my problem to solve. I explained that I needed to gather insights to help me design software they would like and they would find intuitive and that I was trying to help design something that would solve their problems and make their work easier. 

Some of the more forward thinking people in the group approached me later and said they liked the session and could see the value, unfortunately, there were others with a more narrow mindset. In the second session with these users, we changed things as they specifically asked not to use post-its or sketch, instead, we printed out screens from the original system and facilitated gathering information on how they used it. This session proved much better. The problem we had was, working with a set of customers that had a history of being let down by the client with not being able to deliver on promises due to the legacy software. We needed to build their trust. 

In the third session, I suggested to the client that we conduct some one-on-one interviews, where we go out to specific customers, both power users and novice users. Taking time out to go to them showed we cared, would help build relationships and would allow us to really see how they used the software. This new direction worked very well, we built better relationships and found out things we would never have found. These users were much better one on one than in a group and shared a lot more information with us.

Spreading UCD and the methodology across the team and organisation.

Another advantage of working on a continuous-delivery team is being part of ‘showcases’. These are held at the end of each iteration (every two weeks), depending on the size of the organisation, we usually have an open invitation to whomever wants to attend. During the showcase, we walk the audience through what we did during the iteration, what our next steps are etc. We cover high-level info across business, technology, and design.
 
As a designer, this is your platform to really sell design to the organisation. I walk through what we’ve been doing, why we’re doing it and the results. I cover everything from the research phase through to showing lo-fi prototypes and high-fi designs. I emphasis what design is, and isn’t, to drive the point home that I don’t just draw pretty pictures, though they always seem to like my pretty pictures ;)


 
I’ve always found I get a lot of questions at the end with people wanting to know more about design and the insights we’ve gathered.
 
Showcases work well to sell to the wider organisation but you still need team buy-in. Although we have daily standups, it’s hard in that short time to talk about design on a deeper level. To overcome this and ensure the team understands where I am with design, to get their buy-in and keep them user-centered, I run fortnightly 30-minute design sessions to bring the team up to speed on everything. This ensures we are all on the same page, as I’m often working with multiple developer pairs on different components at any one time.

Trust

It’s such a simple word, yet so powerful. To drive design change in an organisation, to recruit willing people to help in your quest, and to make the introverted feel safe, requires trust. This doesn’t happen overnight but it must happen quickly, especially in a fast-paced delivery team. You need them to trust you. Once you have their trust they’ll follow you. I find building trust comes from being honest, open, understanding and most importantly, simply being nice.
 
Many clients I work with have never undertaken customer interviews and it’s a scary process for them. Many have had the same clients for years and letting a consultant they hardly know openly go to speak to them can be daunting. They’re worried customers will panic when they find out the software they’ve used for years is suddenly going to be replaced by something new, they’ve had bad experiences trying to get ideas from customers before or trying to deliver customer promises. It’s understandable they feel like they do, but how can we overcome this as a designer? I build trust with those that can give me access to the customers and explain the advantages, I invite them to join me on interview sessions and explain that we can try it on the customers they feel most comfortable with first.
 
I worked with a client who had these concerns a few years ago. Once he came along to a few sessions with us, he quickly became comfortable and even gave me the customers’ direct phone numbers so I could organize interviews directly rather than going through him. We ended up building great relationships with the customers.

Research and testing doesn’t have to be expensive or laborious 

Fast-paced delivery teams with tight budgets and delivery deadlines don’t have the luxury and time for extensive research. But that doesn’t mean organisations should use it as an excuse not to do it. It just means we need to find something that works for the individual client.
 
Using cohorts and the power of five, is nothing new to designers but something many clients aren’t familiar with. I explain the advantages of identifying cohorts to the clients and explain how we can narrow research and testing by having five people from each cohort or if we have too many cohorts, then to just focus on the main ones clients want to focus on. I usually find that many clients get scarred and usually at this point, swing in the opposite direction and go from wanting to interview no customers to wanting to interview thousands. Unfortunately time and budget are often strongly against us. I find showing them some articles on how patterns emerge after testing with five usually is enough to convince them. If you haven’t built enough trust yet then showing articles from names such as Nielsen Norman Group etc is usually enough to get them over the line. Once the research is complete and you can show the patterns start to repeat you then have their full trust.
 
Going back to the trust thing again, once you’ve built a rapport with the customers, having a small pool you can pull on at anyone time for some quick feedback or testing can really help when you have tight deadlines and just need to validate something. Using tools like InVision is a quick way to send a prototype via email and gather quick insights without extensive and well planned and time-consuming user testing.
 
In some of the very large organizations I’ve worked with, we’ve often had moments where we don’t have time to go to the lengths of recruiting customers and don’t have a pool to pull from. Instead, we’ve recruited from within the company, finding people who fit the profile. We’ve then been able to do quick paper prototype testing within half a day to validate design decisions. Again, having that trust with a client can really help get the idea of internal testing and paper prototypes over the line.
 

To conclude

As designers, we’ll always have to be flexible and think on our feet. We like to experiment and try new things, so not strictly following a process probably works better for our personality types. But, if we’re going to instill UCD in organisations we still have a way to go. I’m not saying the above is the perfect solution and it’s tiring having to start from the beginning with every new client but that’s also the fun and the gratification you get from seeing an organisation change the way they think makes the hard work worth it.
 
I hope some of the above helps you instill a more user-centered approach, it’s not going to solve everything, but if we share what we find works the closer we can get to solving some of the problems.