Arin Bhowmick, Global Vice President and Chief Design Officer at IBM, discusses user interface design for enterprise applications. SE Radio host Kanchan Shringi spoke with him on the evolution of the role of UX in enterprise applications; how and why the design process is different than for consumer applications; organizational structures that support the UX function; the future of UX design with conversational UI; and career paths for UX designers.
This episode sponsored by BMC Software.
Show Notes
Related Links
- 428 – Matt Lacey on Mobile App Security
- IBM’s open source design system for products and digital experiences
- IBM Enterprise Design Thinking Framework
Transcript
Transcript brought to you by IEEE Software
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
Kanchan Shringi 00:00:50 This is Software Engineering Radio. Welcome to our show on UX design for enterprise apps. Today’s guest, Arin Bhowmick, has a masters in human computer interaction and his experience spans over two decades. Arin is currently global vice president and chief design officer at IBM, but he has the UX and design practice for IBM cloud data and AI. It’s great to have you here. Is there anything else you’d like to add to your bio?
Arin Bhowmick Thank you for the opportunity. First of all, there’s a biologist going to summarize on my own words a little bit about sort of where I am. I lead the user experience and design org initiatives and missions for the IBM cloud, data, and AI portfolios. I also sort of serve as the chief design officer for these offerings and with the intent to create experiences that hopefully makes a positive difference to the life of users. I’ve been lucky enough to graduate from the field of human competent interaction and work in UX and design throughout my entire career. But my experience has primarily been in the technology space and I kind of like it because it’s a complex domain, but the problems are not simple ones to solve as designers. I think we exist to help solve complex problems and it’s the constant changes and challenges that keep things interesting for me.
Kanchan Shringi Let’s start with the role of UX and enterprise apps defines an enterprise app as computer software used to satisfy the needs of an organization, not individuals, but at the end of the day, the software is your spy. Humans. UX has not been that important in the past for enterprise apps, but that has changed. Can you tell us why and how?
Arin Bhowmick Well, I’ll start off by saying that design as we call it is really an expression of intent and intend to solve a problem towards meaningful outcomes. And so when we say consumer experience and enterprise experience, at the end of the day, we are designing for human beings and they have a goal to accomplish by using your software or your product. So enterprise software in general is built around the construct of getting your jobs done. People use it to sort of make a living. So there are additional considerations that come into play. For example, the context and environment views, the characteristics and the role of the user, their specific mental model, their emotional reactions to, you know, the general environment that they work in, as well as the touch point. They may have not just with the product you’re building, but also with the other products around your product. So enterprise software design really requires a holistic outlook from end to end, including things like translation and globalization as well as accessibility. So the problem statement is a little bit wider and deeper for enterprise software. But inherently though, I want to still say that we designed for human beings and it’s on us to move consumer experiences. And then the mental model people have into the enterprise world and that’s happening more or less in the last five to 10 years, as we see the new workforce coming in, they play with different applications and they have mobile devices. Their attention span is not the highest. So how do we design a enterprise software experience that they would use eight hours a day, seven days a week in some cases, and this really still leave them with a feeling of sort of accomplishment. So the goal here is be to transform, learn from consumer experiences and bring in those patterns of use into enterprise software.
Kanchan Shringi 00:04:36 Let me ask you about the major goal still is it having the wow factor or having user interfaces. That’s still key.
Arin Bhowmick 00:04:46 I would say that from the research we have done over the years, the single most valuable metric for an enterprise software is about productivity. How can we make our users more productive? And yet that includes predictable elements. It includes, uh, optimized paths flows to get a job done. It’s not necessarily the concept of wow factor as a standalone thing. At the same time, we as human beings have emotional reactions to the environment we are in the products that we work with. So the goal here would be to imbibe those innovation mechanics that we see in the consumer world into these predictable learnable interfaces in the enterprise.
Kanchan Shringi 00:05:36 What is the difference between UI design and user experience? Those words are used interchangeably, but are they, can they be?
Arin Bhowmick 00:05:46 This probably a, a school of debate on this? I will say that an interface isn’t experienced, it could be part of an experience, but it is an in itself. So for us to think about a user experience, we got to think about sort of end to end use this interaction with the product, the company, the services, and how the different touch points come together to provide a meaningful sort of business outcome to the users. A user interface is essentially putting together workflows and content, which are very important that they’re to help users get to from point a to point B. But I feel UI is a small part of the UX. There are much more beyond that.
Kanchan Shringi 00:06:37 Can you talk now about the evolution of the user designer, the UX designer role for enterprise apps?
Arin Bhowmick 00:06:45 Going back to my earlier comment about being designed for humans, but we design for the context of use enterprise applications have many different characteristics. For example, you’re probably designing a product that caters to very different sort of roles or personas in, in my word here. For example, we’ve been designing IBM cloud and just a simple thing, like let’s say billing, which as, as a consumer of any software as an end user, you would, you would know how it works, but when you create a multi-person product, you need to make sure that the content is show, uh, and the interaction model you build in is very specific to the user of the persona. And in my books, if you design for everyone, you designed for no one. So as an enterprise software designer, you really have to think about not just the primary paths, but also some of the, I want to say the fail-over paths as well. You need to also think about instead of making generalized experiences, do you cater towards a specific user or a specific persona? If so, do you know what the goals are? And can you use the software experience to help the user accomplish the goal? So it requests a little bit of a different mindset because it’s not just designing the experience in a generic sense. Each persona has a very different take in the world and how do we, how do we cater towards those differences? That’s what makes it a little harder.
Kanchan Shringi 00:08:22 So you talked about making sure that you’re meeting the goals of the different people that will be using it, make sure they’re productive and take the context into account. And you started to talk about billing as a feature. Can you tell us a little bit more, how would you see that design differently within an empathize app and a consumer app?
Arin Bhowmick 00:08:42 Good question. Let me just give you the IBM cloud example again. So IBM cloud, for example, has tons of paths and I add services, right? It caters a wide set of personas. So you’ve got folks like account owners and for them, it’s important to know how much of the services are being used. Are they going to be overcharged and so on and so forth? You also have to think about the concept of chargeback. Also have to think about the concept of chargeback. So if you have multiple, sub-teams using your account, uh, how much are they using? Can you distribute the charges? How do I allocate the usage? What sort of currencies do we need to support? Are there multiple billing systems involved that be aggregated and bring together information? So all those complexities is inherently part of enterprise software. Another example I’ll give you is the simple act of signing up, right? As a consumer, I’m sure you would have gone in and gone into a website and signed up. That’s great. You sign up. But when you started using the product, would you connect to your elder app? Would you need specific accounts and authorizations in place? Would you want to have, you know, private or regional catalogs or services only specific users need access to specific things. Do you want to account for spend limits between the different users and their targeted personas? So that’s the other facets of complexity. Um, and I’ll give you another last example is instrumentation is big and nowadays, but as you do your instrumentation of services, you also kind of figured out the usage model of your users. So you might have built these great products with the hope that is going to really bring in a lot of user adoption, but to instrumentation you find out that that’s not really the case. So how can we through meaningful experience changes, bring the user back to this core products. So in enterprise software, you’ll have to think about all the permutations and combinations. Unfortunately, life is not going to be linear.
Kanchan Shringi 00:10:55 That’s a very interesting example. Can you tell us how do you then retain a balance between this goal of productivity and the business goals are the challenges there? Is there a mismatch in those goals?
Arin Bhowmick 00:11:10 There are challenges, but I want to say that if we end up designing for goals, that we expect to use it, to perform everything else will follow that’s, uh, as a philosophical statement, so to speak, but the business metrics of what drives the product and the user goals on what they think is important, even though they may be slightly different, but if one compliments the other, I think it’s a win-win for both parties. But the trick here really is to figure out whether we know the trade offs. And one way we are doing that. If it’s an IBM and an IBM cloud, and the other portfolios was talking about is through meaningful user research. We really focus our understanding of the user expectations behavior needs and sort of their motivations to investigative approaches as well as qualitative insights. And so once you have that, you know, what the bullets are, and then we look at the business model and we say, okay, can we map the user goals to business metrics? And if he can do that, I think we are going to get a home run. So that’s been the, sort of the, the take and how we can merge user expectations and business needs.
Kanchan Shringi 00:12:29 So let’s take the example of that. You’ve talked about the billing and the signup and talk about designing for multiple channels of devices. The business goal of goes is to let the customer sign up and look at his billing. But if you look at it from the user standpoint, they would like to do it with their phone, maybe their iPad, and maybe sometimes on the best as well. So how do you balance that?
Arin Bhowmick 00:12:51 Good question. Um, first of all, we think that the evolution of usage of different devices and channels have changed quite a bit. Phones are important, smartphones tablets, but inherently the world is mobile. I want to say, even at your desk, you’re using a laptop, which you then take with you to a meeting. So it’s sort of everything is becoming portable. Now, how do we design experiences that can cross multiple channels and devices? So a couple of strategies we have tried in, in IBM in, in working through examples of IBM cloud, I can give examples there, but it’s to design for responsive experiences so that the experience can scale across devices. It’s fairly common in essence, but in the enterprise world is fairly complicated. You have to support and number of browsers, you have to support different versions and releases of browsers. You need to adopt a grid system and scale and optimize based on the grid columns and so on and so forth. But we try to create this experience where we define the experience and rescale it cause the rises. And in some cases we will also build native experiences in let’s say mobile devices that would inhale the use the, the powerful capabilities that the device provides, you know, like the GPS functionality, the guide of scope and so on and so forth. But by and large, though, we want to make sure that our experiences scale, and we do that by using a design system that bakes in a grid system and has a way to scale up and down.
Kanchan Shringi 00:14:32 So you did talk about ensuring that the UX is geared towards making the use of productive. And at the same time we hear of the need for making the UX simple. If the UX is simple, I also hear comments like a well-designed application should not require documentation so hard. Is it to make, is that the goal and the what about documentation?
Arin Bhowmick 00:14:52 Well, making UX simple, uh, sounds very simple, but it’s probably the most challenging element of it. And I think that’s why we have enterprise designers because they love solving those problems and making things simple, making things simple can be characterized in different ways. We could simplify experiences by let’s say automating parts and pieces of it. We can simplify experiences by implementing good AI algorithms, right? That gives suggestions and recommendations to the user while they are doing the job. It’s not just about simplifying what you see in the screen. Yes, we can do that too. Right. But enterprise software, as I said, people use it for a living eight hours a day, for example, and they’ve been using it for a while. So as we introduced changes with simplification, we kind of have to find a way to coexist with mental models that existed from the last 30 years to the latest in things. And if I, if I go back to your point about, well, you know, simplicity does bring in a lot of benefits, but at what cost, I think it’s important to remember that simplicity is somewhat relative and subjective to the user who is using it. We have had cases where, for example, we’ve taken a screen and spread it into multiple step-by-step screens. So we thought, alright, you know, what, if we guide the user to a process, it might be more simple. And yeah, and generally that, that statement is probably true in most cases. But if you are a heads down user who is trying to be productive and filling out a bunch of forms, you know, have going to multiple steps to get your work done actually slows you down. So that inherent simplicity actually force you to be less productive. So we got to, again, go back to the, the user and the context of use and how much of data operations that they do, how much of collaboration that they need to then design for experiences, talking about documentation in technical products. Yes. Ideally we want our users to be able to walk up and use. Now, I won’t be idealistic to say, you can just walk up and use every part in the planet, but at the very least, can we onboard you the user into our product experience so that you can learn a little bit about what’s in the experience and we can progressiveness disclosed the different functions as you start using the product more and more that we can do and that we should do. However, there is also the domain piece of it. As a user sent to work on a particular task, they have different levels of expertise. You know, maybe they will just, just graduated from school or they shifted their functional competency from, you know, a network engineer to a system admin. I’m just making an example here. And as you do that, their inherent domain sort of ramp up. You need to have. And the lack of that actually poses a challenge to you as a user to accomplish your tasks. So our documentation has been noted in the traditional sense. It’s not just about the features and functions and how we use it, but I think what we are getting towards and an IBM cloud, we are trying to do that is to bring in contextual user assistance so that they, when the user is trying to do a job or a task, there are different ways the user can interact with the system to get help. And I’m not talking about traditional health. I’m talking about contextual assistance, around knowledge articles that are relevant to the topic that he is working in some recommendations driven from AI on things that he or she could do to make it better, as well as interaction with subject matter experts, all in a single pane of glass. So in my view, documentation, as we know it, the way we write documentation, the style, the voice and tone is going to change the, how we consume documentation in our products are going to change. And also the volume of documentation and the, I guess the rapid iteration of the documentation is also going to change. It’s hard to make user experience simple, but it’s the small things that make a difference. I’ll give just two examples. We have this product called cloud object storage. It’s a wonderful product. And with any compute you need, you need to have some storage, right? So again, I’m going back to the IBM cloud example here. When we designed it, we designed for an experience that you can go into the floor of the story service and get your job done. You can identify and define a few buckets and they can go on with that. But we have other services. Like we have a cloud data platform in that there is a tooling product called IBM Watson studio. There you can build and manage your AI models. Now, as you subscribe to the service, you need storage as well. And what we found out is that while the services in itself were great, but they were disconnected the way to make it simple is what if you brought in the concept of subscribing to a story in service and creating the storage buckets, why you’re working on a different service that’s linkage and integration did wonders. So now we have coexisting services that talk to each other. It’s a very well integrated set of offering. The other example is when we have emerging technologies like the world of containers and Kubernetes, and in the growing pains of having to learn them, how do you design for these brand new technology based experiences? So we designed the two services in that plant, the cloud Kubernetes service, as well as red hat OpenShift on IBM cloud, very, very focused on modern day Kubernetes based container technologies. And there’s a learning curve to it, but we managed to design for it by progressively walking the user through the technology. So they could meaningfully use the service. And the result is that in the last 12 months to 16 months, we’ve had more than three in international designer where just in those two products. So yeah, there is a trick to it. There is a diligence and that you need to kind of follow through, but simplicity is really, really hard.
Kanchan Shringi 00:21:38 Thanks for that. And I think this section, we kind of just started talking about the role of UX, how it has evolved, one of the things to keep in mind. And to me, the two things that stand out from all that you said, or these questions was that think from a user standpoint, make sure they’re productive, but put a sign up flow. For example, you probably don’t want to do it in multiple steps, even though it sounds like the right thing to do, but for something that you’re adding in complexity and making it more progressively more difficult, maybe that’s a good idea. So they’re patterns, but you should be careful in when and where you use them. Is that a fair summary?
Arin Bhowmick 00:22:14 Yeah. I mean, bottom line, you should know your user. If you do, then you will be able to design the experiences towards that.
Kanchan Shringi 00:22:22 Let’s talk a little bit more now, but process, how do you structure the UX process? You know, how do you create roadmaps if it’s a new product or an existing product, let’s start with that.
Arin Bhowmick 00:22:35 So within IBM, we are lucky enough and fortunate enough to have a mindset of a client base or user centered design and develop them. And to do that, we created a enterprise design thinking framework, which by the way, is available for anyone to use. And that has sort of three, I want to say, high-level characteristics. The first is the principles that guide us. And so we decided that our focus will be on user outcomes and we’re going to be inventing and reinventing and iterating all the time. And we’ll do that with meaningful diverse teams. And that’s an intentional decision. When we form teams to create projects, they are diverse by definition, diverse in expertise, diverse in talent, diversity, and perspectives. Um, all the elements of diversity. Then we talk about the loop and a little bit a M is a Testament to our constant iterative design and build mindset. That’d be observed our users in their natural habitat on how do their job, et cetera, to really understand their environment and their, their pain points, et cetera. We reflect on that. And then we make, we create designs and experience, and we do that over and over again. And on the, on the more structural approach, we have a concert of the keys, and these are things that help with defining the making of getting alignment and things like that. For example, we have a concert of Hills Hills or somewhere like mission statements. So as a team, we got to know who we are designing our products and experiences for what goals are they trying to accomplish. And what’s so great about it. What is the differentiation factor? So that’s all combined into the concept of Hills. We have a concept of playbacks where we have this diverse team that work with internal and external users to come in and provide a point of view. So we have a lot of these sort of playbacks in, in motion, um, at different stages of the product definition, phase and design phase build phase, and even post build phase as well. And the, and the last and the probably the most important thing is the console of sponsor users. These are, are not stars. These are people that have been designed for. So instead of trying to design on the side, we design and develop with our users. So it’s a co-creation perspective. So all of this is baked into the IBM enterprise design thinking framework, and that’s what helps us sort of move forward. So you talked about designing with users. How is that different or is it related to user research? Um, well, it’s, it’s, it’s, it’s sort of complimentary and it’s it’s additive. I want to, I want to say, so user research is really about getting to know users, expectations and behaviors and such, and then validating your designs along the way, really getting a take of the mental model, measuring the success of your designs and whether users can complete the task successfully, whether they can do it within a realistic timeframe.
Arin Bhowmick 00:25:59 That’s all user research that this format of and summative and subjective set of studies that we do sponsor users are people who are involved with us throughout the journey. They’re involved with the requirements that go along in defining the product. And as we define the product to a sponsor users, we then take the designs and do more user research with prospective sort of users or target personas so that we get more sample data. And we bring the data back in. We shared it back to the sponsor users so that we know that once we get done building this product or service, it will be successful. Sponsor users also have a, uh, I want to say a skin in the game because they are affecting and influencing the direction of the product. So it’s complementary user research is about the techniques that we use to kind of get the right kind of data and sponsor users are the people we work with to help define our products.
Kanchan Shringi 00:27:00 So in terms of view, that is a little bit more. So what else is part of that is the sales team involved with user research? What is the role of data? How do you collect the data?
Arin Bhowmick 00:27:11 So user research is it’s a wide gamut of, um, I want to say, uh, uh, techniques and tools from all the way from contextual studies, where we go in and look at the users and how they are using their system in their environment to more sort of facilities brainstorming, and to get at their wants and needs to the other end of the spectrum of benchmark studies. How long did it take to complete the task, et cetera. In addition to that, we look at instrumentation data. So how are users using our products? Where are they getting stuck? Where are the blockers to conversions to more subjective things like desirability studies. If you build this thing for you, Mr. / Miss User, would it be meaningful for you? Would you desire to get it? So there are different facets of data. We bring in to this user research sort of set of tooling. Now we do collect data before, during, and after the production of our products and experience. Because as, as I said, with enterprise design thinking, we believe in the loop, nothing is ever done. We constantly iterate. So even in the sales cycle, we go and work with our sales teams to figure it out. As they talk about our products and services, and they manifest these experiences in demos and other, such vehicles of sharing, what is the kind of feedback they’re getting? What are the perceptions of the product? Because sometimes perceptions becomes reality. And so we have to account for that in building our experiences, we talk to our marketing teams, we find out what sort of campaigns they’re running and what, what is the messaging of the product? Does the messaging of the product, jive with the value proposition of what the end user is trying to do? If not, there’s a mismatch, when you need to bring it together, we work with the customer supporting, we take a look at the, let’s say the support tickets that people have been filing over the years on similar products and try to learn from it. So we have touched points at pretty much every phase of the journey, whether it across the different competencies, whether it’s marketing, whether it’s engineering with this product management, that with customer support sales and even documentation. So it’s sort of a team sport at this point
Kanchan Shringi 00:30:03 So how do you then quantify their contribution to the business if it’s a team sport?
Arin Bhowmick Good question. There’s always a never ending question on the ROI or user experience with the advent of digital experiences. I think it’s become a little bit more concrete. We can do different measurements studies of the current state and the future state and show the difference. For example, if you look at the conversion rate of how many people are coming into, let’s say IBM cloud, as an example, and resisting for it and becoming an active trial user today, versus if we did this design X or design Y what will it be? And based on that, it’s pretty easy to show the impact, the other things around customer satisfaction. As we go to the different journeys with our users, we constantly tune and optimize our product experiences. And throughout that process, we collect different kinds of customer feedback in products like net promoter score. And we can see how the sort of chronology of the net promoter scores have been improving over time. We can also say that the support cases are going down between releases and part of it is attributed to great experiences. We can also see that the number of trial user conversions is going up, which means someone for onboarding flows that we implemented is also working well. So there are now specific metrics we can glom on in the business for, to show design impact on the metrics. Then do you do comparison between the design and the design all the time, all the time? Again, we don’t believe in any perfect design. There isn’t anything like that in my view, but we believe in constant iterations of designs and, and the, the advantage of having these diverse teams of us talking about is that we do get very different points of view on how we can solve a problem.
Arin Bhowmick 00:32:08 And so we do this AB testing all the time, sometimes in production. So then we’ve been with IBM cloud, we designed a new dashboard, right? And the dashboard is meant to give a personalized experience for the different users that come into our public cloud. It could be a developer, it could be a data scientist, or it could be an account admin and based on the need, they want to see different things. So when we are designing the dashboard, we have probably three different designs and we tested them with different sort of samples in production to figure out which is the best route. And then we chose the one that was getting the most momentum. And it, that was just one example. We do that even during the design phase, where we design multiple variations of designs and then get different kinds of user feedback to pretty interesting experimental design, to make sure that the sanctity of data is there and then come back with realistic data. So we’re getting more data-driven as well, right? It’s not just about experimentation, which we do all the time, but also make sure that we can get the data, interpret the data and then use the data to make your products better.
Kanchan Shringi 00:33:17 The one question to me though, is that this sounds like a lot of work. So how do you then utilize that for multiple projects now, do you have convert those into components and patterns? Guidelines?
Arin Bhowmick 00:33:30 Yes. To all of those questions, we have a huge portfolio in IBM software, even in public cloud, I’m in public cloud, we’ve got tons of paths and services, big data and AI services being gone apps. So we’ve got the gamut. And the challenge here is how can we be consistent with not just our look and feel, but also the way it works at the same time, how can we get our developers more productive, our designers, more productive to spend time solving the complex challenges and problems versus, you know, going into the details of every little widget that exists in the screen. So to help it, then we have a design system, the IBM design system that bakes in a design language. And that has a component library that we call the carbon design system. That’s got all the web components and we’re building in some mobile ones as well, as well as design patterns. So parents are reusable sort of use cases, package to assembly of different sort of components. We also have guidelines bacon as well as visual assets. And we use this carbon design system to help make sure that our products are not only consistent, but we have a same way of, of solving the problem across different domains. The design system, if you want to check it out is carbon design system.com is also open source. So many external folks are contributing to it. So we believe in sharing back attack. This is one way of doing it. So you guys should take a look at it, but design system, this is a one big factor of it. I’ll be at scaled up. We’ve also introduced a lot of sort of learning vehicles to make sure our, our engineering counterparts are very aware of the different concept of the design system, how to implement a grid system appropriately. We’ve also given a lot of guidelines around use it. So it’s one thing giving components and patterns, but then you can also use the parliaments in the wrong use case. So we’ve come up with a list of sort of obvious use cases to map into. And we have a cross-functional across the corporate IBM wide team, whose job is to always call for new pardons that we need or changes to parents because our life is evolving. So we’re going to see a more growing set. And as we build more patterns, more teams are going to use it, and we’re going to become more and more consistent. IBM cloud went to this journey, a huge journey of going to design systems. So with the current adoption of the carbon design system, you will start seeing almost all of our services, have some common fabric, not just the look and feel, but the specific use cases and patterns are going to be similar. And whether you’re in a path service or an ISDN service or a database, or you’re looking at some AI models, you inherently get the feel that they’re part of the same ecosystem. You have similar patterns that bind them together.
Kanchan Shringi 00:36:41 We’ll put that link in the show notes to the design pattern. So if I could summarize, uh, the section about process, what I get is that the focus is on an outcome and the outcome is defined with the help of a set of metrics. Some of them could be things like the number of SRS, which sounds like it’s better for the company though. It also certainly helps the user in that they have less access to log and track and, uh, the bad experience and just having to log in Sr. But at the same time, then you work with diverse teams along with sponsored users in the loop, so that you’re constantly testing the design patterns once, you know, what works and you convert that into components and patterns and share that across teams. Is that something you want to add to that? Is that the fair summary?
Arin Bhowmick 00:37:31 That’s a fair 70. I just want to add that on the business side, you know, we look at net retention rate and things like that. So if we have a user who is using a service for a while, and they’re not going to renew, why not? Can we do something in the experiences that entice them to stay? So I think we are getting into the business of design as I call it from just an executional pace to design, being an element to the strategy of the company. So then we can bring in more users, we can spread the user adoption, but also keep users actively using our products and services. So over the last, you know, 10 years or so, the UX and design competency maturity has, has grown up quite a bit, right? It’s no longer just wireframes and icons. It’s really about experiences. And now it’s about the business element of those images.
Kanchan Shringi 00:38:28 So the metrics that are pretty important. Yup. Let’s talk now about the organization structure. So how the UX Evolve in different companies of different size, is it different in a startup company? Was it a mid-sized company?
Arin Bhowmick 00:38:45 This is a large company. There’s never a single organizational structure that will work across the board. There are so many variables that define the success of your design org structure, et cetera, in IBM, where I am. We have a pretty robust mechanism in place where product management, engineering, and design are sort of equal peers. And we work together on not just the strategy, but also the execution and to enable to do that. I do have a centralized organization here, but the designers are embedded in mission. So day in and day out, they’re working towards the vision of the product or the service. And that’s a great working model for a large company. Like IBM, we have distributed, we have design studios globally. We have different products in different domains. So if you were completely siloed, it won’t work because, you know, we would end up building very sort of myopic experiences. So the challenge we had was how do we scale up the profession? How do we sort of see the forest for the trees and how can we scale by working with each other, even though we are in different parts of the work. So centralized model, but in education embedded with the teams is a way to go right now. Now I’ve seen, I’ve worked in different places I’ve seen in the centralized model will be centralized model. There are pros and cons and all of them. So I would say that depending on the culture of your company, the awareness of what design is and what the design does, the talent and craft the buy-in, the level of investment. These are just some variables that decide on how you’re going to function, but all that is not as important as making sure that if designers are put in an environment where in the stakeholders and the partners actually believe in good design is good business. Then the org structure is kind of irrelevant, so to speak. So that’s what we needed to get into. Now, when you think about product life cycle, you may have a bunch of mature products in your company. And for that, the problem statement is kind of set. So the kind of design that you do and the kind of study that you run is going to be fundamentally different from, if you’re building a net new sort of a, a blue sky organic product, or that you need to do some more upfront research, you need to kind of really work on defining the requirements from the ground up. So the structure you might have, there could be different. So again, my point here would be that I’ve seen decentralized, centralized, both work. It depends on the context and the I talk about, but at the end of the day, I feel like the design profession is nimble enough to be able to work under each of those variations and permutations.
Kanchan Shringi 00:41:43 So you, you did mention that the role of the designer or the design itself changes if it’s an initial product definition, what’s it, it’s an enhancement that said I’d like to talk about the role of UX engineer with the dev team running scrum in that case, would you say that the UX engineer should be part of a team or is that still a centralized?
Arin Bhowmick 00:42:04 So when we start talking about teams, there is a whole element of competency craft and a carrier involved right. In the execution of a project. So I’m just thinking of an example. And IBM cloud, we have the designers sitting in the sprints individual sprints of our services every day. Then this phone calls right there in the scrum of scrums, they are part of the backlog grooming part. So agile and enterprise and thinking we’ve kind of merged them together so that we can get a help with the overall mindset, because we tend to believe that design thing is isn’t just for designers. It’s a way to solve problems and get alignment. So we spread the goodness across the board, and we’ve also changed our execution model to make sure that regardless of what organization that you might report into, et cetera, you’re part of the same sprint team. And, um, the design is being in a different perspective. The UX engineer is being in a different perspective on how things should work and, but it’s handled at that level. And when the Uplevel it to the product level, we started looking into things like design and user experience, quality reviews that we have started a lot. We just to make sure that the things that we ship out the door or something that we could be proud of, are we making sure that when we ship something along the door, they’re going to be usable by our end users to do that. And we do a lot of these sort of internal reviews. We involve stakeholders from not just the design, but also the different competencies, marketing, sales support, et cetera, to come in and seed and action so that they could all influence the product direction. And that’s happening in addition to any of the models we have in place. So I’ll almost on a deem society, org structure perspective to how things can work, regardless of that,
Kanchan Shringi 00:44:03 That’s it, the team has a product owner and the UX designer. So who actually makes the final decision typically, is it the product owner or the user designer?
Arin Bhowmick 00:44:14 So if it’s about features and functions is the part owner. If it’s about how the feature and function needs to be manifested in terms of an experience, we do have the design lead weighing in. If it’s about what kind of technology should be used and, um, constructed to the functionality happen in the product that’s on the engineering team, right? So each one wears a different hat and that’s the power of this three. And a box thing that I’m talking about is each competency bringing in a different perspective. At the end of the day, the product manager is the product owner. He or she will make the final business calls, but we want to make sure that the different competencies that come in in the making of have an equal say so that we don’t trade off one facet or the other.
Kanchan Shringi 00:45:02 A little bit about the differences when you’re designing for micro contents that may be built by different teams. And these micro-finance come together to the whole UI versus cases where you have a dedicated team building, just the UI and other teams building the backend.
Arin Bhowmick 00:45:22 I think it’s, it’s very rare to have dedicated team who just work on the front end and they don’t interface with the backend. I think to have an experience, you need to have the backend architecture already to be able to consume the events and the triggers and the data models that are built in it to manifest itself in the product. So, you know, just is a quick sort of example. We are working on the school project call IBM satellite, you know, it’s a kind of a distributed cloud. It extends IBM public cloud and private data centers and other public clouds. And we got sponsor users from telco and banking, all coming in to kind of help with the definition of, and then making off. And in that experience setting, as we are working through our backlogs and roadmap, and you know what goes in first, second, third, the design team, the product management team and the technical team are sort of locked in step. If you attend that meeting, you won’t be able to tell who’s representing which competency. So that’s the power of great alignment. And I think with great alignment, we will get better outcomes. So, but at the end of the day, there are some business decisions that need to remain. Sometimes designers have a tendency to keep designing for over and over again, because they’re not quite happy with things, but there is a trade off of time and go to market. So that’s where the product manager comes in and, and give it gives a perspective, right? So it is a, I want to say a team effort at the same time, the product manager acts as a business owner to make the right trade-offs,
Kanchan Shringi 00:47:01 Let’s end this section with a question about stakeholders. What can stakeholders do to support and help make this function was successful?
Arin Bhowmick 00:47:10 First of all, stakeholders probably will need to better understand what is design and what can design do. I think there’s a whole myth about design is a support wire wireframes or it’s a pixel on a screen, or it’s an iPhone or making something look pretty. It’s so much more so level one. Is there a good understanding of what design is and what design can do part two in this day and age, we have to zoom that user experience is one of the big differentiators or can be because if you compare to competitors, they kind of have similar features. You know, the price points are kind of similar, the economic status, kind of the similar as well. So what else can be the differentiation? It’s the user experience? The third is stakeholders need to understand that nowadays user experience is also the, uh, I want to say the, uh, the main barrier for user adoption. So if you want our products to meet widely successful, we need to make sure our experiences are great. So are we ready as a stakeholder partner to design, to trade off features and experiences? In other words, promote experiences and build more features along the way, right? Are we ready to try different ways of solving the problem? Do we want to give the creative freedom to the design team, to come up with ideas that evaluate with data, to be able to change the direction of the product? So can, can you think about the role of a designer beyond what they just do for a living, which is to produce user experience design? So a lot to go in there, but more or less it’s about understanding the role of design and what design can do
Kanchan Shringi 00:49:02 Changing gears now to conversational UI and UX. Why has there been a need for this UI paradigm and what are the pros and cons from yourself
Arin Bhowmick 00:49:12 Need? Well, I want to say there’s always been conversational interfaces, but it wasn’t mainstream. So for example, if you have a script running on your command line, is it a conversational interface? I would argue it is kind of if you build in arguments and comments in it, but as users are nowadays used to kind of more social interactions all over the place, they want to feel like they are interacting with the system. So we go from our system of record, to a system of engagement for a system of engagement. There needs to be some back and forth sharing and communication between the user and the system. So that has come to the forefront now. And also in addition to that, as we blend in the field of AI and how AI can really help with making our systems and users more smarter, et cetera, there’s even a wider need to understand not only what the AI does, but how you can interact with it. And some of it, the human way of doing it is to do two conversations. So there’s always been a need. We’ve had that in the past. Now it’s kind of mainstream and people are used to using sort of social conversations to get work done and the social work and their point is how do we make the same thing happen in the enterprise pros and cons in the world of productivity. As, as I was mentioning earlier, where users are trying to complete a particular task, not all of those tasks are going to be adaptive to a conversational interaction model, but there are specific use cases, specific considerations in place on how you build and design good conversation, experiences. Not everything is cut out to be conversational. Maybe some form-filling probably it is, but really in, in an deep engagement reality, you’re building an app. For example, using our IBM cloud services, you can use conversational UX to supplement, collaborate with people’s systems, et cetera, that will help make your underlying sort of artifact better. But the act of completing the task is probably not going to be conversational, but at the same time, if I look at the other end of the spectrum to make sure that the newer generation workforce has coming into the companies and starting to use it tools to ensure that they have the same level of engagement with their enterprise software systems versus, you know, their, their personal, um, access to consumer devices and absence is to build in the engagement in the enterprise software, through conversational experiences, through voice and tone, through micro interactions, through proper content design. So there are different elements of it, not just conversational experiences. So appeal there’s a little bit more to be done because I’m not a hundred percent sure that there is a lot of trust with conversational systems, many end users work with, uh, conversation systems. Sometimes the, um, the output back from the conversation and experiences are, uh, are not accurate.
Kanchan Shringi 00:52:33 So that, that, you know, stress sometime the voice and tone, um, is very generic, so that doesn’t help either. So we feel like there’s a lot more to be done in the conversational experiences field, but I can almost guarantee that this is going to be mainstream for the next, you know, 10 years or so until, until there will be no UI, no conversational experiences. So the design and the copy, what you actually designed the copy is, well, you designed for the interactions you designed for the responses you designed for the way you verbally communicate your design for the cue, or instead the user might interact with your design for the tone that the users might be conversing you. And right. So copy becomes hugely. When I say copy, I mean the voice and tone, as well as the structure of the content and the sequence and how it’s delivered the brevity of it, all of these things matter.
Arin Bhowmick 00:53:37 And I would also say that conversational design is a new enough field and new in the sense that I think we, as designers need to learn more understand, better principles. So it’s a growth area for designers too. If you just take a traditional designer who does a great job in designing, let’s say enterprise software or consumer software, and they say, Hey, the interaction model has completely changed. It’s going to be conversational experience, go design it. I think they’ll have a hard time. They will have to ramp up. They’ll have to understand the principles of behavioral elements that make up the constructs of a good conversational experience. So technology aside, I think that the technology is coming in design. We need to learn a little bit more, more patterns need to be established. I want to say, have a conversation experiences. And then the trick would be to figure out how can we tie in the conversation experiences to the jobs to be done for the user. So if we connect those two dots, they’ll be more adoption of conversation experience.
Kanchan Shringi 00:54:41 So definitely not today. And you mentioned 10 years, but eventually do you think that this paradigm will make screen SOPs? So it,
Arin Bhowmick 00:54:49 I don’t think we’ll have screens obsolete ever. Can we cut down on the number of screens and the interaction sort of morals might differ, might change, but there is this element of, you know, seeing is believing sometimes. And so some of the user interfaces will still be there even though they may be the secondary ways of interacting as humans develop more trust in using AI. And they would want to converse with AI and they’re getting meaningful trustable, unbiased responses, then they’ll start using it more and more. But I think that’s the field that, as I said, you know, five to 10 years, that’s where the field needs to harden a little bit, but I don’t see, you know, physical user interfaces or digital user interfaces just disappearing.
Kanchan Shringi 00:55:40 Thanks Arin. So let’s move on to our last topic for today, which is career path. What does a new engineer need to do to work towards a career as a UX design?
Arin Bhowmick 00:55:50 Let’s take a specific example. Design has multiple, uh, I want to say sub competencies. So there is this world of user experience or interaction design, how things work. There’s this portal of service design, there’s this form of content design. There’s this form of visual design. There’s this world of information architecture. There is a form of user research or usability engineers. So it’s a pretty wide selection of competencies you might want to get to. So depending on where you’re coming from, there’s your background. You might be more, I guess, more at ease in picking up one of these versus being a generalist to be a generalist. You know, it takes time and effort, but it reaps some dividends as well. But I would say that the first thing is to learn a little bit more about what is design, this enough material out there. I love the Nielsen Norman group. They have a lot of great learning materials on design and experience and give it a shot there. Go take a look at some other design systems and recommend carbon design system, for example. And then aside from the whole education part of it, you can learn a lot on the job. So if you’re breaking into the field of design, see if there are other designers around you. If there are work with them, shadow them, ask them to come in and just share the work that they’re doing. And you find some time and effort to critique the designs and get some feedback. So there are ways to kind of learn and adopt, but at the end of the day, if you love solving problems and you want to use experience as a way to mitigate the problem, and you inherently have empathy for the users that we’re targeting, then this is a great field to be a designers with behavioral psychology background. I have designers who have background from the banking industry. I have designers who are, have been trained clinical psychologist. I have designers who are from the service design world. I have designers who used to be software programmers as they’re coding away systems and solutions. They decided that their passion lies in not just the technology, but how you manifest the technology and experiences. So there is no specific sort of blocker for you. If you want to break into design, you just have to pick the part that interests you more. If you want to know more about users, how they work, really get into the head. That is a user research field, and it’s a great field, right? If you’re more interested in, okay, I’m going to break down the, the learnings from research into tangible experiences, then maybe UX design is, is the way to go about. Or you may say I’ve got great sort of eye and a talent for a visual language ability to do provide a brand and identity and a singular point of view to a product. Then maybe visual designers is the way to go. So you have many different avenues, but the good news is you can start from where you are. So what do I expect as a career path, as a UX designer? It, it would be the same as a, a mainstream career. Like an engineer. You start off with a entry-level you scale up to be a team lead and a design needs in IBM. We have these unique sort of paths as well. It is pretty industry-leading. We have this concept of design principles. These are technical well-known design practitioners, and we have a few of them in IBM beyond design principles. You can be a distinguished designer. These are designers who are known for their craft and have a very specific skill, and it can scale across IBM. So you can be an individual contributor. You can be technical design owners as design principles and distinguished designers up to a design fellow, right? So we got a great career curve. Now, is that standard in the industry? I would say most of it is except I’m not so sure about the design principle piece of it, but there is a very defined career curve for most mature companies that have a design competency in IBM. We definitely do. I used to work at Oracle a while back. There definitely was a career curve. I’m willing to bet most big companies actually have a career curve.
Kanchan Shringi 01:00:27 That was a lot of good feedback to their insights about that. Um, how can people contact you the best way–would be through LinkedIn? I think that’s sort of a good start, but more than contacting me. Uh, and I also have a set of medium publications that I tend to write from time to time on different perspectives and, and design and designing for enterprise or new technology. So that sounds a good way to interact with me, but, um, should be an outdoor LinkedIn and I’ll, I’ll be happy to respond.
Kanchan Shringi We’ll put your LinkedIn in the show notes. Is there anything you’d like to talk about that we did not cover today?
Uh, not really. I think you’ve covered good ground. My parting message to the audience is thank you for listening. Just remember that design is an expression of intent, and if you have the right intent, we can provide the experiences together that makes enterprise software equally relevant and equally engaging. And at the end of the day, design profession has the, I want to say the charter and the responsibility to design ethical experiences. So let’s work together towards a world where in there is no bias and inevitable.
Kanchan Shringi Thanks for that perspective. Thanks everyone for listening
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
