E243 - How Human Factors Can Help Pilots Catch A Rocket Booster in Mid-Air

Welcome to Human Factors Cast, your weekly podcast for human factors, psychology and design.

It is Thursday night. This is episode 243, recording this live on April 28, 2022. This Human Factor's cast. I'm your host, Nick Rome. I'm joined today by Mr. Barry Kirby. Good evening. How are you doing? Hey, I tried to switch it up for the intro. I did. There was energy, there was dynamicism, and that's a big word. I liked it. And now it's going to taper off. We got a great show for you all. Tonight we're going to be talking about how a helicopter will attempt to catch a rocket booster in mid air. We'll also answer some questions from the community about the reality of what the day to day is like for a UX designer or researcher. We're also going to be talking about changing career paths to UX research and our thoughts on data driven personas. But first, let's talk about some quick community updates, programming notes, whatever you want to call it. Barry, what's the latest over 1202? Well, the latest over twelve two is that I've been finding a bit wanting this week because we were meant to be pulling together lots of material out of the Human Factors conference over here in the UK. So it was, EHF, 2022. Turns out that when you leave the box with only cables you can get in live material. But the community has come together and we will be pulling some interviews today and tomorrow. So there will be a new episode coming up with a montage of different opinions and thoughts about how the conference went, what people learned from it, and what they would like to see next time. We'll also have some coverage for you here on the Human Factors Cast. In the meantime, you always check out the latest episode over there. I guess we're at that part of the show where we talk about human Factors news. Is that now? Yeah, that's now.

Yes, human Factors news part of the show where we talk about exactly that. Barry, what's the story this week? So this week is going to be how a helicopter will try to catch a rocket booster in midair. So the longest journey begins with a single step, and that step gets expensive when you're in the space business. Earth's gravity is so stubborn that by necessity, two thirds of the rocket is in the first stage. And that first stage is historically ended up as trash on the ocean floor. After less than three minutes of flight, making those boosters reusable is clearly the dream. Spacex recently has been famously been landing its Falcon Nine boosters on drone ships, which is amazing and mind bending to watch. But actually, in reality, with the complexity behind it, is very hard to pull off. Rocket Lab, another company within the space domain, says it's got another way. If all goes well, it's next flight that's going to be carrying 34 satellites instead of being dropped in the Pacific. These spent first aid will be snared in mid air by a helicopter as it descends by parachute. It will then be brought back to base for possible refurbishment and reuse. This is going to be clearly going to be a complex maneuver. The helicopter needs to be in exactly the right spot. They need to know exactly where the first stages is and it's going to be and how it decelerates so they can catch it. They practiced each individual element and this exercise is all about putting together all the individual elements and making them work. There are no guarantees that it's going to work and it's going to be quite interesting to see if they can actually make it. Pull it off. Nick, are you into helicopters catching first stage boosters as they drop out of the air? Oh, wait. This is my favorite story. This is my favorite thing to do is catch rocket boosters out of the air. So really quick, just a quick update on this. I'm looking now to see if there has been any update. They had said it would potentially be April 27 through April 28. And to be clear, we are recording us on April 28. We're looking now on the Rocket Lab website live to see if, in fact, this has happened and it does not look like it has looked like now. They're targeting tomorrow, April 29. So this is still a developing story. We like to talk about these things after they happen, but it was planned to happen before the show anyway. There's just some delays. My initial thoughts, this at first glance is very cool. It seems like there's a lot of really complex things going on here, but as you and I had discovered or talked about in the preshow, it might be a little bit more simple than that. But Barry, what are your kind of initial thoughts here? Gut reaction. I really like it. I mean, people who listen to other episodes of the show know that I'm a bit of a SpaceX geek SpaceX fan, but where SpaceX has obviously done a lot of work around quite intricate maneuvers in getting landing onto a C platform and land platforms to get it to land in such a way that you could almost fire off against right away. This is taking a I guess it's cheaper, I guess it's more reusable and that type of thing. And so what they're doing, they're taking that innovation to the next stage. How do they take something that has kind of been done it's in a way, but actually making it cheap, making it more effective, making it so that it is a different way of playing with it. And it will be interesting to see if they can pull it off because I think it is a complex thing to do. You're playing around with situational awareness, you're playing around with a changing environment. But fundamentally, this should make Space more accessible. Yeah, it's a different way of doing the same thing, but for cheaper and. Yeah, for cheaper. I mean, look, like, I hate to put the cart before the horse, but I almost want to talk about the solution here and what's happening, because the way that I wanted to approach this episode was like, let's look at human factors in helicopter transportation and helicopter culture and all that stuff. And I think it's a good springboard. It's something that we haven't really talked about on the show before and so it's good to talk about. But I think, yeah, let's talk about the solutions. Essentially, they're grabbing a helicopter and catching a parachuting rocket with a sky crane.

Why don't we start off just by quickly outlining what they're expecting to do. So the Rockets called Electron, they're going to do this Electron launch, which has done loads of stuff before. It's 80 meters tall. The first stage Rockets are about 12 meters tall, so that's quite a decent size. It's going to take off from New Zealand. The first stage Burns out after about 70 km and that's about two and a half minutes into the flight. So it will drop off and following along arc. And we've all seen that. I think most people have seen that. That's what I think. I'll tell you where it does descend quite comparatively slowly. You can see that happen. But now they've equipped them with heat shielding because he obviously reached quite a hot temperature. At about 13 km above the Earth, a drug parachute will deploy and then followed by a main shoot at about 6 km. And the time between that 13 and six is about 60 seconds. So that slows the rocket substantially. So that rocket will only be descending at about 36 km an hour. It still feels quite weird to say 36 km an hour is slow. So then what they're going to do is they're going to have a helicopter going and using the helicopter to go and catch this rocket that is descending on parachute. And so what they're going to be doing is using a grappling hook on a long cable, which does sound like it's something a bit out of a Bond movie. So the plan is for the helicopter to fly over the rocket. So over the top of the parachute snag the parachute cables, the parachute lines in this trailing grappling hook, the rocket should never get wet, the rocket should never get in the water, it should just be lowered onto a ship or back on land. And so that will then make that all reusable by the fact that you've got no salt corrosion on the rocket or anything like that. That's where the value of this comes into play. And you think with that, I don't know if anybody is YouTube. I know I have because again, Geek, the amount of failures that SpaceX had in doing in landing on its drone ships, there was lots and lots and lots and lots and lots of failures before the success. And now they have, more often than not, they have success. Whereas this actually sounds really simple, comparatively simple. The pilot's got to fly over. We could talk about whether this is a cited or an unsighted catch. How do they manage that? What other skills are they employing that they should already have? Right. But there's no new technology into the Rockets themselves. It throws a parachute, it doesn't have to renavigate itself back to Earth. It doesn't have to work out where it's at. It doesn't have to re fire its Rockets or anything like that to get the right attitude. It doesn't have to coordinate with a drone ship so it doesn't have to navigate anywhere. The more I talk about actually, the more it is quite exciting. It is exciting. Yeah. Don't get me wrong, this is exciting. This is exciting. It seems like maybe it's just to me, the solution is so basic isn't the word that I'm looking for, but it's just so practical that it just feels like, why didn't we think of this before? Especially when you do consider all those added costs of the salt corrosion and everything, the littering of these rocket boosters on the ocean floor. I think you're absolutely right. There's a lot of excitement around it for sure, for you and I even. It's just the solution. So simple, catch a parachute attached to a rocket with a helicopter. And if you're looking at the thumbnail for this episode, it's exactly that. I guess from looking from the human factor perspective, the big skill here is obviously in the pilot or the crew of the aircraft. So they use the Skorsky to do that and they're going to hang a long cable underneath with big hooks. Fine. Okay, so that feels like that's all commercial, off the shelf stuff. A lot of pilots now, particularly if you're using the big helicopters. So she looks at the same. Pilots are now trained to be able to undersling loads, to be able to drop them on and off. So having something slow underneath the helicopter is not new. So again, they're reusing ideas and skills and training that should already be there. What I've never seen is and it might just be just because I haven't seen it. Is a helicopter flying unsighted effectively over a parachute or something that's descending. So this parachute is going to be dropping at 36 km an hour because that's too fast. So the pilot is going to have to go over the top of this or intersect it in a way that they can snare it whilst it's still dropping. Make sure he doesn't get too close to it. Because if they get too close to the parachute and they intersect with it, worst case with the rotor blades, then that came over. That's not happening. And how many chances do you get at it? Because if you miss one. Then you've then got to get lower altitude, quickly resight it back onto it, and then fly over it again. Presumably, it's not just going to be the pilot themselves. They would have like a load master load crew citing it for them. But that's still good. Then. Now we need to communication issues. How do they make that work? It could be quite an interesting thing to see. And if it was me, I'd then be also having another helicopter alongside it, just taking photographs and video. Oh, yeah. Which presumably they're going to do. So take that first task. How do we think the pilot and the crew can get their situation awareness to a sufficient point to be able to do this in a one grab? Because I'm thinking that I'd want to have a camera underneath to be able to see some of this sort of stuff. Ideally, as a pilot, you'd want some sort of display that on your flight radar, that you have some sort of interaction with the booster because you need to understand your position horizontally towards where it is. Not to mention you obviously got vertically as well. But yeah, I think it's exciting. It is, right? Yes, you're right. There's a lot of different tasks going on, and I imagine some of this is proprietary, so we don't know exactly what's going on. But there's likely some sort of way to monitor your distance to the target, your distance to the parachute, really. In that case, how far out the grappling hook is. You also want to manage that with the distance away so that the Rotary blades do not interfere with either the parachute and set it off course or you want it far enough away so that the grappling hook is stable and not swaying in the wind. There's a lot of stuff going on, and I'd imagine that the training for this looked very similar to okay, let's pick something up off the ground where you're kind of stationary. You're picking something up off the ground. Right. That exists today. That's probably the training for that. And then now let's try it with a moving object. Let's send something down in a parachute and see if we can Hover over it and catch it. And we've also done the rocket thing, too. We've done that. So let's just try to do it all together. Yeah, go ahead. The beauty about doing this in the helicopter, I guess, is because you can Hover if you know the trajectory that it's coming down, because hopefully it's coming pretty much straight down. You could be hovering over to the side of it, because when you come land a helicopter or tilt rotor, faster aircraft such as like the F 35 or whatever, you tend to come and fly alongside whatever you're landing on, particularly if you're going to land on a ship or something, you would go to the side of it. So you don't go to the side of the pilot who's in control and then effectively slip over to the deck and land it. Now, there's nothing to stop you using that technique as well at height. So if you're hovering, Lovie, you're sat in the right hand seat, the thing falls down past your window as you see the parachute go past you over. Because I thought it may be something that you'd fly straight at this thing, but maybe you don't. Maybe you do it on a sideways perspective. That would be massively dependent on whether. Absolutely. So back with now that's taken us full circle back to the skill involved in what sounds like a really simple maneuver, comparatively, is actually we've again compare and contrast between this and the SpaceX solution. The SpaceX solution is very technologically complicated, but from a human perspective, I guess fairly simple because it's all automated and it either works or it doesn't. This solution is sort of technologically simpler because less automation, things like that, but much more reliant on human skill. Wait until they get drones to do this. Just a different way to do it. Just get a drone helicopter, throw it out there. But, yes, thank you, Barry, for doing that transition, because I think it is a good time for us to revisit some of these human factors of helicopter flight. Right. Like, there's a lot of different things, different ways in which we could approach this. I think we can kind of go over some of these major human factors concepts in aviation, which are pretty standard things like instrument design, crew training. You already mentioned a couple of these crew interaction, safety oversight. You also have things like psychological factors, fatigue and distraction. Then you also have a couple of different ways in which, I don't know, offshore transportation presents its own issues. You want to talk through some of those? Yeah. So offshore transportation is getting people out to places, things like oil rigs and things like that. Use helicopter transportation because of the nature of what they do. They go where other aircraft can't, which is kind of what we talked about earlier. But by the very nature, they can go where the aircraft can't. The safety issues are therefore amplified because the environment that they're flying in. So flying to and from offshore platforms is a serious area of concern. The climatic conditions of some of those world's major energy production systems require night time flights, such as over Norway. We have them over here in the UK. You have them in the US, Canada. That means routine flights. Integrated visual environments is a normal thing to happen. And as the existing reserve dwindle, exploration is taken place even further and further offshore and into even more hazardous environments, which means more time flying over more remote stretches of sea with variable weather. Weather, certainly around the UK is terrible. So therefore, understanding and preventing accidents in offshore helicopter transportation will become more important over time. But using them skills to link it back to the article. It's them sort of skills that we're going to be using to randomly catch Rockets falling out. The especially when it comes to things like the weather. Right. You brought up weather. Weather conditions are why they've been pushing this aside for the last couple of weeks, because they didn't want to test it in an environment where they didn't have as much control over the variables as possible. And then you also have the whole flying in degraded visual environments. And so that is, of course, nighttime flights. And you can't see a rocket coming at you from above. Is it going to hit you? It's dangerous. And so there's that to consider, too. Some rocket launches happen early morning when it is dark. And so that's also something to consider if you're trying to launch something. Is it going to be daytime? By the time the rocket comes back down? It's only a couple of minutes. So you're also working within the windows of being able to send a rocket up. So you have to consider nighttime launches. In a lot of cases, we are bringing this up in terms of like the offshore oil rigs. I think it's a fun look at how this is all working. And we brought this up, obviously, because you're over the water as you're catching this, the rocket. Sorry, wrong story. Look, here's the thing, though. There's an Oil and Gas UK report that said basically this offshore transportation accidents between 1991 and 2000. I know we're looking at like 20 years ago, but it came down to two things where you're having this introduction of new technology, ie, better helicopters and introduction of several significant safety initiatives. So again, trying to think about some of these safety initiatives that happened early, what, early 90s to 2000s, thinking about all those things in place which were meant to serve the human and to reduce the number of errors, all these accidents sort of reduced over time. We can think about this from the technology perspective as we think about the solution to catching a rocket. You're not adding really anything new. The technology is exactly the same. The processes and procedures by which are mostly applicable from other areas, you're now just using them on a falling rocket. And so all this stuff together, you're looking at nothing new, which I think is

the nothing new comment is not a bad thing. It's a good thing in this context, because now we don't have to relearn new skills or work with new technology or follow new safety protocols. I'm imagining a lot of that stuff is already in place. You know, more recent study, 2001 to 2010, human factors were the leading single cause of saving from offshore accidents. So when you set aside, I guess, human factors issues, we're the most cited cause. When you set aside things like climate or weather or technology, anything like that. If those didn't go wrong, human factors issues were prevalent and therefore we're more likely. And so it's really important to put some emphasis on that as an area when you are dealing with catching a rocket booster at a midair. Okay, let's talk about Shell. Who is Shell and what does she do? Barry? So you must join this Harry researcher was renowned for his way with words. So two paragraphs he wrote on helicopters in 73 have hovered around, excuse the pun for many years on the internet. So he said the thing is helicopters are different from airplanes and this is what work was talking about in highlighting. An airplane by its very nature wants to fly and if not interfere with too strongly by unusual events or an incompetent pilot, it will fly. A helicopter does not want to fly. It's maintained in the air by a variety of forces and controls working in opposition to each other. If there is any disturbance in the delicate balance, the helicopter stops flying immediately and disastrously. There is no such thing as a gliding helicopter. That's why helicopter pilot is such a different being from an airplane pilot and why in general airplane pilots are often open, clear eyed, boiled, extroverts and helicopter pilots are broodrs, introspective, anticipators of trouble. They know if anything bad has not happened, it's about to. So let's leave aside the idea with the gliding bit of whether auto rotation is applied or a controlled fall. But it's clearly onto something. These words get quoted time and time and time again. And actually I've quoted them in reports myself. The whole different nature behind the two different type of pilot I think is really interesting. Anyway, the whole point about Shell with this is the ICAO uses the Shell acronym. So SHL is Software, Hardware Environment and liveware and as a model to represent various components of the human factors make up of this. This can be expanded to Shell as in S-C-H-E-L-L. So Software Culture, hardware, Environment, Liveware and that's individual human liveware and liveware as a teaming element between humans. So I think it's probably worth having a quick canter through the Shell model because there are some really interesting things here with respect to helicopters. So do you want to kick us off a bit with the software side of things? Oh, I got to start with this. Okay. Software is pretty self explanatory. It is the way in which basically you are working with a machine that supports flying operations, whether that's rules, procedures, checklists, written documents, all that stuff. Basically, when you are looking at the software, some of this stuff is regulated and some of it is not. And so there are things to consider there and there can be often a lot of human factors issues when it comes to software. So we've got to make sure we get it right. When you look at helicopter operations, some are regulated by Casa and helicopter companies are required to have operating manuals, etcetera. So there's like some requirements in place. You have to have a manual or else who else is going to know how to fly it? And in terms of fundamental differences between helicopter and fix wing software issues, there really shouldn't be any fundamental differences other than the fact that you're operating a different vehicle. And that really comes down to the fact that we're kind of taking this safety and air safety seriously. That's I guess what the difference is here is that there is no difference. We're taking safety seriously. Let's talk about culture, Barry. Yeah. So the culture that all involves norms, the customs and practices, conventions and habits, and that's all stuff that occurs outside state. You send operating procedures and regulations. The SPS and regulations give you a set of behaviors and ways of working. But the culture is everything else around that you've been somewhere where they've turned around and said, it's the way we get things done. It's what we do on a day to day basis. It's how we act. It's what occurs to get the job done under pressure and what people fall back on. It might be specific to the actual flying task, but it's also what you're experiencing in the crew room and when you're planning, when you're hanging out together. So if you got a poor culture that's seen in the crew room or socially, that could be an indicator of actually a poor flying culture. Poor culture will also develop with substantial leadership, sorry, substandard leadership and supervision and can lead to deviation from software, including violations. Even I said right at the beginning, this should be beyond the operating procedures and regulations. If you have a poor culture, it will lead you into causing violations and actually going against standard operating procedures. The helicopter industry has seen poor culture in the past, and the issues may also be structural. Pilots are often away from supervision for long periods because the way that we work with people from different cultures and similar cultural interactions may be found in fixed wing, whether it be looking at fire bombing operations or remote fixed wing charter operations. So the young must wing helicopter pilot may have to be more aware of the influence of culture than their peer in a fixed wing charter pilot. It's a difficult thing to deal with because culture is something that is around you all of the time. It's something that is part of the company culture. It's something that is not only top down, but it's in between everybody. It is continuous, so it makes it hard to notice, but you really notice it when it's either gone wrong or you're coming into a new organization. So that's why from a human factor perspective, we highlight culture and try and work on culture because of its pervasive nature. Do you want to talk us through some hardware elements? Yeah. So hardware is kind of the counterpart to the software. The hardware is the physical stuff. So the helicopter itself, the controls, the interfaces, the cockpit layout, all that stuff, human factors 101, a lot of it. So the hardware itself might be very simple in like fly by wires type of situation, direct mechanical controls. Or it could be a larger helicopter, like in this case, where you have sort of a hydraulic boosted control mechanism or some stability system through an autopilot assistive technology, that type of thing. If you're looking at a large helicopter, some of those flight control systems can actually be more complex than your typical airliner. You might have a bunch of different displays and controls to work with. The displays themselves could be simple, conventional round aisles like you might find, or it could be these large flat panel displays. They really vary, and they all come with their own sort of pros and cons here as human factors practitioners. And it's kind of our call to make on which one is going to be most effective in that situation. In terms of external load helicopters, the critical engine instruments may be replicated below the side window to allow the pilot to monitor the load without actually having to look away, check for engine performance. So that's one of the considerations I bet is taken for this type of rocket booster recovery mission where you have this. Some of the instrumentation might be replicated as they're looking down over the load. So that's something to consider. You also have night vision. Of course, we talked about that stuff, and yes, that's about all I want to say about that. Let's talk about environment because we talked a little bit about this. But where does human factors come in? Yes. So with the environment, we've got to really consider that the environment that we're operating in. So that's from the basics of temperature, humidity, noise of vibration, noise of vibration with an aircraft is really important thing to be able to understand what is vibrating because you're in a platform that is vibrating or what is a vibration that you're unaware of. But then you've got things outside the cockpit. So the weather, the sun, moon, terrain, landing area, all that sort of stuff like where are you going to be? Because you've got to be really aware of your environment in helicopter because you've effectively got that ability of 360 maneuver and a 3D maneuver. Whereas in a fast jet or in any sort of aircraft, you tend to move forward, up, down, left, right. But you tend to always move in one direction. Helicopters tend to operate at lower altitudes. Not all cockpits are air conditioned, so heat simple thing, but makes it really uncomfortable flying environment, the cockpit can operate with the doors off for better visibility, and that wind chill can become a factor as well as just general safety as well. So they're often noisy experience way more vibration, as I've already mentioned, than fixing aircraft. And the advantage of a helicopter as we mentioned earlier is the ability to Hover and land vertically. That's a huge advantage. It means that they do operate very close to terrain, and the land insights may be unsurveyed. So sometimes you don't know what you're landing into, and therefore you have to have quite a sensitive control through the hardware to be able to get there. And that's even before you get into the idea of where you're landing, you might have unexpected things, like when the military been landing in desert, you get the sand whips up, so you get Brown out, or if you're landing in whiteouts with snow. So, yes, there's a lot around the environment that can cause you issues within helicopters. What about life where people that's really not important for human factors. Let's just get that. I'm just kidding. So look, there's a couple of the way in which this model separates it. There's liveware with the individual human and then there's liveware between humans. So let's kind of talk about them. Right. The individual human. There's obviously some things that are internally driven that we need to look at, like fatigue, stressors, those types of things, which a good tie back is how the F 35 tried to kill his pilot. Go check that episode out. That was a really great one to do. But I think there's a lot of different other things that are going on with the individual, too. You could have, like aeromedical disorientation illusions. One that's specific to helicopters is flicker vertigo. So the light that's coming through the rotor blades creates kind of a strobe effect, and it can cause disorientation, vertigo, nausea, all that stuff. And in extreme cases, it can induce seizures, which is no good. And so there's hardware that introduces other sets of limitations, like increased fatigue or unique optical illusions, integrated environments. Now when you think about between them, between humans, that is like crew resource management. It's almost like a subset of culture in a lot of ways where you are looking at humans external to the aircraft, like air traffic control or support staff. So probably the people who are in the other helicopter taking pictures saying, hey, you're a little bit off. Correct. By going forward or by rotating left 45 degrees or whatever feedback they're giving. And so it's different in a helicopter versus a fixed wing aircraft, because

when you come back, you're thinking about different clearances for landing, not just a straight path, but something tighter. And then obviously in a low level helicopter environment, there might be a unique set of live wear interaction required between individuals to complete the tasks safely. This would manifest itself in the article in actually putting this thing back on the ground. I think that's where you'd have a lot of communication with ground crews. And so I don't know, it's kind of a cool model to go over shell. It's kind of cool to talk about a helicopter. And we brought in a lot of examples about what a helicopter human factors are and what a helicopter human factors are. But what I'm trying to say here is that I think we covered our bases, and I want to pass it back to you. Barry, any other key takeaways that you want to discuss in relation to shell catching rocket boosters with helicopters? Anything else? For me, it hits three different things, which I think are really exciting. Firstly is around the whole situation awareness piece. So how do you know where as a pilot and as a crew, how do you know where you're at, Where's the rocket out? You've got that dynamic movement between the two. They're not fixed. So you're going to have to be able to coordinate the two and basically bring in some human skill to make that happen. The risk appetite of the organization willing to do it, that's a behavior and cultural element there to be able to look at this and take something that is being successfully done by one company and try and come up with a cheaper version of it that's basically going to undercut that and progress technology further. But then that just takes it all down to experimentation. I think this is going to be we've seen what SpaceX did and how much money they literally burnt trying to get this to work. Is this going to be something that will get quicker access to market? And are we just going to now see a whole new skill set for helicopter pilots who maybe come out the military or something like that to be able to then go and fly around with big hanging hooks under their helicopters to be able to go and catch moving targets? I can't wait to see the result of this and whether it actually works. Yeah, I'm looking at the little diagram they have. If you get a chance, go check out. They have a little press kit that you can check out that has a diagram of how this is supposed to work. And it's really a delightful little diagram. Anyway, thank you. That's our new story this week. Thank you to our patrons for selecting it. And thank you to our friends over at IEEE Spectrum for our new story this week. If you want to follow along, we do post links to the original articles on our weekly roundups on our blog. You can always join us on our discord for more discussion on these stories. We're going to take a quick break, and then we'll be back to see what's going on in the human factors community right after this. Human Factors Cast brings you the best in human factors news interviews, conference coverage, and overall fun conversations into each and every episode we produce. But we can't do it without you. The Human Factors Cast network is 100% listener supported. All the funds that go into running the show come from our listeners. Our patrons are our priority, and we want to ensure we're giving back to you for supporting us. Pledges start at just one dollars per month and include rewards like access to our weekly Q and A with the hosts, personalized professional reviews and Human Factors Minute, a Patreon only weekly podcast where the host breakdown unique, obscure and interesting Human Factors topics in just 1 minute Patreon. Rewards are always evolving, so stop by Patreon.com Humanfactorscast to see what support level may be right for you. Thank you. And remember, it depends. Yeah, huge. Thank you. As always to our patrons, we especially want to thank our honorary Human Factors cast staff patron Michelle Trip patients. No patrons like you keep the show going. Literally keep us running, lights on in the lab, all that stuff. And thank you so much for your support. I do want to talk about Human Factors Minute. Now this is a little something that we do over here for our patrons. If you're unaware, Human Factors Minute is a little slice of Human Factors that we package up and we highly produce and we do our research and we send it off in your Merry way so you can enjoy it in 1 minute or sometimes more than that, but oftentimes more than that. But we package it up so you can enjoy Human Factors content on the go, so to speak. So we have some fun stats that we like to revisit from time to time regarding Human Factors Minute. Barry, would you like to take a guess at how many Human Factors minutes we have? If I pluck a number at the end, maybe, I don't know, around 120, maybe. Oh, you're looking at the same notes I have. Yes. We have 120 episodes so far, total runtime across all those episodes, which you would think would be 2 hours. We're actually at almost two and a half hours, 2 hours, 27 minutes and 40 seconds. Average length of 1 hour and 14 seconds. Our longest episode was our episode on the Surface Transportation Technical Group for HFES and then also for HFE tag, there's a system safety, health hazards and survivability. Those both clocked in at 1 minute and 59 seconds. So look, here's the thing. If it doesn't have 1 minute in it, then it's a separate piece of content. But we managed to get those in with one as the leading number. So that's kind of the cutoff for us is 159, so you might see a couple of those. Anyway, shortest episode was on the Aging Technical Group, and that was 40 seconds long. So you can kind of get a sense of the distribution, get a sense of the topics there. It's something that we're actually really proud of. And if you want to see our lab working on stuff, we have a lot of our lab members actually doing the research on Human Factors Minute to keep the lights on. And that's one way in which they contribute. So they do other things, too. But that is kind of an everybody task to make sure that the lows lights are kept on because it's quite important. Anyway, let's go ahead and get into this next part of the show we like to call.

Yes, it came from. This is where we search all over the Internet to bring you topics the community is talking about. We ask that if you find these answers helpful, no matter where you're at, just give us a like help other people find this content. We have three today. The first one we're going to tackle here is what is the reality and day to day like for a UX designer or researcher? This is by Ten Pumps classic on the user Experience research Subreddit UX Research subreddit sorry. They go on to write what is the reality and day to day like for a UX designer or researcher? I recently applied in the midst of interviewing for a certificate at my local community College to study in UX centered around UX design, although I believe there will be parts of user research built in looking for a snippet a snapshot of your day to day as a UX designer or researcher. What are you using? What tools do you need currently work in? Okay. Anyway, so we'd love to generally hear about your experience as this is a potential path I would like to pursue given the opportunity I have right in front of me in advance for your insights. Barry, your role is not research, it's not UX researcher. But what is your typical day to day like and how might that differ from a designer? Do we have that? It depends, but I think we hit that one here because I don't think I have a typical day to day, literally from everything that we get involved with. It could be running workshops with clients about what they're trying to get out of running workshops with users to try and get progress design, running agile design workshops, or just getting down with nitty gritty and working through design development in terms of tools that we use it's whatever is most appropriate for the time, the amount one day we could be using something like Figma in terms of developing some really in depth things like that. Or we back on pen and paper or I've recently become quite partial to a five Postits, a five size posted. I do a lot of work on posted. That's probably the biggest thing I burned through, but I've found a five large color posts and they are amazing on because they can stick to most walls and stuff well, not yet, but maybe they should be, but to be able to use them sort of thing, they end up being quite flexible and you can sort of sketch things out quite nicely on them and make that work. So generally this is quite a hard question for me to answer because I don't have a typical day and that's part of the fun proof for me. It keeps you entertained. And if you start having too many days the same, I get bored. What's your experience in this? So let me be clear. My title is Senior User Experience Researcher. That is my title. So I feel like I am capable of answering this. Qualified. I am qualified. Look, here's the thing. What Barry said is correct. There is no typical day. However, I'll give you a formula by which you can operate on. There's a couple of things that can be happening at any given time, depending on where you're at in the design development research process. Right. So depending on what project you're on, you might be in the user research phases. You might be translating that research into designs. You might be working with PMS and developers to ensure that those designs get coded into software correctly. You might be working to test that stuff that has been in design for a while. And then you also might be at the other end where you're planning research. There's some context that's coming up that you want to understand what you need to do next. And so my formula is this. Pick any one of those. And that's kind of what your typical day looks like depending on that process. Now, it really gets interesting when you start mixing and matching. So I'm not just on one product sort of track or anything like that. I'm spread across several. And so there's many different levels of research going on at the same time. And so my day looks like a little bit of this phase where I'm looking at the research that needs to be done and a little bit of this phase where I'm talking to designers about solutions on another thing, and a little bit of this phase where I'm organizing times to talk with people and you kind of stack those up. And because of that mixed match of where we're at in the process and other things that need to happen behind the scenes, like setting up research infrastructure, which happens from time to time where you need to create, I don't know, Excel spreadsheets that contain data and all that stuff. It really depends on where you're at in the process and you mix and match those things. You'd be good enough. Answer tools. I don't know. It doesn't matter. You find something that works for you. Really, it doesn't matter as long as it works. The pen and paper is probably best you could do. I use Google Suite because that's what my company uses. It really just depends. All right, next question. I want to change my career path from traffic engineer to UX researcher. What should be my plan of action? This is by Alberta Key. I feel like I'm not saying that right on the UX Research subreddit. Hello, everyone. I'm a mid level traffic engineer with a master's and PhD degree in transportation and highway engineering. I like to know what skills I need to develop to break into UX research, and then they go into a brief snapshot of current skills. Some of it's relevant, some of it's not. Barry, let's talk, though. How do you break into human factors from another, let's say, tangentially related domain? Yeah. What I find is that quite a lot of people break into human factors from the engineering side of things. I know I did it myself. Quite a few other people have done it in many ways. I don't know if there's one suggested is do you go and get another Masters in HCI design or something like that. That's definitely an approach. If you got the time, effort, and money to be able to go and do that, then that's great the way I would do it, because you've already got your PhD, you know, you know how to learn. That's all cool. But actually what you want to be doing now is going to get yourself immersed in the environment. So either go and find maybe either a different role or either a paid role or a volunteer role to go and do that. I think some people have got a human factor lab somewhere that might be an obvious place to go and look at some experience of it. I'll go and do some voluntary stuff and see whether you do like it fundamentally. Actually, the best thing you can do, if you can get it, is to be employed to do it. And so if somebody is willing to give you a job either within the company you're in and you sort of say, look, if you're doing this traffic engineering, if you talk to the senior management said, look, I'm interested in doing this. Can I do a project that uses the skills that I've got but then also uses them and applies them in a human facial, stroke, UX environment? Then you'll do a transition. That's effectively what I did. I was employed to be a software engineer in a cockpit team. And then I was like, oh, I like this designing of cockpit stuff that's really exciting and ended up not doing any software with them at all. Basically got into this and then it sort of balloon from there. So, yeah, there are a number of different routes education, but I think with where you're at and saying you've kind of done the education formal, but I don't think doing the master is going to help you. I think you need to go and do some actual work and to try and find an opportunity. Yeah, I skipped over the skills here. I'm going to bring in a couple because I think understanding what skills you have that are transferable and understanding how what you have done already kind of emulates the type of work that you will do as a human factors practitioner or UX researcher is really important. So to recap some of their skills comprehensive knowledge on research processes, including lit review experiment, design questionnaire and survey development, data analysis and interpretation communicating research findings to technical and nontechnical audiences extensive research experience in traffic safety and driver behavior analysis, published several Journal articles, conference papers, technical reports, and one book chapter I think that's a ton of applicable skills. All you have to do is change your job title from where you're at right now and say, I've done a lot of the stuff that UX research does, and that sounds very reductive. You'll learn a lot on the job. But if you already know a lot of these skills, if you go and just like, I don't know, look up what UX research does and understand the process and how you sort of integrate with a software team if you're trying to get there, I don't think it's so far out of left field that you wouldn't have a hard time finding it anyway. That's just my two cent look at the transferable skills. The only thing I would add to that is read a book on agile, because actually with them skills with agile, then you'll be well ahead. You're good to go. All right, last one here is by Shorts. Okay. On the user experience subreddit. Our user personas for journey mapping, usually arbitrary, are based in data. Sometimes when looking at other people's personas for products and applications that have a very broad audience, I fail to see how having two user personas is useful. When it doesn't capture all the users, it feels like fluff rather than useful data. Can anyone provide clarification for how and why it's useful? Barry, let's just talk about personas. How do you use them? Do you use them? Is it useful? What's up? Yes, I love using personas. I think they're such a valuable and powerful tool if you get them and use them in the right way. So the way I use them is the way you've got loads of data and we talk about target audiences and things like that, where being 50 percentiles and all this sort of jobs. But actually when you're actually delivering and talking about a solution to particularly stakeholders or the other users about why you've done something, if you just talk about the well, I've got a user and they could be anything from this height to this side, this sort of reach, and we abstract out the we don't feel like we're talking about actual people if you can actually get the averages of all of them. So this is where it's actually somewhat based on useful data. It should be based on your target audience description, what your range of metrics are. But also you get some characteristics. So how old are they? What sort of stage are they at in their careers and things like that? And that fluff as they describe it. It's all about making them feel like and look like a person. So you're not talking about a random user anymore. You're talking about Bob or you're talking about Mary or you're talking about Phil or you're talking about Jackie. You give them names, you give them personalities. So they actually feel like you're designing and developing and testing something for somebody, not just a thing. So, yes, I can see why they might feel and seem like not very useful. But actually, I think they're one of the most powerful things we have in our toolbox. That is so interesting to me because we rarely disagree, Barry. And I think that the fluff part of it is the least interesting part to me. I tend to create personas based around, yes, data, but I very much put them into their own roles. So they're like role based personas. Right. So we still attach things like Jim from accounting, who makes this much a year and all that stuff. If it helps somebody, fine. It doesn't help me. The things that help me are things like what challenges are this person experiencing? And why is the thing that we're designing going to be a solution for those challenges? What are their goals? What are their key tasks? Those types of things are tremendously valuable for me. And if we can get those from an average of data and that's now you're looking at like a qualitative analysis of a bunch of different text fields, really, that's your job to kind of pair that down and say, okay, yes, this is what we have. These are the themes in which they are experiencing these problems through. And anyway, that's it. I think people find value in different things. And for me, it's more of the procedural. How do we capture that? All right, that's One More Thing. That's just where we talk about One More Thing. Barry, what's your One More Thing this week? I went to conference this week. You did amazing. It was so nice to be able to get in a room with people and just have a chat and a catch up because it's all very well. All the stuff we did the virtual conference for you a couple of weeks earlier, which was nice. It was good. You got all the information. But this was all around for me. I want to be geek about the nontechnical skills. It was the be able to have a bit of a laugh and catch up and know what you do with yourself now and looking at other people across the room and say, oh, I haven't seen that person in ages. There was a couple of people I went up to who I was like, oh, how are you doing? And they were like, do you realize we've never actually met the past two years? We've talked online and Zoom and stuff, but we never actually met face to face. And there was a couple of them there that I was like, I didn't even realize. I was like, oh, yeah, I don't know whether I should be embarrassed about that. But at the time I was like, oh, yeah. Okay, well, that's fine. It was just weird from that. It was weird. Bizarre, but brilliant. Did you get anyone coming up to you saying, oh, my God, you're Barry Kirby from that 120 two human package podcast? I did. If I had more than one person coming up saying, I listened to your podcast, I really like it. So I was like, I'm just sold. And if I'd had my stickers, they would have got a sticker. But I'm a sticker because they're in a stupid case. Back in my stupid house, I was going to say, were they in the case? They were in the case as well. Everything was in the case. But no. In fact, a couple of them who expressed delight in listening to my podcast where I'm going to be interviewing them tomorrow, so they get their opinion. So very exciting. Anyway, enough about me talking. Actually talking to real people. Nick, what about you? So listeners, long time listeners of the show, know that I have a 3D printer. We recently moved within the last year, about a year ago, actually. And since then, it's kind of been in not storage. It's been out, but not put together. I recently put it back together because we're starting a new project. It's a helmet for my son. We're going to a Star Wars conference. It's worth convention, sorry. Next month. And we're putting a costume together for him. So I 3D printed a helmet. It sits on him. And now I'm in the stages of all the sanding and finishing, and it's a ton of fun. Yeah. I don't know if you want to see more of that. Come Ping me on Discord, but that's going to be it for today, everyone. If you like this episode and enjoy some of the conversation about helicopters doing unique things, I'll encourage you to go listen to episode 203. We talk about the challenges of flying a helicopter on Mars and always comment wherever you're listening with what you think of the story this week. For more in depth discussion, you can join us on our Discord community. Reach out to us. We're always hanging out there. Visit our official website. Sign up for our Newsletter Stay up to date with all the latest human factors news. If you like what you hear, you want to support the show. A couple of things you can do. One, you can always leave us a five star review, free for you to do, and really easy, quick. Feel free to. And then two, you can always tell your friends about us. That way, they come up to Barry at conferences and say, hey, you're the guy on that podcast. Three, if you have the means and want to support us financially, you can always support us on Patreon. All those go back directly into the show, into the lab and help our lab members create some beautiful things. And as always, links to all of our socials on our website or in the description of this episode. I want to thank Mr. Barry Kirby for being on the show today. Where can our listeners go and find you if they want to talk to you about being caught by a helicopter helicopter? Find me on Twitter bezel K LinkedIn of the BP Kirby or come and listen to travel to the Human Factors podcast where we have interviews with interesting people@twelvepodcast.com. As for me, I've been your host Nick Rome. You can find me on our discord and across social media at nickrome thanks again for tuning in to humanfactors cast. Until next time it's depends.