Per Axbom
UX podcast is funded by James and Per together with contributions we get from you, our listeners. If you’d like to contribute, you can do so financially, but also as a volunteer. We’d love your help to make sure we get our transcripts and various other things created and published for each show. Raise your hand to help by emailing UXpodcast@UXpodcast.com.

[Music]

James Royal-Lawson
I’m James.

Per Axbom
I’m Per.

James Royal-Lawson
And this is UX Podcast, balancing business technology and people every other Friday since 2011. We’ve listeners in 195 countries from around the world, from Belgium, to Burkina Faso. Or maybe we can say bienvenue sur UX Podcast Burkina Faso.

Per Axbom
Oh, nice

James Royal-Lawson
A little bit of French.

Per Axbom
Burkina Faso is actually just northeast of the country I was born in, which is Liberia it doesn’t border but it’s very close.

James Royal-Lawson
So welcome. This week. This time, we’ve got a link show for you.

Per Axbom
And that’s when we find two articles, one article each during our digital travels, and try and discuss those, present them to each other and discuss them and see if we can agree or not with the content. And today for for you we have first out is the brief guide to testing mobile interfaces by Andrew Yevtushenko, and Marina Yalanska.

James Royal-Lawson
And second up, we’ve got delivering a good experience as a developer by Pierre Michel. Lots of French today.

Per Axbom
Yeah, nice. I didn’t know you had that skill James.

James Royal-Lawson
I think I lost it years ago, it got eaten up by Swedish.

Per Axbom
As you might expect, we’re actually getting a tad technical today, I believe. And I think that’s one thing that you and I have in common, maybe not all listeners are aware of that we actually have quite technical backgrounds in that we have dabbled with programming, and we’ve had computers really early on. So we really enjoy the technical aspects of the web.

James Royal-Lawson
But I don’t want you to scare them off in Per though, because what we’re hoping to do, I think with our discussions that we haven’t had yet today is connect the the design world and the developer world a little better

Per Axbom
Exactly. Understanding how we can do a better job by understanding new perspectives. So the first article is one I found and I it appealed to me a lot because it introduced actually a tonne of vocabulary, that these are words I hear, often in projects, but I’m always not always specific as to what they mean. Sometimes they float by and I realise, okay, we have to do some type of testing. And there’s different types of testing mentioned. And I’m not actually aware always of what those entail.

So in the project I’m currently working on where we’re testing different versions of a mobile interface by testing it in different types of phones. And I realised that I could be a better help to the developers by being better at explaining what I mean, within the context of their world. So this, this article, starts out by discussing why we’re testing, which of course, is a good start. And we’re talking about product quality, are we talking about, we want to reveal bugs. And that’s why we test interfaces. And the article itself is around testing mobile interfaces, but for me it actually testing any software and actually testing any website as well, this is relevant, this article is really relevant.

James Royal-Lawson
I can tell you though Per it was actually quite…well my instant reflection when I read it was whoa, wow, this is complicated.

Per Axbom
I know, I know. Exactly. And I think I was in the right mindset, actually, for it to be appealing to me all of a sudden. And as I was reading it, as you were saying, Wow, this is hugely useful to me. It’s just because it just introduces this installation testing, functional testing, performance testing, and has a sentence or two just describing what those different testing types are. Which helps me

James Royal-Lawson
Do you want me to read out… because I think it’s actually a wonderful list of these different aspects, I mean, it talks about testing in relation to native apps, web apps, hybrid apps, and then it goes on talk about how you would do unit testing, integration testing, system testing, acceptance testing. But then on top of that you have usability testing, installation testing, functional testing, performance testing, interruption testing, memory testing, security testing, it’s a lot of different things to test.

Per Axbom
Right. And as I was reading it, I was I was realising that this is so much more structured than any usability test that I’ve been part of. When you said unit testing, that’s actually testing a small part of interface, that isn’t integrated anything else. So let’s say we’re testing a button or we’re testing just one page of a website. Whereas when you go on you go integration testing, so this form interacts with this other next step in the form, so you’re integrating different pieces of the puzzle. So you have to figure out do those function well together. And then you go on to test the whole system, which will be the whole website or the whole app. And acceptance testing is, of course, when the client steps in to approve, does this work the way we expect it to. So those are the different levels going from the smallest, tiny piece of unit that you want to test.

I mean, from a UX perspective, that would be does the button look the way I want it to. And then you look at do the buttons across the different pages look the way I want them to do they make sense, do we have primary secondary thoughts about what they should look like.

James Royal-Lawson
But also not just visually Per, the button has to be clickable, and it has to actually do a function.

Per Axbom
Yep. I wanted to keep it simple. But you’re right, it’s so it’s always more complex than I mention, of course. And then there’s when you were going on to describe the different types, then I realised that those different types of testing also helped me to understand the different scenarios that we perhaps tend to forget when we’re doing usability testing, because I loved the way it talked about interruption testing. So when you’re on a phone and you’re browsing, sometimes you will get a call, sometimes the phone will run out of memory, the better we will go low, the media player will start playing, or it will turn off or something like that, and you have to push that button to push it aside. And, and these are scenarios that can happen as you’re using it.

James Royal-Lawson
I’m going to add to that one as well. But of course, this is loss of network, which is something I mean, I’ve been part of many tests where one of the tests is you pull out the network cable back in the day when we weren’t using Wi Fi or you turn your Wi Fi off. Does your does your application still survive, even though it’s not got any internet connection? I mean, there’s something that still astounds me, I think I mentioned this before that the Outlook still struggles if you lose your Internet connection. Yeah, that’s been the case since the 90s. I find it fascinating.

Per Axbom
Exactly. So just reading through these different types of testing and and why you do the testing actually brings out new perspectives on what you should be testing what you should be looking at. And this helps you talk to the developers as well and the engineers around, so the users are going through this process, and this happens, what should happen. And there are things that should happen from a design perspective.

But of course, also from a developer and engineering perspective, which puts you around discussing the same types of problems, which, which is really neat. And I was I was actually blown away, kind of because I’ve worked in this industry for many years. And I was blown away by the fact that I haven’t been involved as a UX or to the extent that I perhaps would like to in these different types of tests.

James Royal-Lawson
And this is an important point. Because all of these different tests ultimately impact the user experience. I mean, if you don’t, if you have a web app or a website that, say has a memory leak, I mean, that might be that slows down the website, it might crash, if a website crashes on it, that’s not good for users.

Same thing with interruption testing, like you said, if it doesn’t work to lose your connection, or when you get a phone call, severely impacts the user experience. If the button isn’t clickable, yeah, clearly, that’s not good stuff.

Yeah, it’s you know, so we need to be more aware of and maybe engaged with some of these aspects, so we can consider them and make maybe better decisions earlier on to help alleviating these problems.

Per Axbom
Exactly. Something I think you and I talk a lot about is performance testing, because we are aware of how long things can take depending on how they’re built. And so that’s a discussion you definitely should be having with your developers. Do they have any ideas and thoughts and knowledge and experience with designing things in different ways and how that impacts how slowly or fast the the or the website actually performs? And knowing and realising that you have to test that on devices for it to actually be real.

James Royal-Lawson
And also how maybe some of these things combined and overlap like if you’ve introduced maybe large images into your design, you’ve had a dialogue with the developers about how to best implement maybe lazy loading or, or kind of reduce the footprint of these images, you’ve then got to go into test to make sure that that solution to alleviate your design decision, or minimise the impact of it is robust.

Per Axbom
Exactly. And it goes on to talk about installation testing as well. And that also made me realise the install-uninstall workflow and how seldom we actually engage in in looking at that. The uninstall workflow for an app, how involved are you in doing that as a UXer or is that something that somebody ticks off in a box.

So in the end, I’m actually I was I was this, I found this article extremely useful. And it goes on to talk about, of course, how important it is to test design with prototyping and wireframing. And it also mentions which I also want to mention the code testing, which in this article, it explains as you do it, either with simulators that you can do online, to test your website in different browsers online. But you actually also have to do it with actual devices to be certain.

And what really got me going and this was on Friday, it was this realisation of how difficult it is to understand what something looks like on mobile devices these days, because many of us are still stuck in the idea of a pixel being a pixel on screen. Whereas these days, many of our screens are so have such high pixel densities, that we have such high resolutions, that there are many pixels per pixel, I don’t know how to explain this on podcast.

James Royal-Lawson
Well, I suppose basically, with on a screen, you’ve got ultimately, nowadays, you’ve got an LED lamp, in millions of places in your screen, they’re very, very tiny, and they shine differently in three different colours, red, green, or blue. And that pixel is no longer what we work with, as far as a CSS pixel. Because of the density, there’s too many LED pixels now on your screen. So one, one pixel might actually be four in reality on the screen, the physical screen

Per Axbom
And then you realise when you’re going from phone to phone, that one, one screen may actually have three of those pixels per inch, or 300 per inch, or whatever, and others have 600 per inch. And then you realise, well, if it only went by pixel, then it would be half the size on the bigger screen. The challenge then, of course, is that somebody had to decide, well, it has to be the same size still. And there’s actually a rule that you can keep in your head, that 96 pixels, a div that is 96 pixels wide is an American inch wide. On the screen,

James Royal-Lawson
…Roughly.

Per Axbom
It’s pretty much impossible to hold consistently across every single screen and device. But that’s the standard that it’s we’ve tried to implement.

Which means that you also have leakage over half pixels in a single pixel, which means it’s really difficult, of course, as a developer these days, to always get the right look on different screens.

James Royal-Lawson
I mean, the the article does mention browser testing, but I mean, that is complex with all the different browsers, especially when you consider the number of devices people use and browsers across devices. Yes, maybe chromium dominates just now. Well in both Android and desktops. But that’s not necessarily the case with Apple devices.

But on top of this, and this is what we’re getting into with pixels now, is the responsive testing. That you may have tested in all these different browsers, but what size viewport did you test in those browsers? That makes a huge impact on you know, what, what the person sees. And this is something I’ve I’ve talked about, I encourage when it comes to analytics. But I think because normally we design to break points. Well, yes, things are fluid between them. But you, you generally would have an idea about how something will look at that width, that width, that width or that height and so on.

So I try and encourage the sending in of breakpoints as something to the analytics software. So Google Analytics, for example. So you can actually divide your data up and look okay, how, how do people may be experiencing that width or this width? Because the experience can be very vastly different if you’re looking at the mobile breakpoint compared to desktop breakpoint, or somewhere in between.

Per Axbom
I mean, I’m reminded of when we in the late 90s, early 2000s. We were designing for different screen sizes on monitors and we were complaining about how difficult it was to choose the right screen size but today you have thousands of different types of phones because a lot of people are stuck with a phones they had five years ago, and some are upgrading all the time.

And it’s just, it’s almost impossible to keep up, it’s, it’s impossible to have a testing area where you have all these devices to be able to test. So of course, you’re sort of dependent on these virtual testers test possibilities online. But you also have to be aware that you perhaps need to be able to listen and make sure that people can report back different types of bugs based on the viewport size.

James Royal-Lawson
Yeah and also, you’ve got the accessibility aspect to that you might be using a larger font in your telephone, or, or screen settings set to be bigger or smaller than default. So this adds two or three permutations to all the other permutations you’ve already gathered when you’re testing. So it becomes actually becomes quite difficult to even get your head around how many different things… this is complicated stuff we work with.

Per Axbom
But it can actually be fun to talk about. And I think having that discussion with your developer, developer team is actually fun, you can make it a fun thing, to talk about complexity, talk about how impossible it is to do the right thing. And what you can do together to make it as seamless as possible in your work process day to day

James Royal-Lawson
And make and make things robust, but you know as in they can cope with failing. Because we can’t we’re not gonna be able to get this to work, on all devices and all screens. So we just need to make sure that when when things do break, they break in a way which actually is, you know, something you can deal with.

[Music]

James Royal-Lawson
So yeah, article number two today, delivering a good experience as a developer. So this article basically covers a UX and DX plus internal developer experience, and how they’re intertwined. So you’ve probably asked me straight away what’s DX. But it starts off by trying to define both UX and DX. Now I’m not going to critique the definition of UX, because we we know how difficult it is to to define, do that ultimate definition of UX. And he himself actually says, UX is really hard to explain. And he’s completely right. So we’ll we’ll park that there and won’t look into his UX definition.

But he, it’s the developer experience side of this that ignited my interest in the article. Now, Pierre says that developer experience, DX, is quite a new term in industry. It’s actually been around for about a decade, I think. But it seems to have gained a lot of traction in the last few years. I don’t know why. I mean, I don’t know if there’s…

Per Axbom
I have to admit, when you mentioned it to me, I wasn’t really aware of it. I may have heard it at one point or another. I didn’t realise people were talking about it.

James Royal-Lawson
Yeah, I mean, I said I think it’s the last couple of years. And I’ve seen it be mentioned in articles a bit more and been brought up, even by developers, I think that I would say maybe the younger developers I’m working with, they actually do talk about developer experience, quite casually now. So it’s definitely gained traction.

Well, what is it? Well, it’s the overall experience lived by developers, Pierre says. Now as they basically develop code, as well as the UX of specific services, where developers are the target audience. So here, Pierre gives the gives two examples of Stripe and MailChimp.

So the payment handling service Stripe, he says, puts the developer experience at the forefront. It doesn’t try and hide dev information away, because it’s it’s made for developers.

MailChimp on the other hand, they hide their dev stuff away. I think it’s on a it’s on a subdomain. And it kind of makes sense because MailChimp isn’t made for developers, not as the primary audience. And if there was too much, if the developer experience was too strong, when you were approached MailChimp, then that probably would scare away the primary audience. Yeah. Now the third thing he talks about,

Per Axbom
It actually makes me think that when you’re sort of a hybrid person, like you and I are, I sometimes struggle to find the developer information, because I want it I want the API codes and stuff, but it’s sometimes hard to find for me.

James Royal-Lawson
Yeah, I mean, we maybe have a different checklist that we we maybe look at different aspects quicker than the primary audience. Anyway, the other thing he talks about, which I think is this is really, really interesting is the internal developer experience. So Pierre uses this phrase to describe how it is to work in a project as being a developer. So, for example, how code is organised, how it’s structured, how you how you comment and document the code. So creating better a better experience for other developers maybe who will work with this or even even yourself in the future.

So this is not, this is not just using tools, services that are designed for developers, this is your experience as doing the whole job at that organisation, as a developer. And I thought this was just really interesting to think about, reflect on how few UXers I know or heard of that have worked with this do you know want I mean here now.

Per Axbom
That work worked with thinking about the developer experience?

James Royal-Lawson
Yeah, because if you think about what constantly developing all these websites, websites, and apps and services, and so on, and sure, we’ve got things like storybook and design systems, and what have you.

But when it comes to the actual understanding and research around the developer’s life, as a developer, we don’t spend much time using our UX skills to help them reflecting on projects, it’s normally like the developing team themselves that say, oh, we need to document in this way, or we need to code our structure, we need to structure our code in this way, and that way, they themselves come up with the insights and the response to what they’ve realised to try and make things better.

You know, think about, we were working agile, and you know, what needs to be improved next sprint, how can we kind of work better? This is generally reflecting within the development team, rather than using some of the skills, using more of the skills that we have to understand the experience, consider how it can be improved, helping implement those improvements and evaluating them.

If they are, I think when we were discussing which articles to talk about, I, you’ve said about how developer experience well, you know, it’s just user experience, because developers are a user. And you’re completely right, we could have, we could have anything “X”. We do have a fair few something “X”s already. But in this instance, it struck me that we don’t help out maybe as much as we should.

Per Axbom
Yeah, there was actually one piece of the article that jumped out at me, which I realised, here’s here’s some place where we could help a lot. When he’s talking about documentation, he’s talking about how the documentation needs to happen all the time. And it has to be ready at any time. And but he also has the phrase don’t over document.

Now here, that’s the real struggle, isn’t it that you need to document but you can’t spend too much time on it either. I see the same thing in healthcare, when you’re actually working on documenting your meetings with patients, you can’t document too much, because then the next person who’s taking over, won’t have time to go through it and it will be too difficult. But you have to get just enough for it to actually to make sense so that people can take over

James Royal-Lawson
Yeah. And this is exactly where our where our skills as your UXers would come in. Because you would, you do the research, you’d understand that developers need some kind of documentation. And then you then you look at the kind of documentation they have. You’ve then maybe analyse what happens that documentation, “oh, right now, oh, I don’t read it because it’s too long”. Okay. So then you’d maybe help them structure documentation or give them advice on how maybe they could document so that it would be more useful to those target audiences, which is their future selves, or other developers if you’re handing over to them.

Per Axbom
And you also need to be thinking in layers, why are you doing this? It’s to help the developers and why are we helping developers? Well, because then you create a better quality product. And what is a better quality product? Well, that is what we talked about just earlier, we talked about performance issues and stuff like that, that is actually affected by being able to produce a really good code, which is affected by how well it’s documented.

James Royal-Lawson
Yeah. And also, you’re hoping for like knowledge transfer, just one, potentially one short comment above a function in a clump of code might mean that another developer spots that when they’re gonna copy it to you somewhere else. Ah right, they did that because of that . And maybe then it it enlightens them into a reason behind something that possibly they would have just brushed aside or not even had any idea about otherwise.

Per Axbom
Exactly. And I, for me, it’s the same. We have the same problems and issues within UX in documenting designs and the reasons behind decisions. So again, we have a lot of experience in understanding that problem, and experiencing understanding how much should we document for it to be useful. Again, I mean this, this is a great example of where we should partner more also in the way we work together.

James Royal-Lawson
Yeah, because ultimately, ultimately, this impacts on a user. Yeah. And that’s what we care about. And I think also, this impacts back on us, because the developer teams we work with just like us, they’ve got a finite amount of time. So if they have a better experience while they’re working, then their work is probably going to be more efficient, which then frees up more time to do more things. So we have a kind of win win here. If we can help the developers with the experience that they’re having, then they can help us deliver a better experience further down the line.

Per Axbom
Exactly. And I kind of like when we talk about these these technical issues in this way, because there is this ongoing discussions always that pops up now with that not so much lately, but should designers be able to code? And I don’t want to get into that I want. But I want to say that maybe the question should be as designers, how well should we understand the material we are designing with. So if you’re working as a designer in clay, you kind of know that you can’t just take any piece of clay and mould it into anything. There are probably hundreds of different clay types, I’m assuming now, I have no idea that you can work with it. But if you’re a painter, there’s is different paint.

I mean, depending on what you want to accomplish, you make different choices with your material. And it’s the same thing here, the more we understand about our material and the different aspects of it, and how we can mould it differently and create different performances. That is important. Yeah. And it helps us and we can’t keep track of everything. And I think that was a point we made just earlier as well, we can’t keep track of everything. We just need to understand this complexity, and the better we are at understanding it, the better we can create fall-back solutions.

James Royal-Lawson
And you we wouldn’t, we wouldn’t try making a product for a healthcare professional without trying to understand the healthcare professional that was going to use it. And we wouldn’t, we shouldn’t and wouldn’t try making a developer experience without understanding the developers. But this doesn’t mean to say we have to be doctors and nurses and so on just to be able to make a healthcare app as a UXer.

So we don’t have to be developers to actually understand the experience the developers are having. And we’ve, I mean, we’ve talked before about how you know, communicating, articulating design decisions, which is a book by Tom Greever we talked about and that whole thing about how our job often is just facilitating or communicating to another person. And sometimes that person is a stakeholder, sometimes it’s a developer, a team member. And developer experience is just an aspect of that, of making that communication and understanding better for between us and them, but also for them to do the work.

Per Axbom
And remembering that empathy applies not to only to the end users, but to everyone on our team, every stakeholder because the better we can help everyone work together to better the product will be in the end.

James Royal-Lawson
I wonder if it will be a good idea to like next time one of your team says they’re going to refactor some code. Offer to sit with them. And you know, just just look and see how their their world. Maybe you can even give them some tips and advice straight away.

Per Axbom
I like that. We have some recommended listening for you, I think,

James Royal-Lawson
Yes, seven years ago, we looked into the question, what screen size should you design for?

Per Axbom
Did we answer that question?

James Royal-Lawson
Yeah, I think well, I think we came up with quite a good suggested process for how you go about deciding that. And looking back….

Per Axbom
Is it still valid?

James Royal-Lawson
Well, this is the thing that we took, I think we call that episode, James and Per move beyond 960 and 960 in some ways, seems quite a small resolution, screen width these days, but the process that we suggested, that still copes with it, that still works, I think

Per Axbom
Interesting. Wow.

James Royal-Lawson
So Episode 52 is our recommended listening and reading because there’s a transcript to that one.

Per Axbom
Thank you for listening. Always a pleasure. And a quick reminder, you can contribute to funding us podcast by visiting UXpodcast.com/support

James Royal-Lawson
And you can also contribute with your time so don’t forget to volunteer to help us with our transcripts and bits and bobs of our publishing routines.

Per Axbom
Remember to keep moving.

James Royal-Lawson
See you on the other side.

Per Axbom
James

James Royal-Lawson
Per

Per Axbom
Why did the web developers send a few extra bucks to his hosting provider?

James Royal-Lawson
I don’t know Per, why did the they send a few extra bucks to their web hosting…provider? I’m not doing very well,

Per Axbom
Because she heard that she should always tip her server.

James Royal-Lawson
Oh