Kate Holterhoff, industry analyst at RedMonk discusses Frontend & Prototyping with Stephane Rodet, UX Engineering Manager at IBM. Rodet shares his experience working with the frontend, design, and UX teams at IBM. We discuss trends in this domain in terms of career opportunities, team roles, testing, and tooling. The landscape of frontend and prototyping is shifting fast, and Rodet explains how IBM fosters creativity and innovation in this space.
Transcript
Kate Holterhoff: Hello and welcome to another RedMonk Conversation video. My name is Kate Holterhoff, industry analyst here at RedMonk, and with me is Stephane Rodet, UX Engineering Manager at IBM. I’m thrilled to have this opportunity to discuss frontend development and design with Stephane today, as this is a subject near and dear to my heart. After a stint in academia, I worked as a frontend engineer for several years before transitioning to my current role as an analyst. I understand you’ve worn several professional hats as well, Stephane, will you tell us a little bit about your background and how you became interested in design? What was that journey like?
Stephane Rodet: Hey Kate. Well, there’s quite a bit to unroll, let’s try to make it short. I started quite a while ago at IBM after making a university exchange, and so I started funnily as a backend developer on the mainframe. So I was actually building a component that managed the processing capacity and so on dynamically on the mainframe. So it was a very cool, super interesting topic. Far, far from the frontend, actually, but we had a desktop app that actually managed the software. And so I was assigned as the first assignment to actually test this desktop app. And so I opened so many tickets that for the next iteration, they put me on the frontend team and they were like, Stephane, no, you’re going to help fix this. And so we quickly moved to actually one of the first Web apps for the same management. So it was it was a new initiative that became the so called z/OS MF. So z/OS management facility was one of the first management system for the mainframe as a web app. So we were working with a very early, clunky kind of JavaScript tooling. So it was really interesting to see how it was installed.
And so after that I got asked to come on to one of the initial and first private cloud teams at IBM, and we’re working on the on the initial private cloud products around 2009. And so I got asked to help for the frontend. And so then we moved to bit we were then using Dojo for producing our app and this led me to become more and more interested in the UX topic. And actually at your conference, at the Monkigras conference, I listened to Phil Gilbert (Monki Gras 2014: Phil Gilbert on Recreating A Design Culture at Scale) explaining IBM design, and I also heard a lot about it internally. And what happened in parallel is that I started to meet the design community in my location. And we started building bonds and meeting regularly, and at some point one of the guys in the team got up and I came to the idea “What if we start our own studio?” And so this was how we started the story of a design at IBM Boeblingen (IBM R&D Germany). We built a new studio and I joined the team, like, a few months afterwards because I was really inspired by that. And then came the question, like, okay, you’re joining the team, but what should be your role, right? And so I started with UX Design, but very quickly there is someone who joined externally from the US who started this new practice of UX engineering and prototyping. And so very quickly we got in touch and this felt like its the perfect fit, actually, and so this is how I got all started. It was seven years ago now, 2015, and so I’ve been evolving in this role since. We’ve started an internal community of frontend to upskill everyone into the modern techniques. And we’ve grown also into a more stronger team. And now it’s even official because I got a department, so I’m now a UX Engineering Manager. Yeah, so this has been something very interesting starting from this role that has been really a niche, and now it’s being more acknowledged in the industry. So there are more and more companies that go into that, and I can see also signs of companies organizing the UX engineers now in structures and organizations to make it scale.
Kate Holterhoff: That’s a really exciting story, thank you for sharing that. And I think maybe for our listeners here it might be worthwhile to pause and kind of dig into some of those roles. So you mentioned a lot of terms here, and there’s a lot of terms in general for UX engineers, so we’ve got a Design Developer, Design Technologist, Creative Developer, Prototyper. What differentiates these, and how would you characterize that role for IBM specifically?
Stephane Rodet: Yeah, it’s pretty funny. So many names for a similar role. So if you know the role more narrowly, then there are some differences that start to appear. So let’s start with the prototyper, because this one is pretty simple. The prototyper is a role that exists also in pure design. So you can be a prototyper without coding, you will be the person who puts the design together into scenarios, potentially designs, also some animation and interaction between them. And so that will help you to get to the first prototype. And then the next step in this prototyping, of course, is to start to mix some code, but also why not go completely with code, especially if you have a design system, you can plug and play the elements together, and the more mature your design system will be, the faster you’ll be, actually, with all of that. So this is then really practical because you get to build some kind of catalog of designs and interaction and so on, and then you get more and more productive and can show the prototype directly to the users. So this is the first step. The next one that I think is interesting is the Creative Developer, and also I think it goes along with a bit Design Technologist. And so the Creative Developer will also play with new technology, sometimes IoT, for example, to come up with new concepts, new possibilities that might go way beyond what just, you know, what the designer in front of the screen will think about. So this is a bit of of a separate role, which I don’t know we have in the company. And then Design Developer and UX Engineer. Personally, I consider them very much like synonyms, and sometimes I would even say it depends on what organization are they reporting to and so on. But basically it’s very similar responsibility. And then you have all kinds of roles that come into this. So, for example, the UX engineer would be responsible for working on the design systems. They will be responsible for also prototyping with code for sometimes coding some interaction. Sometimes they will go and help the developers to understand, you know, to show them how to make a specific design happen. And sometimes they will also advise the designers on a specific technical matter, also to help them understand what’s possible, what’s not. Helping them with the domain knowledge also of the product.
Kate Holterhoff: Great, so it sounds like there’s a lot of overlap there. I think what interests me about the frontend space is how there is this kind of need to synthesize the roles that we all operate with, but also there’s these these new divisions that we’re seeing in the field. So that kind of reminds me of Chris Coyier‘s really important article, “The Great Divide,” which he wrote for CSS Tricks a few years back. It outlines the disparities between frontend engineers, particularly those who work heavily with JavaScript, on the one hand, as opposed to those who work with HTML, CSS, design, interaction patterns, accessibility, etcetera. And, you know, that was actually more the side of the fence that I worked on. So I guess I’m curious, what strategies do you recommend for confronting and finding commonality in light of this division? How do we find the areas where we can work together, and where are you seeing the field move in terms of this this division, which Chris Coyier outlined in that seminal article?
Stephane Rodet: Yeah. This is really a very revealing article. It sparked so many ideas in my in my head when I read this article, I was like, oh, finally someone put it on paper. And it’s a really interesting case because very often in IT you have that kind of specialization happening where where a single role got divided into multiple, like backend developer, then you have the database developers, you have, well, I think people will hate if I say this, but the more kind of DevOps oriented roles. But it starts from a common point in that case of frontend development, you really have people coming from two different places, right? You have people coming from software development, engineering, sometimes even like backend development, or at least application development, moving into frontend and having a little bit more to do with design, but maybe without having the solidified or formal knowledge into the topic. And on the other side you have the more, like I would say, the agency developer who would realize and prototype the ideas from designers mainly for websites for communication supports. And so now those, those two roles have to come together to create a more complex outcome. And I think that’s the kind of thing that we worked on a lot: that idea of design, trying to bring those two kind of personas together. Because you need both skills right now to make complex web apps happen, right? Because they are complex in structure, but they need to look nice, they need to feel nice, they need to be usable, understandable, consistent in vision. So there is a need to have those people speak together, and, as much as possible, also exchange skills, right? So transferring knowledge is very important. So, for example, what we did on our side, we created a community for those two categories, sort of more development from the developers and the UX engineers to come together. So this is very important. And I’ll try to fill the gaps a bit. Like if you are if you are more of a backend developer, then let’s have a look, try to spend a week with designers, try to use their tool a little bit as well. And the opposite side, right, if you are just a CSS developer or maybe a designer, also know how to code a little bit of frontend. Then you can have a look at other stuff like, I don’t know, you can look at Python and can look at trying to do your own data science. We have some people actually in our studio looking in that direction and that brought their skills on super power, really.
So there is the kind of strategy you can use. Also, keep the awareness here by trying to keep good contact. But also, at the same time, I think this is a fine line to run on. Like what I’ve seen is that still the more, what I would call CSS developer or maybe UX engineers, you know, the CSS developer is more for what I would call the agency model, right? So when you write primarily content that has a lot of editorial aspects, but not too much functional, right? And the UX engineer is a bit of the evolution of that role, but more in a complex kind of application, or even further enterprise kind of context, right, because the UX engineer will also know how to plug JavaScript together to make more complex software work together. So this is a bit of the kind of differentiation I see. But still, if you take the CSS developers or the UX engineers, both tend to work a lot with with design although they are different organizations, and might place them into a different reporting branch. But at least the way we found it works the best for us was to have the UX engineers tightly connected to the design, and how do we do that? We just place them in the design team very simply. So they can actually act as designers. Also, they can sometimes help the designers: work with them on common problems and then keep the more, I would say, application engineer kind of person also in tight contact with the other developers. So they can also have people who understand their way of thinking, of working, their evaluation, and so on.
Kate Holterhoff: I think the collaborative aspect of the sphere is something that maybe doesn’t get spoken about enough, and you’re completely right. In my experience, it really is the idea of working together with folks on these projects [that] can just be extremely liberating. And then another thing that I think we’re seeing in the industry is just the sheer number of tools that are coming out to support folks who work on these interactive teams. So I guess I’m curious a little bit about that aspect. So, you know, the velocity of the technologies that are emerging to support design disciplines, design system management, design tools, so, I’m thinking here of Figma, and Lottie, and web and native platforms: it’s extremely exciting but also challenging to keep up with. Can you talk at all about how to stay ahead of these changes in the frontend landscape?
Stephane Rodet: Yeah. We see that as a big role of the UX engineer to keep up with those technologies, and especially also help the designers to make sense of those technologies because, for example, sometimes there will be tools, I don’t know, like Airtable or Figma. Many of those design tools are actually highly pluggable, so you can write plugins for them to enable new functionality. So suddenly you make a design tool that’s completely random and free to something that just, you know, that’s much more of a specialized toolbox for your component system. So you can make all new kinds of outcomes happen and you can bring way more consistency and speed and so on in the workflow of the designers by plugging this in and sometimes writing a small piece of software. So we see that as a very big responsibility. At the same time, we also try to think all the time, what’s the value of the technology? Because if you have too much movement and not enough stability, then at some point it starts to be detrimental. You start to having disconnects and people will just not keep up with the changing workflows and all of that. So there is always a fine line to be had in there, but we still think it’s important to have certain people in the team that have some reserve time for looking at those tools, right? And you might decide it differently in some places. You will have dedicated teams, in some places you’ll have every folk who spend some time looking at new tools on a regular basis. I think it plays a big role in motivating the people and making work more enjoyable, especially when you know that you have some influence on on the tooling and the workflow of the team. I think this empowerment is very, very important in general, but just also to keep up with with the other role, like productivity change and so on.
Kate Holterhoff: One last question for us that I’m particularly curious about. So I typically think of testing as the domain of the backend, and we spend a lot of time in this conversation talking about how there’s actually a lot of back and forth between these [roles], and the full stack developer seems to be alive and well. So I guess I’m curious that even though testing is not something that the frontend is usually thought of as really dealing with, you’ve argued that that actually is not the case, that it is important for folks in the frontend to take on the role of a tester. So could you expand on that idea?
Stephane Rodet: Yeah. There are multiple levels to unpack with that because there is some level of testing that I think is known to every frontend developer, or at least they aspire to, which is to use some frontend testing tools for their code. And having this run at least some base test being run on every build, and commit, and so on. So this is definitely one aspect that is known, but I think when you look at the direction of UX engineering, what is the role of the UX engineer for testing? And this is where it gets very interesting because when, for example, a UX engineer starts to produce some coded prototypes of a design, then you get a software implementation of the design, but with a fraction of the cost of the real thing, right? You don’t need to care about all the dependencies, what the API might do or not. You can just test the interaction itself, right? So there is all kinds of testing that you can have with the users. You can also, I think, as a UX engineer, you can use your skills to deploy, for example, different versions of a design so you can compare the two solutions. We had that done recently by a team. It was really interesting to have the actual stuff being presented. So there is definitely a lot of potential in this. And then you go even further like how is that about the responsiveness of the design? How’s the accessibility? Can we make it accessible? What about, how do the animations on the micro interaction feel? There is a lot that you can do with the design tools of course, but sometimes I’ve seen teams who weren’t enough knowledgeable of the limitations of those tools. Sometimes they underestimate how much you can do more outside of that. And I would say even the design tools. Lots of them have some so-called prototype function which can bring you to different states. But there are many scenarios in which it doesn’t work anymore. So as long as you’re writing a simple form, you know you have a website you want to navigate between elements, you want to highlight one or two elements, it’s really fine, right? But as soon as you go into kind of a free world. The kind of stuff, for example, you have my favorite example is a spreadsheet, right? You want to test if a spreadsheet interaction is working, your user might be writing something anywhere and then you need to show on any other place what’s the result of that? So that’s the kind of things that with code you can test very easily because you can just code it on the frontend and then have a look and and try it with users to see if it works.
Kate Holterhoff: Well, this has been an exciting conversation. I feel like I’ve learned a lot from you today, Stephane. Thank you so much for joining me for this RedMonk conversation. Learning how the frontend, UX and design continue to evolve, especially at IBM, I think is a really important story to tell. So thank you again for taking the time to speak with me today.
Stephane Rodet: Thank you, Kate, so much for this great discussion.
