Welcome to the second part in our series on CI CD. I'm Suri and I work on the content team here at GitLab. We're thrilled you're joining us to learn how to make your DevOps dreams a reality. If you have questions during the presentation, please use the Q&A box at the bottom of your screen. We'll also dedicate some time to answer your questions at the end of the presentation. If you have any technical difficulties, please use the chat function and I will do my best to help you. Today, John Jeremiah, a Senior Product Marketing Manager, will help us solve the collaboration conundrum. So let's get started. Hello John. Hi Suri. Thank you so much and good morning, good afternoon, good evening everyone. I'm super excited to be here with you today and to talk about what we're facing and to continue the conversation we started a few weeks ago when Victor talked about DevOps and some of the challenges people are facing and I want to focus really today on what we're facing. I want to talk about the challenges people are running into building on what Victor shared and look at what are some of the blockers and barriers and why are people running into those challenges and then how can you break down the barriers? How can you move forward? So let's get started and take a look first at the reality, right? And if you remember what we talked about, Victor talked about the reality that a lot of people are facing when they look at DevOps. People are investing an enormous amount of energy and resources to try to transform the way they deliver software. They're spending literally millions and millions, even billions of dollars to try to improve the way they deliver software. But in many cases, the results they're feeling, what they're experiencing isn't what they wanted. They're not getting the ability to go faster. And in fact, a lot of times people are reporting that they're disappointed with the results. And if you think about why and you look for why, you're going to find some really interesting observations. You know, a couple of observations I found when I started to look at why do people struggle with DevOps is, you know, if we looked at, you know, stories that people have written, two of them that came to mind that I saw that really resonate. Tech Beacon, they wrote a great story recently about one of the reasons why people fail with DevOps. What are reasons that drive it? One of them was, well, they create a DevOps department, like another silo to try to do DevOps when the whole goal is to try to build collaboration across the board. Same finding actually, interestingly, came out of an article on Dezone. They look at, you know, not thinking about capacity in a workload, not appreciating the real challenges that people are facing. And they're bringing DevOps in without changing the way they work. I love to have Dezone talked about, you know, how it's not just a set of tools, but it's changing the culture. And it's changing a culture that is inclusive of everyone who's involved in developing and delivering software. It's not just the devs and the ops. It's quality. It's security. It's the business owner. You know, one of the hardest things is getting business owners to engage and be part of these delivery lifecycle. I experienced it myself, introducing ads on an organization where they thought all they had to do is write the requirements and then come back in six months for what was done. Business owners have to change too. And it's one of these changes. It's one of these transformations that it can't be mandated from leadership. Leadership has to embrace it and support it. But it also has to be something that developers and engineers and security professionals and ops teams have to embrace and want to change too. This is a change of the culture in the organization that only happens if we all start to change the way we work. You can't just buy a tool. You can't just say we're going to do it. We have to really embrace and embark on a different way of leading and a different way of thinking about how we deliver software. And if you look at and think about the traditional world, the traditional enterprise IT organization of how we've evolved over the years. I've often I've written about this about how it's called tribes in the different tribes of IT and a lot of times we call them silos. So, you know, silos works here, right? There's a group of people who work on planning and governance and they have their tools and their language and they work together to manage and optimize their portfolio. They come up with an idea, a plan, a new project, something that they're going to deliver. And a team is formed and they go off and start building it. Sometimes in isolation with the people who are going to test it and make sure it's good and ready to go. I know in my past history, it was often in isolation. One of the biggest challenges was how do you get these teams to work together and not be at odds with each other? And then when you get done, well, how do you get it to production? I mean, this is what Patrick Dubois started to talk about when he talked about agile ops, which became DevOps not so many years ago. This is the, those barriers between development and operations, how operations could be more agile. But these barriers are in between the teams. Not only are they between the teams, but you know what? These barriers aren't just cultural. We built, too often we've built them into the way we work. We've built them into the tools we buy and the language we use. We've created all these different tools and then we've tried to solve this barrier with, well, we try to wire them together. And then we run into problems because we have different data models. We have different definitions of different elements. We often find ourselves in conflict and in having to maintain all of these different tools is how they integrate with each other. One change is we have to work on managing and maintaining and it becomes a huge overhead for organizations to keep track of and for teams to keep track of. And at the end of the day, the business really doesn't care about how the tools work or how they connect with each other. The business cares about delivering value at the end, how we do it, how we deliver value. They don't care. They really want us to go faster and deliver value. And so what we really end up with is some very real challenges and some very real issues that this model introduces. We don't have any real sense of visibility and we can pull it together with dashboards and reports and put it into PowerPoint or slides or different ways to show it to leaders. But it's hard. It's incredibly hard to have a clear view of status and what is where and then understand the status but where we're going. It's certainly not efficient. It's not a process or a framework that says, Oh, wow, we're going to be able to just let it run and focus on on resolving issues and delivering new value and new innovation. And and frankly, the other part about the other challenge we often run into is the one that our auditors and security teams and they expect to have some degree of control. When you have to go through an audit to demonstrate compliance with COVID or socks and you have to be able to demonstrate that you're following the process and the controls that you set are in place are there. And that people that they work in the old way in the way with all the different tools and the way we were traditional, it can be really hard. Because a lot of times people are going to find the shortest way to get things done to be efficient. And that often makes it hard when it comes time to audit and prove that you actually delivered and followed the process. So these sources of friction, these sources of challenges and pain points can be really a problem. And frankly, when you look at it from a tool chain perspective and you say, OK, well, it's not really that bad because I'm just managing. You know, we have one or two projects and it's fairly simple and our tool chains are simple and they're defined and we can deal with it, right? You say that. And then the question would be, is it not perhaps a bigger problem? Because if you think forward, think about where we're going. Think about the future of cloud native and how we're going to see more and more microservices and smaller, more granular applications. Think about how more and more teams are going to have be involved in building and developing and delivering smaller pieces of solutions. It's going to lead to a multiplication of tool chains and it's only going to get harder. It's not going to get easier. You might even consider a tool chain crisis that is that we're on the precipice that this is going to become much, much harder as we go forward. And you have to solve this. You have to think about how do you optimize your tool chain in order to be faster and more efficient? And if you want to move at the speed of business, if you want to accelerate and go as fast as the business wants you to go, then we have to figure out how do we collaborate? How do we bring teams together to interact with each other to have one common view to share their goals and to share their vision? Now, it started, frankly, it started probably 15 years ago, give or take. When we introduced and we saw people start to adopt Agile, Agile really was focused on lowering the barriers between these core teams. It was about how do we get developers and QA and project managers to work iteratively and to focus on having visibility on what they're doing and to work more collaboratively with each other. And I'd argue that Agile has helped these teams to be much, much more efficient. And when Patrick and Gene and Jez and John Willis and the guys who have been thought leaders behind the DevOps transformation, the world of DevOps, what they've started to force us to think about is then how do you go on and how do you start to lower these other barriers? How do you enable automation and collaboration and sharing and measurement? How do you bring those principles of lean manufacturing to lower the barriers to enable teams to collaborate and communicate more consistently from place, from part to part? So they're not thinking about their silos, but they're really focusing on how do they respond to the business demand for value, the business demand for innovation. This is the key. And that's why we do what we do. All of us. We come to work every day and we focus on building and delivering great software. It's not about managing the tool chain. It's about supporting the business. And in the old way of working, the old way of doing this, we were always often got stuck on thinking about sequentially, about from one hand off to another going from silo to silo to silo. And as you think about these handoffs, what does it do? It introduces friction. There's all these opportunities for waiting. In a lean mindset, you want to eliminate work in progress. You want to eliminate and reduce your constraints so you can go faster. But if you get locked into this siloed mindset of handoffs, it only leads to friction and finger pointing challenges. But when you're able to work collaboratively, and you're able to share and have visibility across the full life cycle, you can start to think about how can I go concurrently? How can I free it up so that we can have multiple builds a day and we can have teams working on multiple issues in parallel. And we're no longer constrained by the silos and our lack of visibility, but we're really able to move at a much, much faster pace. It's frankly a liberating mindset to be able to think about working together collaboratively across the full life cycle, rather than having to wait and wait and wait, because that's what the business is doing. And your competitors are not waiting. You have to figure out how to go faster and this is a key to doing it and a key to going faster. So let's go back and look at that tool chain for a second. This is what so many of you are experiencing every day. One version, one variation of these tools or another impacts the way you deliver. Now, if we want to look at what does the answer look like, how do you solve this? Well, one of the ways you solve it is it's cultural. It's about getting teams to work together. It's about aligning goals and KPIs and aligning so that people can work together collaboratively, but it's also about removing some of those barriers, removing some of those roadblocks so that way people can work together faster so they can have a common view and a common discussion that the team is able to unify behind. It's about having a single source of truth where you can really have traceability and visibility across the life cycle. It's really about how do you streamline the processes and enable teams to work in a way that they're more efficient. Now, you know, I have the term left shift in here or shift left, but it's relevant. How often do we wait until late in the life cycle to either do security testing or some version of performance testing, only to discover that we have a problem that's going to impact our ability to ship, or we're going to ship it and it's going to impact the value the customer experiences. And I don't know about the rest of you, but I know that we're make those decisions you have to make all the time. And a lot of times you don't have to do that. If you can identify performance and security issues as soon as they happen, as soon as they are introduced into the code, you have a chance of fixing it. So being able to shift left is an important capability and it's important to think about how do you help people do that. And then at the end of the day, you have to have a system and a platform and a framework in place that allows you to manage and govern the work, where it's not out of control, where it's really quite controlled. In fact, I wrote a piece about how mature DevOps actually produces higher quality and more reliable solutions than it does if you work in a more traditional waterfallish way. I wrote about Gartner's bimodal model once, and I think they get it wrong because it's really about how do we work together and how do we collaborate with shift left automation and testing to ensure that we're always delivering quality. If we do this right, if you do this right, you're going to have more control and more compliance and better governance than you ever would before. And while you do it, you end up reducing risk and delivering higher value. Now, I want to share a little bit of how we do this, right? This is something we do. We're doing this, right? This is not something that is theoretical and you might be able to do it. This is something that's for real. I mean, this is something we're actually doing. Not only are we doing it because we're as transparent as we are, you could actually check out our single discussion at GitLab because what we've done is we've brought our entire DevOps lifecycle into one view where we really do maintain a single conversation from planning future features and issues to how we go ahead and then start to create the merge requests and code to how we build testing and security testing into the pipeline.  It all gets moved through to consistently packaging, releasing and configuring. See really what we're doing and what we're demonstrating and we're doing as a team here at GitLab is we're building around a single conversation, a single conversation that helps us focus on delivering value and iterating at a remarkable speed. And because of what we're doing, because of the mechanics of what we're doing, the way we're working as a culture and as one team, we're able to deliver amazing value. And this is what we've experienced. And I think it's something you should look at how do you do it for your team, whether it's a combination of tools that you work to streamline around, or how do you bring your teams together to collaborate and deliver faster than ever. A couple of closing comments and a couple of closing thoughts, we kind of get to the end so we can take some questions is, and I want to reiterate what Victor had said earlier. And because in his presentation, I think he got it right and I think it's still true. I think at the end of the day, what we're talking about is a cultural transformation, a transformation in which involves how your people, how the people on the teams, the different tribes, how they work together, how they build trust and a relationship with each other, how they learn that it's okay to experiment and to start to take risks and to learn together and how they embrace a process and a framework that enables them to embark on continuous improvement. How do they continue to improve their process? Because at the end of the day, your DevOps journey really is one that it starts with the first step of committing to continuous improvement. And I'm not sure exactly where it ends because the business will always want faster release. They will always, they will start to consume the speed that you're able to give them. And the tools are an incredibly important part. They're enablers. The more the tools that you use can communicate and integrate together, the more seamless they come together, the lower the friction, the more you can reduce the friction and accelerate delivery. So it's an exciting time, frankly, and it's one that I have some time, I think, for questions. Dan is with us. He's been fielding questions as well as we're going. Dan, do we have any questions in the question that I could take? I actually have a question here for you, John. Okay, sorry. Someone wrote in and asked, what is the role of executives in a DevOps transformation? Great question. You know, I've spoken to executives. I think about this and I think that the role, I think executives are an incredibly important part of this. Executives, you know, while they may not be in the weeds and writing code and working on the details of how things happen, executives set the tone. You see, executives set the goals and the KPIs for an organization. And so if you imagine an executive who tells a CIO, who tells her VP of ops, I want no more outages. Okay, great. The VP of ops is going to execute on that KP on that goal. And they're going to implement a set of processes and practices to make it really, really hard to make changes, because they know that changes lead to outages. And so the CIO is in effect basically through that goal told the VP of ops, don't you dare, you know, make it easy to release or easy to deploy, because that might lead to outages. Unintended consequence of simple KPIs can often have a huge impact. So I think executives have to appreciate how the culture of DevOps is different, and how thinking in the end and distributing responsibility for having systems up can help people to work more efficiently and collaboratively. Yeah, I think executives are incredibly important. At HP, I worked with a CIO named Ralph Laura. And Ralph, I really love what Ralph said, he presented a DevOps Enterprise Summit 2015 and he said, my job is to provide the buoys for the team to follow, not the boundaries. And Ralph's idea was, you know, I need to give them general directions to what the goals are and where to go, but the exact path they take, they need to find their way. And it was about empowering teams to be successful. And I thought Ralph was his insight as a leader as to how to lead this I thought was spot on. Other questions? We have a question here. Where should teams get started on DevOps? Do you have any high level advice? That's a great question and I love that question because A, I get it a lot. I actually get a similar question. I had somebody else that asked me what's the best tool for DevOps and that separate question. And the answer to the number one tool you have to have for DevOps is the one on top of your shoulders. It's about how you think about changing the culture in the sense that you have to think first and not just start with, let's go buy tools. But where do you get started? And this is another very relevant. I had a conversation with Gary Grover who wrote a book about starting and scaling of DevOps and the enterprise. And I asked Gary exactly this question. I said, Gary, where do people get started? And Gary's answer is, and Gary's kind of a consultant at this role in this part of his life. He gave me a consultant's answer was it depends. And I tend to agree with Gary at some level is that it really depends on what's your scope of responsibility.  So that's one thing that it depends on. If you're a CIO, you've got influence across the whole life cycle. Then the answer is, and the answer for anyone really is look at your flow. Look at your pipeline, the flow of what it takes for the value stream, for what it takes for an idea to go through the development process to production. And then in the spirit of Lee manufacturing, in the spirit of thinking about, and in Kaiser, where is the biggest pain point bottleneck in your process? Is it testing? Is it test environments? Is it perhaps release management? In your scope and in your end-in process of what you can control, start to improve and remove those constraints. And that should be one of the guidelines as to where do you get started. Now, I think there's a couple of common patterns about how people get started. I think there's a pattern where people start to work on improving source control and improving their development processes with automated builds and automated testing. That's a common theme that we see people start there. We also see people, I've seen people start with, I'm going to work on releases and release automation. We have problems with all of our releases. We lose control of our environments. And Kurt Bittner, who used to be a forest generalist, I think he's now at the Scrum Alliance, his advice to some companies and to customers was start with production and work your way backwards. Start with making sure you can consistently deploy and make deploys to production and work your way backwards. So I think the answer, it's unsatisfying is that it does depend on the organization and it depends on who's trying to drive the change. It depends on where the pain points are. And the truth is, anywhere you start, you're going to end up touching the whole life cycle. And as soon as you start, I would argue you're doing DevOps because now you're focusing on improving your flow and improving your velocity. And that process of continuous improvement will just build on each other and will snowball over time. Thank you so much for answering that, John. And we have one here about tools. Focus on tools was listed as a reason for DevOps failure. Aren't you selling a tool? Yeah, I am. And I'm going to say this because I've been this person, but the term I use that I described myself in my past life was, I was a fool with the tool. I thought buying a tool would change the culture of my organization. And we bought and tried to implement a portfolio management tool in an organization that wasn't really ready. The cultural change, the people weren't ready to change. And so much as we wanted the tool to drive the change, at the end of the day, the hard work of change management, of organizational change management, was work that our leaders weren't prepared to go as far into push as hard. And so from a mid-level, we tried to push a change in the organization. The organization wasn't really ready for. And so the tool by itself does not get you, will not necessarily get you the results. And only a few isolated situations will buying a tool just magically solve a problem. Ultimately, it's how you use and how you deploy and use a tool will drive the results. There's a great example of there was a blog post that James Shore wrote 12 years ago, 15 years ago. He described how to do, the blog post you can Google and we can put a link in. But the post was how to do continuous integration for a dollar a day. I think it was a dollar a day. And he described in that post how to use a rubber chicken and a bell for a team, to enable a team to do continuous integration. And the point is it wasn't about the tool, it was about the process. It was about how the developers use the chicken to determine who was building at a given point in time and how the bell was a signal for the other developers to realize that there was a new version on the build machine that they needed to go pull down and get an update of the code they're working on so they can continuously integrate. It's a great post and it's one I've used in the past. So it's not, the point is it's the people and process as much as it is the tool. And absolutely get labs, get labs, single application to address the entire life cycles is frankly pretty darn cool. But the tool alone won't do it for you. The tool alone can enable you. If you're committed to making the change and moving in that direction, tools can be a huge enabler and can help accelerate that journey though. So I would leave with that. I'm putting my vendor pitch hat on just for a moment. So speaking of people, we have a question here. How can you build trust between teams so that rather than having one team hassle the other for an output, they can trust that something will be delivered? Boy, that's a tough question. So part of building trust is being transparent. Part of building trust is showing up with the other team and being transparent about where your priorities are and what you're trying to achieve. And being transparent about how you're going to engage and work with others. I think one of the characteristics that helps to build trust is just just organizational transparency between the leaders of those teams and the people working on those teams. If you don't believe that they're doing what they're going to do or saying what if they say one thing and you don't think that's really who they are, what they're doing, that any words trust, that hurts trust. One of the ways I think that DevOps in general, the principles of what we're talking about when we look at DevOps helps to build trust is automation. Culture is part of DevOps. So as soon as we start to automate those things that are important, you start to trust the pipeline to tell you where things are at and when you have those issues between teams of dependencies on other teams. I would suggest one of the strategies is to ask yourself the question, is this something we could automate? Is this something we could work together to automate, whether it's performance testing or whether it's user acceptance testing or whether it's compliance with certain requirements from a documentation and auditability perspective or whether it's security. A lot of times the reason the trust isn't theirs because we've eroded it over time. But if we can build into our development lifecycle, those handoffs, we can start to trust the pipeline too. And so I think there's an element of automation that can actually help to build trust because then we focus on how do we document, how do we automate this to make it repeatable and how do we make it so that way as we learn together, we then improve what we've put into our pipeline, our automation improves to reflect our knowledge. I think about when I joined GitLab a couple months ago, I was updating one of our websites and I broke something, which is good, breaking things is good. But the output of the result of my mistake led to a new test that would now prevent me from making the same mistake again. And so it's about trusting the pipeline too. And we have a question here. It says, I understand that culture is important to start with DevOps. How about the next step to technically collaborating as a team with a focus to achieve a solution? Yeah, it's circular, frankly. I mean, it really is. It's a circular journey in which the culture of sharing and collaboration works together to build trust and to focus. And when you start to think about this, I've seen this in a couple of situations, and I know Gary does this when he runs workshops. And I saw it when we adopted DevOps at HP. We brought together all of the leaders, all of the stakeholders into one room and they kicked off the whole journey around the summit. And they established some common definitions and common goals and they started to put into place what they called at the time. And if anybody wants it, I can find it or I can get it. I know people have it. They created their own DevOps manifesto of the principles that defined DevOps for them. And you can have an opinion about whether the word manifesto might be overkill, but it was a set of working principles that they collectively agreed to sign up to and how they were going to work together. And that was a way that they won built culture, but it quickly led them to how do they start to collaborate technically to work together as a team to deliver software, to deliver value. And as I see this, it's an iterative cycle. Gary likes to work. His customers, when Gary Gruber does his work, he likes to get them into a one month rhythm of one month, we're going to improve something. What are we going to improve this month? And it becomes a cadence of every single month. They're working on improving how they deliver while also working on delivery. And so I can't recommend Gary's book strongly enough. I think he offers great insight as to how to do it practically. It's not a technical book. It's a practical leadership book. And so if anybody would like that, I can either tweet at me or ping me somehow. Ping me. I didn't put my contact info in here. I probably should have. But ping it. Contact us and let us know. I'll be glad to connect anybody with Gary, or figure out how to get you inside to Gary, into what Gary does. So speaking of practical tips, we have a question. When working in a waterfall style organization, what kind of conversations are good starters to help executives see the change you want to introduce? Tough question. I think the conversation with executives. So here's, gosh, it was a quote. And I'm going to say the quote. I'll get the guy's title wrong. I just don't have it in front of me. But this is the chairman of the World Bank in Geneva, the World Bank Economic Forum. And he said it about three years ago. He said, the world is no longer a world in which the big fish eat the small fish. It's now a world where the fast fish will be eating the slow fish. And you know what, if you're in an organization and the mode of development being waterfall oriented, and you know what, waterfall works. If you know all of your requirements, and if you know exactly what it is you're going to build and nothing is changing, you know, it's a stable, static environment. If I'm building a bridge, building a house, waterfall is pretty good. I mean, the laws of physics don't change. Concrete doesn't change. Things are pretty set. If my world is what is one in which my environment is one in which that's what it is, then you know, maybe that's good enough. And maybe there isn't pressure in the industry to go faster. Maybe there isn't the driver to do this.  You know, taxi companies aren't software companies. Tell that to Uber. Hotels have nothing to do with software. Tell that to Airbnb. And I would argue that every single company has a component that's digital and has a component that defines how they relate either with their customers or if you're a government agency, your citizens, or if you're just B2B, your partners. It's digital. We establish and maintain relationships and we deliver value through a digital relationship often first and often and sometimes only. And so from my conversation with the executive, it's going to be, where is your disruption because it's out there? Somewhere in a garage. There is someone in Kiev in a garage preventing a new solution or looking at a problem who says, I want to change this. If they're not in Kiev, they're in Johannesburg or they're in Silicon Valley. And they're thinking about how they could take the combination of ubiquitous computing on the cloud, whether it's AWS or GCP or Azure, if they can spin it up on the cloud in moments, they can deploy it to these supercomputers that are in our pocket that we call phones. And all of a sudden, your Home Depot, a hardware company, and now all of a sudden there's this disruption that emerges because someone has come up with a better way to get hardware supplies to their users. And so rather than going into Home Depot and wandering around the aisles looking for the right tool or the right hammer or the right nuts or bolts, I can get it on my phone. I mean, it's not out of the scope of imagination. And so my conversation with an executive would be to try to help them understand how, one, that disruption is coming.  And before long, they're going to realize that if they can't move faster than their competition and they start to lose market share, they're going to have to change. And so that's one. I think the other part of it is an education for executives. A lot of times, and I went on this personal education myself and just to be transparent, I used to think this DevOps stuff was crazy thinking that we're going to automate all of this and we're going to have people pushing code to production that fast. It's crazy. That won't work. You know, I came from an ITIL background. I thought from ITIL and sort of a traditional waterfall background myself. But it was once I realized that the power of what we're doing here is based on the principles of lean manufacturing and the principles of continuous improvement and automating all of the things we do such that when I make a change, any change, it's going through tens of thousands of automated tests and security scans and checks and that everything is being validated to make sure that my change is not going to break something. And if it does, then it doesn't go. So what we achieve with DevOps is higher security, higher availability, better quality, lower risk. These are all the things executives want, but you got to get past the mindset that has led them to think that the barriers and the silos of the past somehow gave them better reliability or better availability. And I would frankly argue that the traditional way of putting in all the processes and the checks actually makes it harder to deliver with confidence. But that's a whole separate conversation. Thanks, John. I have a question about mindset. How do you help people shift their mindset from just thinking about something to taking real action to start the journey on actually building it? I kind of wonder where that question came from because I would suggest that you look at our handbook and our core values of iteration and get that one of the things we really, really embrace and I would suggest that we are probably at the forefront of doing this, which is iteration of what's the minimum viable change you can do to move forward and think about when you have the idea, the mindset of I want to go in this direction, what's the smallest change? What's the smallest valuable step you can take in that direction without having to have the whole answer? And I think the opportunity for people to think differently is to look at if I want to change... I'll use an example that's relevant for me right now is I've been working on trying to define and articulate kind of a maturity model or maturity framework for how people adopt DevOps and it serves a couple of reasons and so I've discovered a model Ticketmaster build which I think is brilliant and so I'm applying this idea of minimum change what's the smallest change I can do to refer to or to reference or to start to do that and so I'm in my head building out what are the steps I need to take to either build consensus or to make changes that help us to go in that direction and so there's a couple of sides to it one side of it is I think you have to at least communicate and build consensus and get there's a collaboration part of it before I take action I like to at least make sure we've thought it through and I understand other issues and pitfalls and have we done this before but once you've done some of that then let's start going and it's small changes and it's about the power of small changes on our organization that you don't have to have you don't have to boil the ocean you don't have to know what the full DevOps lifecycle is going to look like in order to take one step and automate and either look at how do I start to automate testing more to do testing more consistently and effectively one step how do I do builds more consistently one step is what it takes to start that and you don't try to solve world hunger it's one bite at a time I like that you solve world hunger one bite at a time and really the case here is you got to take one bite at a time and how you're going to do this and be open to be open to the reality that where you thought you were going when you started your journey maybe you may end up somewhere different because you get 10 or 15 steps into this journey and you realize that there's a better alternative than what you thought you were doing at the beginning so you have to be open to that evolution as well but by taking small steps you're moving further along the journey and that's the key it's to get moving don't get stuck talking about it start doing it thank you so much John we have one last question here how do I know when I'm done with the DevOps transformation well that's actually I think an easy question because I don't think you ever are done so you know you're done you know you're done when the business says to you they call you up on the phone and say you know what don't go any faster this is fast enough when the business calls up and says you know what you're delivering is super fine value we don't need any better there's no competition where we don't need it anymore and I think that will never happen I've never known if you want to talk about unicorns the unicorn I've never seen is a business leader who said I love our IT shop they're great they deliver on time and they're efficient and fast that's the unicorn that doesn't exist out there at the end of the day the business leaders that I've worked with demand demand that IT go faster that IT deliver faster solutions and are more responsive to their needs they've all been frustrated with the long Gantt charts and the delays that's going to take the ship stuff and the fact that they don't get what they want so I believe you're never going to reach that point where the business is going to look at you across the table and say thank you I think you guys are awesome you don't need to go any faster I believe that as soon as you give them a taste of faster they will want more they don't know it today but as soon as you give them a taste of what it's like to be able to get an idea out of their head and into production in three months say you're at six months today you're doing it every six months which I don't think many people are but let's say you are and you get them to three months they'll consume that and then they'll want you to go in two months or one and they will be they're going to need it because the market is incredibly fast and the competition is fierce so you're never done, simple answer you're never going to be really done it's continuous improvement and the spirit of Kaizen is really what it's all about it's about improving and going faster and delivering higher quality and delivering more value that's what this is all about this is exciting times thank you all for joining us we hope you feel ready to adopt a DevOps model if you'd like to learn more please visit about.gitlab.com we hope that you'll join us for the third part in our series in which we explore ways to use CICD to remove barriers between development and operations teams thank you again we hope you have a nice rest of your week bye


Do you believe in magic wearing a massive hat? It's a difficult skill and time-consuming at that and it's magic the explode is kind the best role to make your party go fully blind I'll tell you about the magic if you insist I must but if I stand in a we's then healers got to adjust healers Why didn't you adjust welcome to a crap guy to Final Fantasy? The last group of the derp's per-cerks job is the magical range DPS or just magic for short look at the hat Look at the hat nothing up my sleeves You are the most important person in the party because when the going gets tough a big hat is required and the amount Of damage you do is proportionally connected to the size of your brim where the melee sniffing up the boss's farts and the range You're shouting yo mama jokes while making love to the arena's boundaries You are the healthy middle standing your ground till you go down to pound town when you found the sound that makes a bad Guy's frown you don't do as much damage on average as the melee's instead to trade it off for the utility of being able to Attack at a range from anywhere in the arena with one major difference from your physical range cousin the cast bar that little Lightish red loading beam that you see just about every other main story quest when you have to search a suspicious bush or scout out For the next place thank-you will find yet another new color of depression most of your skills require you to stand perfectly still in order to Have your big numbers to go off and if you so much a special edition Han Solo your neck to get a better angle at your hot naked tank your skill stops And everybody sees how you are no longer looking respectfully Luckily every single casting job usually has a lewd calendar's worth of tools to circumvent you having to staple your feet to the floor Which does mean in order to up your mobility without losing out on DPS You'll need to learn the right sequence of buttons suppressed like you're playing a seven-dimensional accordion that said there's one universal trick to Upping your mobility no matter the job and that's the maneuver known as the slide Though you normally have to wait for the entirety of the cast bar to complete little known fact once it reaches about four fifths of the way Through you need no longer restrainer movements as though your feet were sweating gorilla glue and you can afford a small amount of movement without Losing possible uptime cool tip This applies not only to the magic DPS But any skill for any job that has a cast bar so you can even be a sliding slicing samurai The magic limit break similar to the range DPS is an AOE that deals less base damage than the melee's but can hit multiple targets In this case a massive circle instead and now you can make fun of the boss for not moving out of the obviously telegraphed danger puddle for a change Boy, do I love throwing stones out of my glass house the family of magic is made up of three siblings Okay, that's a lie It's actually four but the smallest one kind of win a weird career path and they're not often invited to the New Year's parties The black mage is a fantastic job if you're a fan of cookie clicker because you're pressing the same button over and over again Ad nauseam to see big number go During rotation you start out headbanging explosions at the bad guy like a Until you're completely out of mana then you go into a goth phase Where you chug a bunch of cold energy drinks, can you back to peak performance where you can go back to?


Good morning everyone, we can start right? So, yeah, just to introduce myself, I am Sunil. So, I work at design lab here and basically I am doing this workshop which essentially is going to help you, the whole idea of the workshop is to kind of walk you through certain exercises and concepts that you know, you get familiar with and then you can kind of actually easily apply them in your projects. So, just to kind of give you a sense of like what we are going to do today, right? So, there is basically like, we are going to do about three exercises, right? The first one is basic, I mean it is pretty fundamental, it is just basically kind of, you know, really kind of get you warmed up in terms of how to approach a design problem. The other exercise is basically, which I think a lot of people kind of, you know, find it hard to kind of balance out is how do you balance basically business with design, right? So, the second exercise is really about that. And then basically the other main problem is like if you guys get a project and you got to start it from scratch, like what is the design process to follow, right? What is the framework that will kind of help you make decisions as you go along? And I mean through this, I am going to like, I am picking like examples from Clearwater because that is something that, you know, obviously I understand and you know, I have worked on personally. So, I think that will kind of give you a sort of perspective some inspiration to, you know, start working on the sentence that have been given to you, right? So, I think the main focus today is, I mean obviously design is a very vast sort of topic in itself and you can actually go down, you could have a workshop at a very, very sort of, you know, specialized level but we are just going to cover three main areas. Basically just I think the key is really how do you, I mean first before you approach a design problem like it is very important to understand the context, right? How is basically someone going to use the product? In what context is he going to use a disease? On the move is he, you know, in his house, etc., etc., right? Just understanding the timeline of how the user is actually going to use the product. The other thing is really, like once you understand, you know, the sequence of events that's happening with the user and how he's interacting with the system, like how is the information structured and the last is basically the presentation, the presentational layer.  So, we're going to actually talk about these three things. So, I mean, when you talk about approaching a design problem, right? I think the main important thing is really to, you know, ask these questions, right? Who really wants this information? What's most important? And what is the context in some, I mean, what is the context in, you know, what is the context in which the information is going to get consumed? So, just give you an example. You know, this is what a ticket looked like. I mean, if you look at it, you know, it looks pretty clean. It's kind of follow standards and stuff like that. You can see, you can find information, you know, very clearly, but I mean, if you actually think about how the ticket is going to get consumed, right? You can make a lot of sort of enhancements.  So, if you see the difference between both of these, like it's just, like the information is, you know, structured in a much sort of cleaner way, right? And it's easier to find out, right? So, just some details, right? So, giving you another example, anyone uses the passbook, like, I mean, IOS users here, right?  This is what it looked like, right? I mean, passbooks obviously have, you know, the scope of design is very limited, like most of the IOS takes care of most of sort of the layout and stuff like that. It's just basically, you figure out what data points you want to show and there's a ready template to be used, right? So, if you look at it, I mean, in its own self, it kind of works. But, you know, if there's a, if you have a tablet who's, you know, booking lots of tickets with us, this is what it looks like, right? So, in the passbook application, when you have, like, multiple tickets, this is what it was looking like, right?  It's just basically got, it's just got basically the dates and stuff like that, right? So, we kind of redesigned it, we said, okay, like, you know, right on top. We obviously did kind of, we were never expecting this situation where people would have, like, 20 passes in their passbook, but that happened, right? In fact, that image was tweeted by one of our customers He wasn't even complaining, but, like, we picked it up and we basically redesigned this. And this is what it looks like right now, right? So, like, when it's in your passbook, so if you see compared to others, like, you actually know the context of the pass itself, right? So, I mean, these are, I mean, you can actually make a difference through design at a very, very minute level, right? I mean, and just to kind of, I mean, this was really to kind of give you a, before we start on your design exercise, right? I just wanted to highlight these things because the design exercise you're going to work on is kind of very similar. So, I'm just going to pass on some sheets, right? It's essentially, it's got, we're going to look at the voting pass. How many people have floored into Bangalore for the conference? There are a lot of people there. So, I mean, like, you guys obviously have a first time experience like more recently about using a pass, voting pass. So, when I was talking about basically like, you know, the context and you know, who's really going to use a sort of this pass, right?  Like, you know, if you look at the traveler, every, the pass actually goes through multiple hands, right?  Where he kind of needs to refer to the pass for like various information points, right? And then, you know, you have like the security guard who's, you know, during security check-in who actually looks at this voting pass.   And then you have somebody at the pre-voting also to just make sure that you're getting onto the right flight, etc. So, everyone like kind of needs a different sort of, is looking for a different data point at this stage, right? So, obviously, I mean, if you look at, if you look at the airline staff and the security staff, they seem to be doing this from, you know, they're just doing this from, I mean, from morning to evening, they're probably looking at 100, 200, maybe 1000 voting passes a day. So, obviously, you don't have to design for them because they will kind of, you know, they will get used to or they'll kind of figure out, you know, where to look for information even if it's not prominent, right? So, having said that, like, I feel that, you know, if you look at the weightage, I would say that like, you know, 70% of the weightage on the voting pass should be actually given to the information that's required by the traveler. And, you know, in fact, 30 or even less than that, you can actually give it to the rest of the people. So, you guys have worksheets with you. So, I would actually, you know, so I've actually just... Does anyone need worksheets? So, some part of it is got washed out. So, I, especially the traveler bit, so I'm just going to keep this light on, right? I've just grouped the information based on the primary user and secondary user, right? So, like, why don't you guys take a stab at, like, designing a much better voting pass. The second sheet essentially has information bucket, what's missing is... So, I basically created three buckets. There was basically the important stuff, not so important stuff and the least important. I mean, when I talk about least important, you could basically chuck, you know, those... If you feel that there is something on the voting pass that's not required at all, you can just basically... Anyone has any questions? Not very clear. We need to categorize which information is most accurate. Yeah, exactly. So, essentially, I've, you know, I've noted down, you know, what the primary user needs, right? And if you see the block here, essentially is where you need to actually do the new voting pass. Yeah. I'm just trying to pull out the original... So, the sequence number is essentially the number in which... So, when you check-in, right, you get assigned the number. So, if you're the first one to check-in, you're basically sequence number one. So, if you notice, like, when you're actually boarding the flight, just, I mean, before you get into the shuttle, you have, you know, the airline staff will actually... If there's no barcode scanner, they will actually check-off 116. So, they would have, like, a map and they'll just check-off that this person who's checked-in is actually going to board, right, just to keep track of who's not checking, who's not checked-in, or who's not boarded as yet. Who's not boarded as yet. So, yeah, I mean, if you think about it, it's like, it's a... information that the traveller doesn't care about. Yeah, exactly. So, it is less important, but like I told you, there is a use case where, you know, there are multiple travellers and you need to... You need to kind of distribute the passes. At that point, it's relevant, but yeah, I mean, it's not the most important thing. You also get sometimes multiple boarding passes at the same time when you are hopping flights. So, maybe in that case... In an international case, yeah. Well, it's just probably really that important. The destination is, right? Even if you have multiple... If you have androids to, say, Dubai and Dubai to New York, it's not like you're going to have a flight to board in-band or to New York directly, right? No, no, but yeah, I mean, I guess, like, when you have two boarding passes, you know that, okay, I don't need this boarding pass right now, right? It's something that I'll need later on. So, yeah, I mean, it's a valid point, but again, like, you know, you have to consider these cases as well. I think the class also, I think you need for LDA, if I'm not mistaken. Or something, you need it for something, or produce the class number. I know what you need it for. You need it for, like...  I mean, today we started doing that, right? We sent your frequent flyer number, but earlier when we were not able to send the frequent flyer number to the airline, you had to go to the airline website and actually kind of clock those miles in, and they required the class at that point. So I don't know if it's relevant any more, but yeah, that's one of one case that I remembered and needed the class. You should also think about utilizing the space. Like, you know, there is a class, right? So we can use the right side of this logo, and we can differentiate by using colors. Yeah. But I think, you see the class, the seat class is, you know, slightly technical and it's kind of for the airline. I was just explaining that basically, I mean, every class has a fare attached to it, as I understand it. So, like, basically when you actually, you know, you're booking in advance, essentially you're booking tickets in the cheaper class, right? And then that class gets sold out, and then, you know, the second class gets opened up and that's how the prices increase. So every class has a thing, and in a full-service carrier like a Jet Air, this probably doesn't apply to Indigo and the low-cost carriers, but basically the full-service carriers, you can be upgraded to first class or business class only if you're in a higher class. You know what I mean? Like, even if you're in economy, but like if you're in K, you never get upgraded. So, probably the only understanding I have of the class. So I think irrespective, I don't think it's kind of important for the user that much. Okay, so I think we have run out of time you know, I guess, you know, we've kind of obviously discussed a lot of ideas and I'm sure that, you know, you guys have come up with good solutions. So basically, I mean, just to, something that I didn't get a chance to kind of mention earlier, I think through the workshop, you know, even though like I believe that, you know, the final result comes, right? Through the workshop, the idea is not that you kind of get the best solution out there, it's just to kind of go through the process and you know, if you guys are enthusiastic about like taking this to finish line, you know, you have that opportunity, you can always go back, you know, like kind of define this design and like, you know, I'll be around through the conference so if you have any ideas or you need feedback, we can kind of work together to refine it and you know, maybe we're figuring out a way if we can actually showcase whatever you guys have done through the conference. So, yeah, I mean like, you know, these exercises don't end here, you can go back and refine it, but like we kind of keep moving in because I want to cover a lot of ground here, yeah.  I think over and above what we did in the previous assignment, I think there's one layer of, you know, basically you were just addressing what the user needs. There's another layer that, you know, comes from the business which is like, you know, what does the business really want? You know, what does the business want to achieve with any sort of design effort, right? So I'll give you an example before we jump into the exercise, right? So this is actually what our confirmation page looked like, right?  And if you notice, you know, what the user actually booked, what he was charged was kind of like, you know, somewhere in the corner. So even though this was kind of addressing business goals, you know, it wasn't really addressing the basic user need, right? So I mean, after talking to a lot of users and getting feedback, in fact, this was feedback coming from users where, you know, because people are still, you know, the users who are still very uncomfortable with using their credit card and obviously payment gateways are not as stable as we would like them to be, you know, many times you get charged, but your ticket doesn't get, you know, issued and suffer that happens a lot. So, you know, there was a certain sort of comfort level that the user wanted first, right? As soon as he booked the ticket, he wanted to kind of feel that, you know, you know, I booked, this is what I paid for and this is what I got in return, right? So I mean, so we said, hey, you know what, like let's not basically try and do everything. Let's take it slow. Let's kind of give that comfort level first. And so we basically broke the entire page into three parts, right? There's basically, you know, just your booking. So, you know, this is what you booked and this is what you paid. And then, you know, things that you could do next, which is essentially coming from what the business wanted to do. And of course, I mean, business, both even deals for that matter is basically coming from the marketing team. So this is what basically came up with, right? So this kind of really improved the experience of someone who's actually made it. And because obviously, you know, the transaction size is also much larger than what you would pay in an e-commerce website, buying a book and stuff like that, you know, you're spending anywhere between 5,000 to 20,000. So like building that, like sort of comfort level was very important. So yeah, this is what I was saying, like, you know, like even though, you know, you have a lot of pressure to actually address business requirements, you need to understand that the user comes first. And there's obviously, we used to actually sort of balance it out, right? So, I mean, that kind of brings us to the second exercise. Many of you actually, and so most of you use credit cards. So like, does everyone have a credit card in the house? So what do you think about the credit card statements you get?  So imagine that basically, you know, this is what a user wants from a credit card company, right? It's kind of, it's a pool that you can actually sort of, you know, access in case of an emergency. This is a group exercise, sorry, I just forgot to mention. So, you just kind of make groups of five people in your location only, like just, you know, five people together can just sort of sit together and brainstorm. So I was talking about the user, right?  Also, you know, how do, I mean, how do I maximize my credit limit? These are things that user wants, right?  You can continue paying bills which you normally do with cash, but if you use a credit card, you can actually redeem mines and stuff like that or more points or whatever, you can get free tickets and so on. And then, obviously, there are a lot of deals. So these are all the things that the user expected from a credit card company.  So this is, again, something that the user wants. And what does a bank want? The bank just wants you to spend more so that they can, I mean, that's the end goal, right?  Same name. Sorry? Same name. Yeah, exactly.  And, you know, this is what the bank wants, right? Out of the whole process. Can we, like, so you guys have the, what do you call it? Everyone's got, I mean, all the groups have one sheet. So we'll actually do this in a group exercise. I think to start off with, I want you to actually, you know, really think about what, what do you want to achieve with this redesigned? What is that problem that you want to solve? I mean, to start off with, it's important to actually set some goals, you know, before you actually get on to sketching and doing anything, right? So like, you know, you have the business objective, you have what the user needs, and you have basically the existing credit card statement, right? So what is the problem that you want to solve is very important. So like, I'll give you some examples, right?   So you get a sense, you know, there are other things which actually, there are other smaller problems that you can solve. Like, so today, what does reward points really mean, right? Like, what is the value? Like, it's very difficult to kind of gauge the value.  So I'm saying that, you know, these are sort of opportunities that you can look at, right? Yeah, but before you do that, I mean, it's important for you to kind of think about what you want to solve and I guess everyone, the fact that everyone on, you know, everyone in the house actually use the credit and you guys understand what the pain points are. So take one pain point or multiple pain points and like, see if there's a better way to present the credit card statement. So, yeah, I'm putting this on and you guys have the, I think the prints for this version is much better. So I think just to set the context of the next part of the workshop, you know, like we spoke about like, you know, when we started off with, you know, how do we approach a design problem? How do we think about, you know, what user needs, what kind of information, what's important and stuff of that. And then we basically kind of looked at how do we balance what the business wants. I think one of the major challenge is that what if, you know, you were to basically build something from scratch, you know, you don't really have any reference point. Like, you know, redesigning, it's easy to basically look at an existing product, you know, find out what issues there are. But what if like, you know, it's a completely new thing, right? What kind of process, what kind of process can you follow that basically, you know, lets you identify the problems and actually like come up with solutions for it.  And that's the whole idea of this part of the workshop. Like, I'm kind of just going to quickly run through all the different techniques and sort of tools that, you know, we've been using to kind of solve small to complex problems when it comes to design and interfaces, right? So, I mean, in the next part, we're going to look at, you know, what if you've got to basically build a user experience for an online bill payment system, right? So, I mean, I'm just kind of listed down, you know, what, you know, the brief requirements of this online billing system, you're not going to kind of design the whole thing, but we'll kind of look at one small portion of it, right? I mean, all the examples that I've picked, essentially, I've picked so that, you know, everyone understands the pain points, everyone pays bills, right? So, like, it's easy for you to identify with the user and that's one of the reasons why I've picked these examples, right? So, Kena, is everyone like, does everyone have access to, like, I mean, I just want one person in a group to have access. What I'm going to do is we're just going to share one document on Google Drive, on the meta-refresh hashtag. So, Kena, can you just, like, share that thing? Just tell them to read with it also so that everyone gets access to it. So, you can just have the document. Essentially, it's like, you know, you're already covering that in the slideshow, but, like, you'll have a sort of, you'll have a reference point of the entire thing and it's slightly more detailed that we'll kind of, you know, you'll be able to, before it, through the design exercise. So, it's pretty much the same thing, but slightly more detailed. So, yeah, I mean, talking about process, right?  You know, what is the customer need? Again, what is the context? How are people going to use it? What are the flows? You know, how do we structure the information? How is the user actually going to navigate through the product? And the entire presentation here, right?  You know, how to choose at the type phase and stuff like that, right? So, we'll talk about that a little bit in the presentation aspect.    He's got to go to a Vodafone site to play a game.  Can I basically bring all this under one umbrella so that, like, I can actually pay bills from one place, right? And of course, you might have some specific needs. This customer might have some specific needs, like, you know, I don't have a credit card. I have, you know, I need a net banking. I need to be able to pay by net banking and stuff like that, right? Then there are some other users of the product, right? So, we may not be the primary users, but you still need to kind of, you know, address needs of these users. You would have people who want to work for this company. You know, you'll have, you know, people who want to, I mean, the investors, interested investors or the press who want to write about it. So, we're not going to get into detail, but I'm just covering it because, you know, you will have to kind of, you know, address their needs as well. And when you talk about context and flow, right, we spoke about the life cycle. I mean, in the previous assignment, when you're talking about the boarding pass, right, how does a user navigate in an airport using the boarding pass, right?  And to support this timeline, does your site or your application have all the necessary state? Because you cannot talk to a first-time user and an advanced user in the same tone. I mean, you know, a first-time user will need a little bit of hand-holding and stuff like that, right? So, how do you look at those different states of the application? And the other thing is just looking at how does the user get things done, right? Like, for example, I'll talk about, you know, what are the things that the user needs to get done through the application. And the other thing is, like, these are probably slightly advanced sort of areas that you might have to look at. These are like behaviors, right? So, things like, does this guy pay, you know, bills late? Or is he someone who pays bills on time? Stuff like that, like, do you, who are you trying to kind of cater to, right? The guy who actually pays bills on time or things like that. And so, just understanding the user, or at least being conscious about it. Because, you know, no user is the same, you need to kind of be conscious about these things. And the other part is communication touch point, right? Just thinking through. So, I mean, when you talk about user experience, it's not limited to the interface, right? You know, when is, when are we supposed to actually get in touch with the user? What are the kind of communication touch point? Is there an email? Is there an SMS? And stuff like that, right?   Has he registered? Has he signed in? Has he paid a bill before? Has he added a card? Has he set up, you know, an automated payment facility on the account? Stuff like that, right? So, these are kind of some things that you'll have to kind of question. And to give you an example, you know, this is what, this is the clear trip, like, account section. And if you basically, you know, you've not really added a card, this is what you get, right? So, we just talk about express mail, you know, what it is, what are the benefits. And then, this is the same page in a slightly different state, right? Like, if you have cards, that same page changes into like a card listing. I mean, just, this is an example. And then, through the account, I was talking about, you know, how do you get users to do more things? And so, like, I mean, these are some of the upsells.  So, this is basically, you know, get upselling like different features of the site depending on what state you are. So, for example, you know, if you've, you know, we have a profile, a traveler profile. And if you've not really told us what your sort of meal preference or seat preferences, then we'll ask you that, right? So, we'll just keep building your profile without you having to do that.  I mean, from Bangalore, we'll say, hey, you know what is Bangalore your home city? And then we'll keep adding to the profile without the user having to do it in one shot, right? So, I mean, this is really kind of those elements that you need to think about while building this. So, what do you need of the user, right? What is, what do you want from the user, right? Like, for example, in terms of, so I'll give an example in the context of a bill, right? Assuming that, you know, he's been paying a bill with a particular credit card and he's not stored that credit card, there's a possibility to kind of ask him to store that credit card or whatever. I mean, this is just an example. But yeah, you need to think about those things as well.  You know, how does he add a bill? How does he pay a bill? You know, how does he save a card and stuff like that? And, you know, looking at this in, like, in sort of, like, looking at this holistically, right? Again, what are the touch points across the board? Like, for example, if someone has to store a card, where are the opportunities for you to actually get him to store a card without him doing that explicitly? So, giving you an example, right?  So, you know, just talking about or drawing attention to the consistency in the communication, right? So, basically, this is what the ad looked like.  We advertise the URL, which was qrtip.com says expressway. And then when users actually land up with the expressway, there's, like, that consistency, right? Like, it's, you can immediately identify and kind of, you know, it's kind of adds that, like, extra, like, because expressway is all about storing a card and stuff like that, you need to build in that trust, right? So, if you kind of have an ad that, you know, has a particular visual, and then that cut doesn't translate into your online presence, there's sort of, like, doubts that come into users' mind, right? So, right from, you know, how it's delivered on the desktop to the mobile, and then while creating an account or sort of in the account section, so that this is, like, more like public-facing, but when you're kind of inside the account, again, there's, like, that consistency in branding and communication across the board, right? On the mobile apps across the board. Even, like, during, I mean, if users don't, users haven't actually bothered to do it through the accounts, like, there is that, again, we actually are kind of, you know, using the brand to kind of have that connect, you know, during the book flow, right? And so, basically, right from, you know, getting people to store the card to actually, you know, transacting with Expressway enabled, right? So, there's kind of, yeah, I mean, I just wanted to share this example because I feel that the successful Expressway lies in kind of building the trust through consistency across the board, building that brand, pushing it through the, pushing it through the product, right? It's not really, it's, like, marketing and product working together to actually sort of building a brand which is kind of very, very sort of strong. Anyways, so, I mean, talking about communication touch points, right? I was saying, you know, what are the communication touch points? Email, SMS, you know, things like, you know, how do you kind of talk about the benefits of this feature or service? What kind of reminders or notifications do we need to put into the, because I mean, this product essentially calls for notifications or notifications, right?  So, just that experience, right? When does it happen? How often does it happen and stuff like that, right? And of course, contextual product ourselves, right? Is there, like I was talking about while making a payment, can you actually get into store a card? Now, storage of card is actually a separate feature, but you kind of do it through, you know, a slightly different task. Okay. So, again, giving you some examples from ClearDrip about this.   You have the airline, I mean, it's ClearDrip, there's the airline, there's a bank, right? There are kind of, you know, in many cases, because a lot of the process is manual, things, you know, users get, I mean, it is a longest process, like getting a refund is a longest process. So, how do you make users actually comfortable about it, right? So, we actually, you know, we kind of like this communication builds that trust that, you know, what if this is the status of your cancellation, the refund is getting processed and we can order the way to even ask whether like the refund got processed, even though that's out of our control, we could actually push it. So, the last email is just kind of, you know, sending out saying that, hey, did you get your, did the money actually get credited to your bank and stuff like that, right? So, yeah, I mean, I think, you know, you want to look at all this holistically, it's not the interface, user experience is like way beyond just the interface, right? Moving on, talking about contextual upsells, so this is actually, so I don't know if you guys know, we actually, you know, launched this product called collection, which is essentially travel inspiration, we tied up with Continas Travel and kind of launched this collection. Now, we had a boring, you don't have any trips kind of a message in your dashboard earlier on.  Now, this is a great opportunity to actually inspire people. You don't have trips, they go get inspired, you know, so just, I just wanted to highlight this example because it kind of fits in very well in this context.   Because you don't do it the other way around. You kind of understand the flow of the user and then figure out now, if this is the flow, what are the screens that I need to build to support this flow, right? And how are people actually going to navigate through those flows?  I think people underestimate what a navigation can do. I actually come, I mean, I was not able to actually get a good example, but many times you land up on a site and you don't realize what the site actually does. I mean, I'm sure a lot of people have actually experienced that, especially when the service is new. And I guess all of you probably are building products where they are unique and they don't exist. They don't have any, there's nothing familiar, users are not familiar with that concept at all. So, I mean, think about how you structure your navigation because that can actually be a design, it can actually communicate a lot about what your product does. I mean, I'll just give you an example.  There's basically, if you notice, there's like, you know, you have the search projects products and they have an arrow because like, that's just to indicate that like, if you click on those, the context will be maintained. You'll kind of be in that same, sort of that same interface versus if you go below, you would actually land up. So like, if you see collection and need to go in small world, that the context completely changes. You don't have, you don't no longer have the left navigation. If I put the arrow, user would actually expect like the site to open up right there. So think that there are, you know, small set of queues that you can give users to kind of explain what the product or what they should expect. So from site structure, moving on to at a very screen level, right, if I mean, you guys did voting pass and you did the, I guess you guys really thought about how can I actually present this same information in a way that's, it can be consumed really easily and it kind of, you can get all the key information points in like at a glance, right? So that starts with really understanding what's important, like driving the same point, what is really important and then you kind of start with that and everything else kind of becomes secondary, right?  So if you notice, pretty much everything in the itinerary is flat, right? Now, obviously, that's not how users expect it to be, right? This is what the new book flow looks like. It's a, you know, you can actually get a sense of the itinerary at a glance compared to this, like you have to actually really, you know, get into details and really like read all the information, right? You are like, for example, economy is at the same level as the flight details or at the, you know, and if you look at, you know, the departure airport, it's all jumbled up, departure and date is all jumbled up. Here actually it's kind of broken into smaller pieces so you can actually consume it layer by layer.  Anyways, another example is like our hotel details page, right? So this is what our hotel details page. Again, you know, it's just completely flat, you know, self-service, like we are not kind of saying what is important here, right? So we said, why don't we kind of, you know, improve that? So, you know, you're through the hotel details where we're basically highlighting, you know, how good is the hotel, right? Basically, pretty much all the, so just see this, even though there's a lot of content on this page, this with very less information says so much about the hotel, right?    And in fact, what we're doing is, you know, we're thinking minimal on the mobile and then bringing it back to the desktop. So, yeah, I mean, that covers, you know, the structure, the page structure part of it. You know, how do we actually deliver that at a glance experience? Moving on to the presentation layer, right? So when it comes to presentation, right, so now let's look at bill payments, right? I think the first thing that, you know, you would like to think about when you come down to actually building or rather, you know, creating a visual style for the site, is really thinking about all the metaphors and keywords that are associated with bill payments, right? So, you know, there's cash, there's a card, right? There are bills, actual bills, right? So can you collect, say, I mean, or rather the way we do it is we start collecting visuals that are related that kind of inspire us to take the direction for the visual design, right? So everything, so first make a, like, a list of keywords and, you know, what are the associated keywords and then start collecting visuals that kind of start inspiring you about colors, typography and stuff like that, right? And I think this exercise also will kind of give you a sense of what the treatment and voice and character should be for the site. I'll give an example, Expressway, again, this is what actually we started off, right? I mean, when you talk about Expressway, we kind of, you know, started collecting these sort of highway signboards and this is what we came out with, right? And obviously this is not the kind of, this is not what we wanted to communicate, it feels very informal, it's not, it doesn't feel, you know, sort of trustworthy.  And this is what we finally came out with. So I think, I mean, this is also a very iterative process. You know, you would come up with visuals, you would collect visuals, you would kind of go down a path, realize it's not working, you know, go back, start from scratch. And it's just that basically, you know, following this process just makes you conscious and it's very easily reproducible, right? So like, for example, if this retro style, you know, visuals are not working, maybe I need to take a slightly different approach, right? Just, I mean, I think, but it's important to kind of be able to reproduce that. The other way to actually do it is like, you know, building inspiration.  It's actually a way to convince clients more than anything else, but actually it can work. In today's scenario, you have Pinterest, you can actually go look for a lot of images, put it in one place. So this is actually a board that Anand created. He actually is going to speak tomorrow. You know, he's leading design at Cucumber Town, and he's written a fantastic article about how to choose a typeface.  Cucumber Town is all about, you know, chefs and people are kind of sharing recipes and stuff like that. So, like, his inspiration was really, was derived from food graphics, right? Like, what kind of labels are out there that kind of show up on food items, right? So, I mean, this is very easy to do. You don't have to kind of, you know, go cut news papers and stuff like that. The other aspect is, which is very important, is basically, you know, like, refinement and detailing, right? Like, that plays a big role, at least I mean, like, we spend a lot of time doing that.  So, at this level, you kind of really look at alignments and, you know, how do you kind of refine that visual hierarchy through this process, right? So, I'm giving you some examples. There's a, if you look at the site, I'm just kind of drawing attention to all the details that have gone into the, I mean, design of the site. I mean, that's probably one of the reasons why it looks clean, at least I think it looks clean.  So, from there to, you know, forms alignment, so like this, the loader bar is actually exactly double the size of the mother deal and the sort bar, right? So, when it actually, so if you notice, sorry, so when it actually finishes loading and actually, you know, transitions out, it uncovers the content below that, right? Without any sort of extra lines or anything like that.   Users will finally do what they have to, but like you could actually guide them. So, I mean, this is how we expect the users to actually go through or consume content on the site. The fact that, you know, there is something loading and there is an animation, your kind of, your attention goes to that, right? And then obviously, I mean, the fact that it's loading, you kind of start noticing things around this page, right? And then basically, once the results actually load, your focus goes towards the result. And I mean, I'll showcase how this actually happens, right? So, we have, if you look at it at a very sort of minute detail level, I mean, this is how it's layered, right? So, I mean, literally, we have, I mean, these layers in terms of what do you call it? They're very subtle, but actually it's there, right? So, coming back, now the fact that the results are loaded, you know, there are multiple ways to consume the same content, right? So, you could basically, you know, look at each unit at a time, you know, if you're concerned with the price, you could compare prices, you know, I mean, and you know, if you're kind of already this, if you already, if you're kind of interested in one particular flight, you're actually now only consuming that unit, right? You're not looking at anything else.  I mean, so moving on, I mean, moving on to the transitions, right? So, I mean, I believe that basically transitions work if you kind of use it, you know, it's not all over the place, you kind of use it smartly. It can actually bring a lot of character to the product. Just giving you some examples. This is what, I mean, just showing you some sort of transitions on being to go, right?  Like you say, if I like, you know, you have a search bar, that same search bar shows up in the page inside, can we kind of transition it, right? So, there are multiple transitions here. One is basically the search bar moves up to the top. Then at this stage, you know, we don't have the root information and you only see the icons for the mode transport and as soon as we get information about how long the roots are, we actually kind of build the root and that's also animated. So, like, we didn't get this on day one. It was just like, you know, this looks very abrupt. Can we actually make it more natural and stuff like that? So, I think, don't think about these on day one. Like, kind of look for these patterns. You might find them and like, if you're able to pull it off, I think it kind of adds a lot of fun factor to the... So, this was another thing, right? So, initially, I mean, we have, you probably, if you use Queer Trip regularly, we have basically a modified search button there and then essentially it shows the search form and that search form used to have a calendar. So, basically, when you want to modify, you can see, I mean, you can see what are the prices if I want to change the dates and stuff like that because people really change the dates. And we saw, we noticed that a lot of people actually use the modified dates. You cannot move that calendar outside so that people don't have to hit Modify Search because basically, you know, they just use this calendar from here and when you hover, you can actually see the rates. So, but people are so used to using Modify Search, like this got completely missed in the beginning. So, a lot of people started complaining, hey, where is the calendar in the Modify Search? So, great opportunity to actually do two things. One is, you know, retain the calendar inside and then also draw attention to this calendar. So, basically now what we've done is this came later on. So, the same calendar actually transitions in place. It kind of does two things. One is obviously it's available outside but also kind of reminds you that this is available outside. So, again, you know, something that we have not thought but it just kind of, you know, we saw that pattern, we got it working. Another transition we wanted to showcase. So, like this is, we wanted to bring in that sort of, you know, delight factor. Every time somebody finished a step. So, yeah, this is a small, subtle thing. So, yeah, I mean, like I'm kind of covered with, you know, the examples, the whole idea, you know, to show you that was to kind of get you thinking while you actually work on this assignment is that you could actually look at all these things while building it. And so moving to the design exercise. You guys, have you shared the view? Has anyone been able to access that page? Yeah. So that, I mean, this took, yeah, it's a good exercise. This to give you, so, you know, obviously, we were talking about the fill payment application but we're not basically looking at the entire application because, I mean, obviously, we don't have too much time. In fact, I mean, just now we have just 45 minutes. So, we've got to kind of sprint into this. So, the scope is essentially looking at just the dashboard of this product.   And, you know, how do you give this user a summarized view of his account, right?  Yeah, I mean, basically, we're just going to kind of focus on this aspect. We're not going to look at the entire, we're not going to look at the entire application, but just think about what the navigation should be and what the dashboard should be. And I think the only difference between the previous one and this is that the credit card statement was, I mean, we started off with, like, a voting pass, which was very small, a very small problem to solve, the credit card was just static. This becomes a little dynamic. There's a little bit of, there's a timeline involved. So, yeah, I mean, how does, how do you, how does the product respond to different states of the user, right? If he's like, I've already kind of drawn attention to the fact that does the product talk to a guy who's coming for the first time differently versus a guy who's, you know, added a bill versus a guy who's slightly advanced and has multiple bills and stuff like that, right? So, yeah, I think that's the scope. We have 45 minutes. I mean, obviously, there's lunch after this. So, I mean, yeah, you guys want to, like, you can continue working on this. Even, you know, we can extend it a little bit. Do you think you can buy a frame out of this or just ideas? Buy a frames. Yeah. And like I said, we don't end at that. Like, I mean, one o'clock is not where this assignment ends. You can feel free to kind of, you know, go back, define it, and we'll kind of, we're trying to figure out how to showcase your work during the conference if you're going to be taking the conference later on. I think it's good to kind of take this to finish line because, you know, all the stuff that I spoke about, we were able to at least, you know, cover, you know, everything till the presentation will be great. But, yeah, it depends on, you know, how much time you guys also have outside of today and tomorrow. Some things could be done as a applying delay in some group. Yeah, sure. Yeah, it's on the meta-refresh hashtag. Sorry?  So, the logos are quite specific. Yeah. Yeah. Yeah. Yeah. So, I mean, I think you kind of just ask yourself, right, does this basically, you know, communicate trust? I mean, is it, like, is it a logo that people have trust, right? And it's too playful for you to trust it, right? You would trust, so if you look at the actual icon or the tiny logo that we came out is like, is the sign that you can go ahead. I mean, you have those signs. You trust that, right? You look at that and basically, you know, if you trust that visual, so I think that's really the framework, right? What is, you need to ask yourself, what does the brand need to communicate? If trust is one of those things, then, yeah, I think it's express way, but it doesn't communicate trust. So, I think that's the real reason why it didn't fly. Yeah. Yeah. Yeah. Yeah, exactly. Yeah, exactly. Yeah, exactly. So, it's got, I mean, it's got all the elements. You know, in fact, if you see the visual, if you see the campaign and all that, even though the name is express way, the image is of a runway, right? So, I mean, so you have flexibility.  So, it communicates, yeah, I mean, absolutely right. I mean, it does have the elements of an airport and I was talking about you trust that, right? Like, if it says, you know, this is the direction you need to go, you trust that. So, I think it has that sort of element to it also. So, twitter.com slash metarefresh, and we'll be able to see some things. People have access. You've put a hashtag. Who's not able to access that thing? It's not there. It's available, right? So, everyone's got the document. So, it's basically, I mean, it's the same, it's whatever I've covered in the last part, slightly more verbose. And I think, like, the idea there is that we don't have to, so, like, for the purpose of the exercise, we don't have to actually cover everything in that. It's just, like, you can use this for future reference when working on a product, but, like, it covers, like, the scenarios aspect. So, you can, you feel free to, you know, refer it, I mean, you don't have to cover all the points there.


Hi, so I'm going to tell you a little bit about the Strategic Opportunity Support Program. I'm Melanie Funes, and I'm really lucky to be able to work with Dan Loenstein, our director, and with our incredibly talented program coordinator, Ms. Juliet Faulkler, who should be recognized for her immense contributions to this presentation. So what is SOS? The Strategic Opportunity Support Program is CTSI's pilot funding program. We issue about $1 million per year in research support to UCF faculty at all schools. We have 14 different grant mechanisms which span from pilots to technology to shared instrument, multidisciplinary, multi-center, and career development. What I want to talk to you a little bit about today is two ways in which we've had an impact at UCSF, and then ways in which we impact the community beyond UCSF. So at UCSF, we've contributed to building infrastructure. SOS initiated the Resource Allocation Program, or RAP. RAP actually brings together all of the funding agencies on campus. It simplifies intramural funding by providing an announcement, one application and one deadline, a single process for review and a funding decision. It increases, it has increased the research support at the university by working together all of these nine funding agencies. In the last year, RAP issued about $3.5 million and 119 awards. And over their span, they've issued actually over $12 million. RAP, although it was initiated at CTSI, became a campus-wide resource and it recently moved to the EVC's office. We've also impacted research funding here at UCSF. In the first five years of CTSI, we issued $5.5 million and 183 awards. $3.9 million in the first four years was issued to support research, and that subsequently led to the recruitment of $44 million of research funding. When faculty were asked what the role of SOS was in recruiting funding, they responded with, it was critical, it was crucial, it was essential, it was invaluable. I put up this quote from this faculty member who says that the SOS support was absolutely essential toward their efforts to obtain subsequent funding. But not just that, it's, without this support, it's entirely possible that I would have converted to a clinical role or left UCSF. So how do we impact beyond UCSF? I want to tell you about three specific examples, particularly dealing with policy standards of care and therapeutics. So just in short, one of the examples that deals with standards of care is an award that SOS gave for what's commonly known as bubble boy disease. Obviously, you know, we're one of many contributors towards the success of these programs. We're not trying to take, you know, full credit. Ultimately, this investment led to the faculty member being able to recruit $4.4 million to establish some really huge partnerships that led to a statewide newborn screening program. The infants identified with SCID are actually treated here at UCSF. And recently, this became statewide legislature. It now is added to the list of diseases that California newborns are routinely screened for when they're born. A second example is prostate cancer. In this case, a faculty member was given an SOS award to look at a molecular imaging technique. As it turned out, this molecular imaging technique could be used as a companion biomarker to therapy commonly used in treating prostate cancer. They were able to recruit $4 million in NIH funding, and this agent is actually right now in phase one clinical trials here at UCSF. And the final example that I want to talk to you about deals with policy, and in particular, sodium intake and coronary heart disease. Dr. Bibbins Domingo was awarded $30,000 from SOS to look at adapting the coronary heart disease policy model to address disparities in heart disease. She developed a new version of this model and was able to use this new version in subsequent studies with the most major one being published in the New England Journal of Medicine in 2010, which tells us that reducing daily salt intake can reduce deaths by coronary heart disease at an average of 75,000 people per year. It influenced policy guidelines on sodium intake and was published in the Institute of Medicine's guidelines on strategies to reduce sodium intake in the United States. So with that, I'll just say thank you. So thank you, Melanie. I just want to clarify, so that's a 12-fold ROI on the investment in SOS? Roughly, yeah. And those are additional funds that they attribute to getting the small grant? Yes, that's correct. Okay, good. David, do you want to start us out? Well, one of the things, as I'm hearing the word strategic, you've got different cores that are within the CTSI. So we're hearing about recruitment core and we're hearing about the clinical core overall. And as I'm listening to that, I'm just wondering if part of the thinking is the strategy of using the different cores and facilitating what's going on. So there's some pilot funds. Is there thinking with the people about how other services may be used in thinking of their work as a pipeline? Absolutely. So SOS actually has a CRS award that we partner with CRS to offer to the community. And that includes funding for faculty members to use towards research that they're going to do in the CRS group, but also I think in other areas. Yeah, and is Julie Auger here? Yeah, so and we're working with Julie specifically on a plan that does what you just said. So to provide small grants to people to allow them to use cores across campus. Talmage. The small grant idea is a wonderful one that often it doesn't support salary, doesn't support salary or not. And usually, the people who have the bright idea are the ones with no money. I wonder how. So Melanie. So SOS awards actually do allow for salary. Okay. Yeah. Yeah, plus we've been putting a lot of energy into getting other grants for junior investigators.  That's a lot of work to support those. And those are the ones with no money, with good ideas who really need that launching. All right, Sam. Yeah, I think the RAP program is just a great testament to what the CTSI was able to do in its first cycles, bringing disparate groups together across campus to come up with a cohesive funding model. I was wondering about where you're thinking is in terms of where do we go next with this? Because I think in the early phases, you really did consolidate all the available funds. And now are we just in a maintenance, making sure they're used well? Or where are you thinking about taking this to further. Expand this idea? So there's two things. So yes, we're in a maintenance mode of making sure that the awards that are offered continue to be offered. But the second thing is that SOS can actually be used as a platform on which other programs can build new awards. So we're currently working with BMI to add another award for M Health. And I suspect that in the future we'll continue to collaborate with all the programs across CTSI and across the university to offer new funding opportunities. Have we reached outside in an explicit way the university to foundations or industry or anyone else to contribute to try to make the pot bigger? No, not for SOS specifically, but we should. I guess it's worth putting out that since it's now in my office, it's sort of like our responsibility to do that. For RAP, yeah. Yeah, I think that's what we're talking about, RAP. And so we've actually started reaching out to industry to see whether some of the funds that come in there could be put into a pot for that. We've talked to a variety of organizations. We're just now, because we've just taken it over, but I think your point's perfect. We need to use this great start and now see if we can expand the pool. Yeah, and actually we have been doing that too outside of the traditional grant program. So you'll hear later about the T1 Calis program, for example. And that's one that's where we have a lot of interest from industry to co-fund it. So yeah, foundations is another place too. Already there are some donations from foundations that go to specific awards within RAP, and that could increase over time as well.