PurePerformance - DesignOps with Barista: Scaling UX and UI Efficiency at Dynatrace

Episode Date: March 16, 2020

DesignOps, just as DevOps or NoOps, is targeted towards increasing the efficiency and collaboration between designers and engineers in order to deliver better, intuitive and consistent user experiences. It requires changes in processes, people and tooling and is heavily driven by enabling engineers to become more autonomous when developing and delivering new value for their organization.Join this podcast and learn from Ursula Wieshofer (@Ursula_W), UX Design Team Lead, as well as from Fabian Friedl (@fabian_friedl), DesignOps Team Lead, on how we live and breath DesignOps at Dynatrace. You will learn about the recently released OpenSource Design System Barista, how it enables our engineers to deliver consistent user experiences across all sorts of software projects and how we manage feedback through the Barista GitHub project for future innovation.Also make sure to check out the recent blog posts UX Guilds as well as how we deal with the constantly changing requirements of our design teams.https://twitter.com/Ursula_Whttps://twitter.com/fabian_friedlhttps://barista.dynatrace.com/https://github.com/dynatrace-oss/baristahttps://www.dynatrace.com/news/blog/a-running-start-towards-enablement-how-a-ux-guild-will-broaden-our-horizons/https://medium.com/@holgua/owning-the-unknown-d796e2705ac

It's time for Pure Performance. Get your stopwatches ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Welcome everyone to another special episode of Pure Performance. I'm not even sure if this is a Pure Performance Cafe or if it's a regular episode. I just call it Pure Performance. And I'm actually here in Linz. I'm not with my colleague Brian Wilson today because he's hopefully still sleeping at the time of the recording.

But I'm here with two lovely colleagues and I actually want to start with you, Ursula. Thanks for being on the podcast. And before we get started with the topic, can you give us a quick introduction of who you are, how long you've been with the company and what your role is? Yeah, thank you. I'm Ursula from the core UX team in Linz here at Danadrys. I'm with Danadrys since five years now. And I'm actually a team lead in the core team. The core team versus embedded UX designers that we have is taking care of basic frameworks for the product and the platform.

And we're trying to increase consistency throughout the product and enabling other teams to create a very good UI, I would say. Perfect. So five years with the company. Congratulations. Thank you. So you've seen, obviously, the growth that we've experienced, which is also a topic that we're going to address later on. How do we cope with the extensive growth we have and still, you know, coming up with great UX and UI in the different components of Dynatrace and how you contribute. Awesome. Then to my left, to your right, the next colleague, Fabian, same questions to you. Who are you?

How long have you been with the company? What's your role? Yeah, thank you for having me. My name is Fabian. I am now with the company in March. It's going to be three years, so pretty close to my anniversary, let's say. And I'm the team lead for the design ops team. So I'm, my team is responsible for bridging the gap between everything that our UX department does and our UI developers. So we try to, we try to find that we try to create the tools that our UI developers need in collaboration with everybody from the UX department, so they can develop as efficiently as possible, basically. Perfect.

So that means you obviously, you are UX, UI, more developer-focused, more design-focused. Now, in preparation of this call, we wanted to address a couple of things that people, that I think is interesting that our listeners understand what we do at Dynatrace, how do we do certain things at Dynatrace?

And you sent me actually a long list of things that you wanted to talk about, which I thought was really great. And also people cannot see this obviously right now because we're standing here next to a wall. And a couple of things, I want to kind of go through it step by step. So I think you mentioned a design system. So let's start with a design system. What does a design system mean? What is this all?

Why do we need it and which problems does it actually solve? So a design system is actually used to equip teams with all kinds of things they need to create a good UI. So when you think about a small organization, the collaboration is pretty easy actually because all the people that are involved are in a constant loop. But if you think about the company, patterns, components, methods even, knowledge, everything they need to create a sophisticated and good UI. So, and actually, I think you brought up one big point that I should have started right from the get-go before we go into topics. With the design system, we solve a big problem that we have, and I'm sure other companies have as well. You start small, then you start to grow. I think right now when we talk about the size of Dynatrace, we talk about around 800

engineers being distributed across eight different labs. So how many labs do we have right now? We have a lot of labs that are globally distributed, multiple countries, multiple time zones, right? And kind of how can we make sure that all of these engineers deliver the same set of quality from a UX and UI perspective that our customers are expecting? How can we make sure that these developers are also efficient and don't have to reinvent the wheel all the time? And I think that's why I guess the design system makes a lot of sense, right? Giving them the tools and the teams that you're working with, you are designing like what are like, can you give us a couple of more examples? I know you said some functions, some font, like what else can people envision that you are delivering? So my team is looking at the design system all from a user-centered point of view. So we take the user and we think how can we make as a user the experience throughout the platform better.

That means that we have always the same components because users learn faster. That means that we have patterns that always solve the same use case in the same way. So that users can build some trust with the platform and can build up their knowledge on how to interact with the platform better. And so my team provides all the guidelines that helps the other teams of what patterns do exist, how do I visualize something in the product in a certain way that it is consistent to other parts. Yeah, that is what my team does.

And if I can relate this to an example, I know in the past we had components in the product where you said, why does this list work completely different than the other list? Why can I sort this list and I cannot sort the other? Why does this chart give me this charting option and the other one doesn't give me the charting option i guess this is some of the let's call it inconsistency and kind of really like like multi-development people develop the same thing multiple times and for the end user it felt strange because in this part of the product it looked like a and the other one it looked like b and as you said it doesn't really give you a great feeling and also it doesn't give you the feeling like you get to know the product and how it works yes and exactly the

goal of this all is that the user doesn't even have to think on how they interact with dynatrace the platform they should just concentrate on their jobs and we should take this burden away from them actually cool now fabian to you so you said you're working more on the developer side helping our developers to actually use these components and become more efficient with it. It's about scale in the end. Can you tell us a little bit more on how you take the stuff that Ursula and team is coming up and translating it into something that the developers can use? Yeah, sure. So what we are building inside the team is basically the technical foundation for our design system, Barista.

So our design system is called Barista and we are building the technical foundation to provide the outlet to give all these information that Ursula mentioned to our users, internal users. And we talked a lot about developers, but the consumers for a design system are not solely scoped to developers. A design system should cater all different user groups that you have in the company. So starting from project managers to UX designers and developers alike.

So a design system contains the components and we inside the team, we try to be like the guardians of the system. So we try to be like the guardians of the system. So we try to keep the APIs across the components consistent. We now have a base set of about 50 components in the design system. And the design system contains documentation on when to use a component from a UX perspective and also how to use a component from a UX perspective, and also how to use a component for a developer. So you have definitions on the API of the component, you have definitions on where to get the component from,

so where to import the component and so on. And we have different live examples where basically a developer can already see the component in use in the design system, and best case scenario, just click one button and copy the code over into his application, his or her application. So this is really focusing on providing a good developer experience and providing developer experience that enables all our developers to work really fast. Because a table has a very similar look all the time and you just have to tweak certain properties for your use cases and if you have ready to copy examples you're way

faster than if you have to type it all over again so that's pretty cool so now you talked all about developers but in the very beginning you actually said the three kind of main stakeholders are developers ux and also like the product managers that means you also designed your components in a way that said that the product manager can quickly let's do some let's do some prototyping yeah also possible yeah so we can you can basically start off with an existing example of that's provided in the design system and you can spin up this example isolated for prototyping in an online ide so you don't have to install anything it's just one one link that

gives you an online editor ready for development basically with one example that you can already use and we have about i don't know 150 examples ready for you to use with all the different components that we have. So it's pretty cool to start prototyping without setting up anything locally, especially also for product management. That's pretty cool. Now, also, I know from personal experience that the system that we developed, the Barista system, is not only something for us internally. It's an open system. We made a strategic decision to open

source we wrote a lot about those blogs out there we will link to the blogs we will link to the to the barista website where everything is hosted i also know that i'm very close with the captain team so the captain team is using it i also know that some of our partners who have built extensions to dynatrace external extensions are also leveraging Barista because they wanted to make sure that people that are using their solution kind of feel familiar with the UI. I know that the guys from Versio, they've built a cool system on top of the Dynatrace data and they are using Barista. So that's pretty cool.

But can you give us a little more insights? I'm not sure who you figured out who to answer but why did we go the way of open sourcing and also does this change anything for us from the way we work with it um yeah so we open sourced the component library and barista in december 2019 um so this is when we really started the transition so the decision was made a little bit earlier. But in December 2019, we started migrating everything internally to GitHub, including really the way we work or we worked previously. So we moved our entire CI, CD pipeline to GitHub. We moved all our issue management to GitHub.

We have our discussions out in the open why we decide to do things a certain way. And we basically work out in the open. We really wanted to go all in on open source. And the reason for that is we wanted to provide transparency to all our developers that we already have internally, but also to, like you said, customers that want to extend the Dynatrace platform and want to have the Dynatrace look and feel. And of course, they don't sit next to you in the office day to day. So you have to really give them all the information transparently.

And GitHub is perfect for that. So we really embrace the open source workflows and try to go full open source with Barista. Cool. Just for folks that are listening right now and are sitting next to the laptop, how do you spell Barista? B-A-R-I-S-T-A.

Just like a barista. Like we have a floor down from here, right? Exactly. You know why? Because a barista is a person who takes high quality ingredients and builds an extraordinary experience and that's exactly what we do with our design system that's pretty cool um you mentioned the term design ops uh i know everybody likes the x ops dev DevOps or NoOps or DevSecOps. So DesignOps, just for me, because I've never heard about it before,

is this, I assume it's an industry standard, it's a term that people use, or is this something that we are establishing? Or can you give us a little bit more about background for that, for people like me that have never heard about this before? Yeah, so DesignOps is basically, at least my understanding for DesignOps is having the bridge between development and design and automate a lot of design tasks that previously were manual tasks. in their design tools like version control or having a centralized place where we can change design tokens that are used inside our design system. If you want to change a color for a certain component, you can change it once in the design

file and it trickles down into your developed component. So having automation in place for previously manual tasks is something that we in the design ops team as well cater to. Perfect. Now, between the two of you, right, UX side and then more on the development experience side, how do you collaborate on a regular basis? How does this work? Do you also participate and have your discussions on Git?

Do you meet internally on a regular basis how does how do you then take the feedback from engineering and putting it back into the design system how do you take in the feedback from the community that is out there how does the collaboration work that would be interesting for me to learn so we try to keep all the discussions actually on github that are component related because we want it to be transparent. And also we want the outside world to see the significance and importance of user experience at Dynatrace. But we're also like, so we're gathering feedback a lot to components and to things that we should improve through our UX enablement guild. So we just recently established a guild throughout the Dynatrace organization

from very different roles that help us to gather all the requirements for components and we try to come up with components then that tackle all the requirements so that in the end it's easier for the developers to work with the components that Fabian's team is having there overall. How do you say?

Guardians. Guardians. Cool. So how do you call it? A design guild? What did you call it? UX enablement guild, we call it. Can you elaborate a little bit more on that?

Because that sounds like an interesting concept. Yeah, so the guild concept is actually used by a lot of big companies already. Normally they take the same role, like developers for example, and build up UX knowledge in their roles. We do it a bit of a different, so we don't want to create an additional job to our Guild members. We actually want to just create a little bit of ux awareness and get them into the different teams because if something is developed with ux awareness in the end the the ui will be way better and that helps us so they help us to find all the

requirements for the components needed but also they help us to find out where in the process they get stuck and how we can help them, which tools we should provide, which guidelines. Yeah. Very cool. And I think you wrote a blog about this as well recently. Yes. So we'll make sure to link. So folks, if you are interested in learning more about that guild, about that concept of how we do it internally, check out Ursula's blog.

Do you remember the title so that people can find it? I mean, we'll link about it anyway, but something. It's, what was the title? Yeah, we'll have it on the Dynatrace blog, I believe, right? It's on the Dynatrace blog and it's on Medium. Perfect, on Medium too. Yeah. That's perfect.

So medium.com or the blog.dynatrace.com, you'll find it and we'll link to it as well. So now looking back at where we started. So we talked about we had challenges like every organization that is going through growth, either growth, organic growth or growth through acquisition. We have a lot of companies also that acquire. I mean, I know from talking with our customers that a lot of companies grow by acquiring different companies and then you have a mixture of tools and they are doing it like this and they are doing it like this and then you often see in the products that it doesn't really fit together right so I think these are some of the challenges of having

different approaches to solving the same UI or UX problem and then growth also comes through organic growth obviously like in our case when you are actually successful and then you have to onboard more people. So at really the end, the question is, how can we make sure the onboarding process is better? People need to become efficient faster because otherwise just wasting too much time. You want to avoid duplicated efforts and building the same thing. Now, can you tell me a little bit? And again, not sure who to direct this question to, but when a new engineer starts or a new team starts, is there a special onboarding phase?

How do you actually explain to them how to work with these systems? Or is it self-explanatory anyway? Or how does this work? Yeah, so we had different approaches in the past, obviously, because for some teams, they approached us and said, hey, we are going to start off with creating this new UI you have the system in place but can you show us something and we then had a one-week workshop where somebody from our team actually onboarded an entire UI team that started off with this new technology so but of course we we cannot do this for these fast-growing systems and fast-growing company that we have.

So we also have everything written down in documentation. But of course, people prefer a more personal approach sometimes. So we try to give everybody that starts off a person in contact from the core ui team that they can approach any time if they have questions so especially if they want to contribute something because of course we have a core team of now including ux about 20 people let's say that work on barista and we cannot scale with the amount of developers or UX engineers or project managers that actually consume Barista in this way. So we are relying on outside contributions. So contributions from other teams or even outside the company, maybe someday, hopefully.

So we want to provide them as much guidance and as much help if they want to contribute as possible. And I think your personal touch also helps people get started. And this is what we want to do. Very good. Have you planned? I see other frameworks, also what we do with Captain, provide some short video snippets, some YouTube tutorials on this is how you get started. I think that would be an interesting thing to do. It's a pretty good idea, actually.

My first sample app in five minutes or something like that. Also, I'm offering this to you if you want to because I happen to have a YouTube channel. If you want, we can do that. That means it looks

really like if people get started, we figured out a way how we make sure that they get onboarded as fast as possible so that they become productive. Developers get the personal contact that they can ask. And I think a big topic that I, you know, again, I'm looking always next to me on the board to make sure we cover all the items. Collaboration is a big part. We already talked about this, that you are collaborating all the time.

You're pulling in all the feedback. Any other things on collaboration? Have you seen other benefits with this design framework and how you're leveraging it? Cross-team collaboration, any other benefits you see? Definitely. The design system barista helped us a lot in collaborating actually cross-lab and cross-team

because it's the single source of truth in our company. So you can rely on if I talk with a product manager about the table, he has the same picture in his head as I do. So different roles know what you're talking about because the basics, the basic behavior, the basic styling is all taken care of already. And then you can concentrate on the individual

and the innovative part of the product, actually. Yeah, that's great. And especially, as you said, right, you always, if everyone has the same picture in mind, then it's clear what you mean. And there's no ambiguity anymore okay I talked about the table but my table looks like this and then now you say this is not working as expected right so I think that's that's great

and also having one central place of naming things yeah I mean is really hard and coming up with the correct name and people refer to the same thing with different names so having one central place in the design system where actually the name is defined and everybody can relate to this, to speak the same language, basically helped us as well tremendously, especially when talking design development collaboration.

This is also something that really helps us speak about the same thing, basically. Cool. Fabian, you mentioned earlier, I think you said 20 people are currently in the UX team, roughly? UX and design team together, so the core team. The core team. How many, so that people also get an understanding,

they listen to the scope and the scale of Dynatrace right now. How many development teams would you think are currently using your system? I think about 95 or something. 95 development teams? I think so, yeah. I mean, not all development teams have a front-end aspect, but we, of course, have different also internal teams. That's the cool benefit that internal tools for DevOps, for example,

our whole DevOps team is using our component library that's part of Barista as well because they want to have the DevOps internal tools look like Dynatrace. Exactly. Not only the customer-facing applications are using, and not only the Dynatrace product itself is using these components, but also internal tooling is using these components. Also teams like support and readiness are looking at barista all the time to make sure that they understand what is a good user experience what do we actually support and recommend to do and yeah yeah i like that so actually this this kind of allows me to talk a

little bit about um you brought up the DevOps team. We now call them the ACE, the Autonomous Cloud Enablement Team, because when we talk about Dynatrace, people typically assume we talk about Dynatrace, the product, which is obviously what our customers see and use every day. But what they may not hear all the time, even though it should be clear that we as Dynatrace, we develop not only Dynatrace, the product, we develop all of these different tools, whether it's backend systems like BaaS, CI360, whether it's services like Davis Assistant, whether it's our, as you said, the development productivity tools, our pipeline tooling, everything that the ACE team around Thomas Fischl

and Thomas Reisenbichler, what they are developing. This is all software that, you know, might not be visible to our customers, but obviously has a UI, right? The visualization that they have in their pipeline tooling. The visualization of BASCI 360, that all looks the same as Dynatrace because they are all basing it on Barista.

Yeah, exactly. And that also obviously allows us to, I think that's where the scale factor comes in again because we have a lot of engineers and engineering teams that are developing software. And instead of them having to reinvent a UI from scratch and reimplementing all these best practices, they just base it off of your design system. And therefore makes them more productive, and they can really focus on the stuff that they need to do. Exactly. Really cool.

Is there anything else that you want to make sure we cover? Is there any other resources that we want to make sure that people here know about? I mean, again, we can put a lot of links. Yeah, check out the repository on GitHub. So it's in the dynatrace-oss organization on GitHub, and the name of the repository is Barista, so you can find it on github

at dinatrace-oss barista perfect and any feedback and contribution is of course appreciated and welcome yeah we will obviously link to your blog then also holger he had a great blog as well on medium on how to scale a ux team yeah So there's a lot of things and I'm really happy that we are, as a company, not only sharing, let's say, the best practices

on how we deliver Dynatrace as a platform and what we do, but I think UX, this is the thing that is visible, right? We as a company, we talk a lot about

user experience. We talk a lot about how to build high-performing systems. And so it's great that we actually show how we do this from a UX perspective and how we scale. Which now reminds me about one moreing systems. And so it's great that we actually show how we do this from a UX perspective

and how we scale, which now reminds me about one more quick topic. And Fabian, I think this goes to you because we talked about this a couple of weeks ago. Dynatrace, part of our DNA is performance and user experience. I would assume that when we designed and we implement Barista,

that performance, meaning the speed on how these components render how fast you interact are interactable by users that it has been a core principle can you talk a little bit about this yes of course so um of course dynatrace the the product itself is very data driven so we need to display large data sets for our customers in the ui so therefore we course, need to think about if you have a view that really needs to display a lot of data, you need to think about stuff like lazy loading

certain areas of your page. So you have an initial paint that's really fast, but if the user clicks on a tab view, for example, you reload only the necessary things when the user interacts with it, right? So this is something that we really try to build into our components. And also for large data sets that you want to display in a table, for instance, think

about virtualization of your rows, because if you have like 10,000 rows in the table, you really need to make sure that you don't overburden your browser. So these considerations are built into these core components and the everyday UI developer that wants to start off with the table in a view doesn't have to think about this again and again because it's already built into those components. So that means as a developer if I put a table on my view and on my local environment, I may only have 10 rows and everything is perfect.

And then it's used by a customer and they have 10,000 rows. It means that Barista takes care that it actually doesn't create 10,000 quote-unquote physical rows that are kept in the DOM and overburden the browser, but you're taking care of this. Yeah, exactly. That's awesome. Awesome. And last question um i know we do monitor dynatrace with dynatrace so folks that are giving barista try maybe for their own ui they should be self-assured that if they are using their own ui like building their ui with barista and then use Dynatrace to monitor it, that

our RAM, our real user monitoring should just give them all the insights, every user, every click, every swipe. Right? That should all just work out of the box. Yes, sure. You do that. Perfect. Awesome. Hey, I want to say thank you so much. I hope we have another chance

in the future to kind of give an update to the community. I will, as I said, the links to kind of give an update to the community. I will, as I said, the links will be out there. And yeah, all the best. And I think if people in the UX or UI space are interested in seeing how it feels from the inside, meaning how to work for Dynatrace, do we have openings right now? Of course we have. All kinds of different roles we need. Yeah can you

maybe for folks that are not familiar where exactly all over the place I mean in all the different labs? Yes we have labs in Gdansk and Barcelona and Detroit all over Austria actually the most UX designers are currently in Linz. We have openings anywhere at the current time, yes. And also different roles. So UX designers, UX researchers, UX writers. And for the design ops team, the same. So we're always looking for talent. And if you are interested in having

or have a web development background and front-end development background, or if you call yourself a UX engineer, you are basically a perfect fit for the team, I guess. Perfect. And I think all the jobs

are on jobs.dynatrace.com or.at for the Austrian jobs. Awesome. Hey, again, thank you and see you next time,

okay? Thank you. Bye-bye. Thank you. Bye-bye