Chris and Thomas take a peek behind the development curtain to find out what makes a product team user-focused.
- What makes a team user-centric?
- How are developers affected by UX decisions?
- Should designers code?!
- How can we support better user stories that work for both developers AND designers?
- How can we all play nicely together?
- You can learn more about the digital transformation project that Thomas and I have been working on for… Besco… in this very exciting case study.
- Check out Masters Of Scale, particularly the very awesome first episode featuring AirBnb.
- The agency thomas mentioned who use the ‘top trumps’ style of user story point allocation is Mountain Goat Software.
Well hello to you, and welcome to Making Matters ; the podcast all about UX, design, development and all other kinds of exciting digital things. My name is Chris Myhill, and I’m a UX designer based in London.
My name is Thomas Edwards. I’m a solution architect based in London. A solution architect, if you don’t know, is someone who helps make something happen using technology.
This is the first of what I hope to be many podcasts, but will probably be just be one. Maybe two, if we’re feeling really keen.
So today I want to talk to the shifting complexity behind the development curtain. Thomas is hopefully going to help me get to the bottom of some of these problems.
I’ve been working with Thomas for quite a while. Right now, we’re tacking a rather big digital transformation project for a high-street supermarket chain here in the UK. To retain their anonymity, we’ll call them…. Mesco.
…It’s Tesco. (laughs).
So this project is all about creating a much simpler and more straightforward digital workplace for their staff. Now, most people who work in supermarket stores aren’t too technology savvy. And they don’t want to be, either. In this day and age though, most people need to use technology on an almost daily basis to get their jobs done.
The tools and information staff needed involved interacting with a bunch of really complicated systems. When we first got involved with the project, we did a lot of research on the processes that the staff had to use. It was just mind-boggling how many different systems they needed to get everything done. The tools were so complex, and they were forced to accept a lot of really bad design… and (quite often) incorrect assumptions about how they would understand the technology.
We’re working on it. It’s a long process, but we’re trying to make their tools much simpler for actual human beings to use.
This is the sort of thing we’d like to talk about. For companies like… ‘Fresco’… there’s a big shift underway. They’re realising that putting good design at the heart of the business is really important to staying successful.
What we’re trying to do as technologists is transfer that complexity behind the ‘development curtain’, to give users a better experience. And that’s what I want to ask you about, Thomas!
What do you think is involved for organisations (and developers) to shift to this new way of thinking?
I think that a lot of it comes from the top. It comes from the management of the organisation that you’re working with. You have to bear in mind that a lot of the people who have managed to get to the top are obviously very senior. They’ve been in the company for a long time, and they’re used to certain ways of working. In an IT-sense, they will have been around, likely, towards the tail end of the ‘mainframe era’ of computing. When you’re dealing with a mainframe operation, the most expensive component is actually building the system. You don’t really want to have to bend any rules, or change something just to help someone have a slightly better day.
The shift, I think has come the idea that you can now quickly put together an application much more affordably than you could have a decade ago. Suddenly the opportunity is there, and you need the CTO (Chief Technology Officer) or whoever is at the top, to get it. This is so everyone down the chain understands that it’s a priority. The priority isn’t doing lots of things - it’s doing the right things and doing them well.
Unfortunately, that sometimes means saying no. There are a great deal of podcasts that already talk about the idea of saying no and prioritizing. They speak the trurth. It does from the top. What we need is for someone to say : “Actually, we don’t want these 10 or 15 new features. We just want this one great one that does really well, and we’re prepared to invest the time in it”.
This, combined with the efficiencies of modern development means you should be able to get it. But that’s the biggest challenge… The top-down factor
I was listening to a podcast called ‘masters of scale’. There was an awesome story about the early days of AirBnB. In the early days they were not only building the site, but they were meeting the property owners to take the photos, to meet them, to basically ask them how everything was going with the service.
I think it’s quite incredible when you’re not just running your business, but also doing your user research, and developing your site. All of these different roles end up getting rolled into one. I guess that leads me to asking ; is it a lot for one person to take on? Especially in a startup environment, does it take a special kind of developer to have this user-centric attitude?
Yes and no. It’s tricky. I think there are different types of developers, and they have different things they enjoy. A lot of developers will enjoy making things as smooth as possible without really worrying about the actual end user. It might just be that they’re responsible for making the site as quick as possible. Now they enjoy the fact that it’s as quick as possible, but they reason they’re doing it is because they know it’s what’s best.
I think that the best developers have the end user in their mind at some point. It’s why they do what they do… But I think the tricky bit is finding the ones that understand user experience, and the research that goes into it. Those that try to bridge the gap between what’s the most efficient thing, and what’s user-centric. This is a little more difficult.
A developer really ought to have that mindset where they’re thinking about how the user might navigate through what they’re building. It means extra work and putting yourself out, and that’s the key thing that you want.
Yeah. It’s complicated. Obviously you’ve got designers and UXers on your team, but you’ve also got developers. They’re being put under a lot of pressure recently to think more about the user, and be have more of a seat at the table. I sometimes wonder how realistic that is because, as designers, it’s very much built into our job descriptions and always has been. Getting involved in workshops… getting our hands dirty with user testing and research… But now we’re increasingly seeing developers being expected to also do these things. To be more of a participant in the user research.
You hear a lot of people saying “get the developers on board! Get them to your user testing! Have them at the workshops!”. That’s fantastic, and I agree it’s what we should do… But is that leaving the developer with sufficient enough time to focus on development?
Mmm, yeah. A developer is being pressed for time. Development is quite expensive, and you get a lot of pushback from senior people (normally those paying the bills) who don’t want to waste the money or time. This probably causes a lot of friction when a user experience request causes conflicts because it’s enormously expensive to do.
When does that ever happen? (laughs).
We’re giggling because this is probably the only thing we talked about before the show.
There was a blog post a while ago talking about the ‘undo’ button in Google Mail. That’s the way it should be, when you delete an email. You probably wanted to delete it, and don’t need a confirmation button. Undo is fine, and that’s the experience you’d probably expect. The developer implications for having an undo button are absolutely enormous. Suddenly you need to add a field to your database to cope with the fact that the user has deleted something, but it isn’t gone yet. You need to have an operation to tidy things up. What happens if the user deletes something, and then immediately closes the window? You can’t rely on the Undo button waiting for 10 seconds before performing the action. So you need to have a background process to prevent that problem.
Just having an ‘undo’ button, instead of a ‘yes or no’ choice could add days of development if you’re working in a complex environment. It may not even be possible.
So what started as a simple idea in the user experience suddenly becomes a monster for the people who have to make it. So there’s a friction there. It’s tricky. It can be very hard.
Interesting. I think that’s where the conversation flips a bit. I know quite a lot of designers who, in a situation like that, would actually get quite uppity about being challenged on their design idea. “Why do we need that ugly ‘yes or no’ box that pops up? We just want an undo button! That’s what nicer!”
I think when you start to understand the implications of some of your design decisions, and how much of a pain in the arse you’re causing the developer you start to think twice. You start to wonder if the benefit of that feature is enough to warrant the developer tearing his or her hair out for the next several days.
That’s it. You need to have the data behind your decision to prove it’s worth their while. I think when it comes to design, as opposed to research, it can be very cute for a designer to say “this looks really nice”. And I’d agree — but it’s also very expensive, and it doesn’t offer a tangible benefit to the user. It just looks better.
Design is functionality. It’s not necessarily about making things pretty, although that helps. Without data behind them, it’s ok to push back on a designers choices because if you can save days of development just by tweaking the design a tiny bit (without any impact to the user), those are savings you should be making. Just for the sake of everyone’s conscience.
The more complexity you add to a project, the more tricky it becomes to manage post-launch. But if you have the data behind it to say why it’ll make the product better, then that changes things.
To that point, I guess it’s a really important responsibility of the designer to take on. They need to have that understanding of how much complexity they are adding to a project through the decisions they’re making.
Absolutely. This comes back to an argument that a number of people have written about which is “should designers code?”.
Oh no! He said it!
(laughs). My personal belief is that they shouldn’t need to. Not necessarily. But they should understand he web. They should understand the components that the web is made up of. It’s a very tricky argument, and it’s not going to be resolved today by us, but it certainly helps to help from a web point of view, instead of a pictures point of view.
Mmm, and an understanding of when you create that sketch layout or whatever, having an idea of how much effort that’s making for the development team.
Something we’ve done together in the past that’s worked quite well is to work with user stories. So, when we’re producing designs we’ll at the same time be creating user stories that we can assign an effort level to each one. I think points is the technical agile term. So when we’re scoping out features in our design, we’re essentially adding 1, 2 or 3 points to each one. The designer doesn’t necessarily need to know all of the complexities associated to the story, but they do need to understand the level that it is.
Something quite simple like having an ‘undo’ button on the page might have taken the designer 15 minutes to mock up… But that’s actually a 3 point story that’s going to keep the developer busy for a whole week.
Absolutely, there’s a company called Mountain Goat Software that use a ‘top trumps’ system. You have cards with effort points on them. When they’re working, they sit the team down, including the designer, and they all at the same time put their card in for the number of points they’re awarding a story. So a designer might go “it’s a 1”, and put their 1 card down. The developer might say “that’s a 3” and put the 3 card down. The rule is that you go with whoever is highest. You might ask them why, and talk about it a bit.
On the flipside, there are always scenarios where the designer can find something more complicated. Maybe due to the implications of responsive design. It might be something quite fiddly to do across different widths. The developer might find this really. So it can flip around, and the designer can have a situation where they have a more complex problem as well.
It comes back to what every successful project comes back to. Getting everyone on the team involved early. As experience designers, we always put a lot of emphasis on the user requirements. Or, to some extent, the business requirements.
We sometimes fail to think about what our teams are prioritising. So for example, a developer might want to improve performance and page load time. Having them involved early, and getting those thoughts out on the table is really importnat.
Yeah, absolutely. I’ve been thinking about this for quite a while. Trying to figure out the best way to write stories so they get all the way though.
A lot of people get quite precious about their stories at the beginning, but you need to make them flexible - allowing for developer and designer oriented stories. You have to be honest about them, you have to say “as a developer, I want this to happen”, but then at least it’s open and honest and you have a conversation. Otherwise it’s something you might talk about at the beginning, but don’t necessarily capture.
“As a user experience designer, I want to be user testing every week! I want some budget!” (laughs)
Right, shall we call it there?
Where can they find you, Thomas? Those people on the internet?
I’m Thomas Edwards ; @thomasedwards on twitter
I’m Chris Myhill ; @justuxdesign on the twitter. Lovely, thanks very much!
Thanks for listening!