Accelerating Development Using UI Frameworks

Patrick Mooney at UXDX Community: Dublin. Video: https://www.youtube.com/watch?v=4Zc2Ka2zOKk

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and the Optum design studio

[00:00:10] Thanks, Catherine [?], for the opportunity to speak today. This is a really exciting topic for me, and hopefully you will get to understand the importance of a UI framework. UI framework is a very odd term. It was actually my manager who said to me about a year and a half ago, "Patrick, I want you to write an article about UI frameworks." And I'm like, "What's a UI framework? I've heard of web frameworks, design systems, pattern libraries." So I want to explain what a UI framework is today.

[00:00:39] Just to recap on who I am: I wrote my first application back in 1991, some time back at this stage. It was an interactive adventure game where you could navigate around this world, almost like Game of Thrones, and you could decide to go left or right or to fight someone. And it was all done in WordStar. Does anyone remember WordStar? It was a challenge. The first thing I did when I got my first computer was build an interactive application. After that, 18 years with British Telecom in various careers. My background is in software engineering, but I moved into design because I realized, "I've got a calling here. My calling is actually user experience; there's a name for this." So that was quite interesting. I had various roles there; content management was really the core of my career, and information architecture.

[00:01:24] Yes, I do run Dublin UX, but my day job, which is essentially also my evening job and my weekend job, as I'm sure some of my team members here can testify, is actually running the design studio in Optum. I want to show you this video about Optum to give some context as to what we actually do and why we do it.

[00:02:43] That's our new brand campaign, and I think it really resonates with what we actually do, and what we do as a studio. Optum: we're a small company, and I'm sure maybe one or two of you may have heard of us. Revenue last year was 101 billion. We actually report into UnitedHealth Group, 226 billion, so a very large company. There are about 300,000 of us working in the company today, and within Optum there are 85,000 nurses and doctors working for us. So what do we do? We're out there enabling people to live healthier lives, and we're making the health system work better for everyone. Within the studio here in Dublin, we're designing solutions which practitioners and doctors and nurses get to use on a day-to-day basis, and which members and patients will also interface with. So it's a very noble cause.

[00:03:27] Now, most people will recognize me from Dublin UX, which is one half of who I am. The other half is the studio. This is my studio. It's a very collaborative studio, definitely built on culture, built on trust, built on respect, and built on shared learning and understanding. And this really resonates nicely with the team at UXDX: that shared understanding of bringing developers and designers, researchers, product managers, everyone, together into the one conversation. So important. Our studio is about 160 of us strong. We are user-centric, we are full-service, we do everything, and we are the powerhouse behind NPS. I'm sure people have heard of NPS, Net Promoter Score. We're the ones who are driving our NPS figure up through a user-centric approach.

Why teams end up with Frankenstein websites

[00:04:16] Now, I'm here today to talk about UI frameworks. Design systems: okay, show of hands, who has heard of a design system? Great. Keep your hand up if you use a design system today. Fantastic. Keep your hand up if it's a design system that's been built just for you. Okay, fantastic. I want to talk about the use case for using a design system. I want to go back to some of the history of design systems, where they came from and how they've influenced web frameworks today; the benefits of using a UI framework; and how we within my team, and I've got an 11-person team working for me in Dublin, actually build UIMF. It's the user interface management framework.

[00:05:00] But let's rewind a little bit. This tale is one you will definitely recognize. We tend to work for global companies; Zendesk, as we mentioned earlier. We're looking for connection with clients in the US and stakeholders globally, and communication becomes a big, big barrier to moving forward. We've got team members working in different cities, across multiple time zones, across multiple locations. We all have deadlines, and that can be a problem, because once communication breaks down, you get a trust issue and you get people going off on different tangents.

[00:05:36] Pressing deadlines: we've got to ship in two weeks, we've got to ship in a month. What happens? We're working in agile, so we're releasing code, at least for a design system, every five weeks. We've got tight windows, we've got to push things out, and as a result you can get inconsistencies in your UI. That's called a Frankenstein website. I'll talk more about Frankenstein websites later on, but they can be a result of those quick decisions. There's no alignment, so you can get things looking a little bit odd, and you're wondering why that's the case. And that introduces technical and design debt down the road.

[00:06:08] A good example here is that Mary is working on feature one, as you can see there, a sign-in system. But in the same application, as part of it, you can have James working on another feature, a separate team, not necessarily talking to each other. And you can see, okay, it's more or less the same, but no, it's completely different: you've got the labels in different locations. Along comes Josh working on feature three: different colors. Yes, it's all functional at the end of the day, it all passed QA testing, but when you put it on a wall and look at it all together, it's all completely inconsistent. So we're dealing with global teams, we're dealing with pressure, and that makes decisions like this.

[00:06:44] The next one is that we're dealing with increased complexity. We're deploying into multiple environments at the same time, multiple devices, whether it's desktop, tablet or phone. And again, that can create problems. You may end up introducing new patterns based on the environment in which you are deploying.

Patterns and where they came from

[00:07:00] What's the solution? It's a design system. This is a lovely definition of a design system: it's a set of connected patterns, and I'll define a pattern in a moment, and shared practices, which are coherently organized to serve the purposes of the digital product. So you've got two core elements there: your patterns and your shared practices.

[00:07:29] A pattern: I've got a small screenshot here from the BBC GEL. I love what the BBC are doing; they've really documented this in what I feel is a first-class way. A pattern basically describes how something should work under the preferred conditions. A navigation system, an accordion, a button, a sign-on journey, whatever it is: the pattern describes how something should work under the preferred conditions. It's repeatable; it can be reused anywhere within the interface. And most importantly, it's skinless. There's no color, there's no real skin applied to these patterns. If they're used correctly, they're independent of skin, which means you can rebrand it, you can white-label it, you can reuse it over and over again, and the pattern remains consistent.

[00:08:20] It's been created to solve a specific design problem, to meet a need or evoke an emotion. I think that's quite nice. It's frequently documented in the form of text, or maybe just gray diagrams. You know you're not dealing with a pattern system if you've got lovely colors in there, or code; there are other ways in which you can document it. It's really heavy on documentation.

[00:08:45] Let's rewind a little bit. Where has this concept of patterns come from? We go all the way back to the 1500s. I think this is wonderful: The Four Books of Architecture. It's one of the first reference books that talked about patterns. Andrea Palladio produced this book to document how construction was going to be done in Italy, in Venice. It's a series of rules and vocabulary and patterns and principles for any new designer or architect to build a structure. So all the way back in the 1500s, this book was created to put some sense on what was going on within the industry at that point in time, to document those patterns. And each pattern would have a clear illustration and descriptions of how something should work.

[00:09:36] Something we don't talk an awful lot about is anti-patterns: you should actually document how things should not work, because sometimes that's more important. If you give a design or development team a series of instructions, they can interpret that; it's all up for interpretation. So it's good to document the anti-patterns as well.

[00:09:52] So, back in the 1500s. Let's move on to the 70s, 1970s. This is a very interesting book, and actually my own manager has named his kids Christopher and Alexander, I found out, as a result of this book. He is so passionate about pattern libraries and systems. This is A Pattern Language, by Christopher Alexander, and the purpose of this book is to document how urban planning occurs. If you're going to have a network of connected facilities, houses with shops, post offices, what's the best pattern to build a village, so it's going to be effective and it's going to work correctly? Again, this was designed to be rolled out at scale to build up new communities.

[00:10:37] It had a very clear structure. It had a name, it had the problem statement that was trying to be solved and addressed by that pattern, pictures, of course, when to use it and when not to use that pattern, and then guidelines. So again, we're not looking at digital interfaces here; we're looking at physical environments, and we're using patterns. Again, in the software industry, this was a very popular book in 1994, all about object-oriented patterns, one of the first books on this topic. And again, it allows software engineers to reuse these patterns. There's no need to reinvent the wheel every single time.

Visual identity, guidelines and pattern libraries

[00:11:13] This is what I quite liked, back in the days of the 70s again, when people began to start documenting their visual identities. We have another pattern system: this is the NASA Graphics Standards Manual. This is open sourced; it's available. I'll tweet the URL. It's available as a downloadable PDF, or there was a Kickstarter to get the printed copy of the book. And I thought this is quite interesting, because NASA, in the 70s, the space race and so on, created this pattern library. It's not for the web, it's not for apps. So what was documented? The typography, for consistency. The layouts for mailing envelopes and press releases; that's pretty incredible. Publication grids: if we're going to write some articles or publish books, exactly how to lay things out. The branding of vehicles, pretty fascinating. The branding of clothing. And of course they also branded the shuttles.

[00:12:23] So this standard for the visual identity was produced. Pretty iconic. It's open source; it's a really interesting PDF to download and read. So we got into this practice of documentation. We like to look at rules and look at process; especially in UX, UX is all about process. This is a great example from Apple, back in 1986: their first Human Interface Guidelines. This has continued to evolve. At one point in time they were publishing these documents; now they're available as live websites, and it's continually changing. It's a live website because it's changing so fast.

[00:13:01] When we had the rise of the graphical user interface and the web came on, this really changed everything, because there was a race to get applications out there. I remember I started to write my first lines of code back in the 90s for Netscape browsers, and then IE3 as it was. We always had changing sets of standards with the web browsers, so we were using blink and marquees, and everything was all over the place. Of course, then the iPhone, and there are other competitors now, but look at all these different shapes and sizes of iPhone. You bring out a pattern: how do you grow that? How do you keep that consistent? Again, we like to document, and look at these sample books from O'Reilly from 2005 to 2014, and there are many more in between. For some reason we just love the concept of writing books and documenting it: "This is the right pattern. Get it out there. Everyone do the same." That's interesting.

[00:13:55] So that's a pattern. Let's look at components. Components are how something works inclusive of the constraints in which it's being exposed. A pattern could be an accordion: how is that going to work on a mobile versus a desktop? The components are the building blocks that bring all that together. They can include design, and sometimes they can even have code in there. So you've got components. And I'm sure you're all aware of a style guide or a pattern library. That's the tool to capture and collect the patterns, and it traditionally focuses on style; it doesn't necessarily include code. So it's a bit of a fragmented market here: we're looking at patterns, components, style guides and pattern libraries.

[00:14:40] Let's talk about pattern libraries for a moment. I even remember this: the Yahoo pattern library. It's no more; this is a screenshot I got from the Wayback Machine. It's gone. The history of this is quite interesting. It was back in the Ajax days of 2005, after the Ajax summit. I remember writing my first Ajax applications: "This is going to change the world." It was the Web 2.0 era. The question was, how should interface designers account for the rapid incremental UI updates that Ajax makes possible? About a year later, Yahoo released this pattern library. Essentially, if you went along to it, you could look at a pattern and look at the use case and get this wonderful component that you could download, with reference code. For the first time, not only was it the visual part, you were getting code, and you could actually use that in your applications.

[00:15:32] That was great, but that meant they were all the same. They were all consistent, and if you were using the Yahoo component library, you knew you were using the Yahoo component library. It was one way to do everything. So a year later, a Danish web developer came along and created this, UI Patterns [?], which is still live today. What's quite interesting about it is you can go along, look up one pattern, and it will give you that one, but maybe a hundred different options, so you can be inspired by that. And this is where it gets back to what a pattern is meant to be: the way something works, the functions. And then the component is essentially the actual interface put on top of that.

Web frameworks and atomic design

[00:16:07] Pattern libraries have evolved. At the same time, our development community has created web frameworks: jQuery and jQuery UI; we've got Bootstrap, download the CSS and the HTML from that; you've got Angular and you've got React. Again, this is a market that's changing, and these web frameworks are tying you into maybe a particular look and feel. That's just fine, but we've got to respond to that.

[00:16:36] I'm just going to introduce atomic design for a moment. Is anyone familiar? Hopefully we're all familiar with atomic design, so I can go pretty quickly through this. Brad Frost introduced this back in 2013, and it was essentially using chemistry to understand how we build applications. You've got atoms; matter is comprised of atoms, which are bonded together into molecules, combined into organisms, and then you've got ultimately the universe. When we look at that, here are some examples. An atom here could be an input form, a button or a label. Combine them together into molecules. Combine them even further, and now we're getting the basis of a website. We can take that further into page templates, and then the pages. A wonderful concept, and most of our modern UI frameworks will be built on atomic design principles.

[00:17:27] But there's a problem. What happens if you start taking these molecules and combining them together? Do you really get the right results? Sometimes, no. You'll get Frankenstein websites, where you'll get a little bit of this and a little bit of that, and all of a sudden you get a bit of Material Design intermingled with Bootstrap, joining with Salesforce Lightning, and you're like, "What's going on here?" It just looks incoherent. Be very careful of that. And this is where documenting a pattern library is so important: to make sure you document, "Don't put these two together; it's not really going to work too well. Don't put a secondary navigation at the top; keep it a primary navigation." Just because you can do it doesn't mean you should do it.

[00:18:05] There are some great examples out there. For example, Salesforce Lightning is, I think, one of the great examples. When you actually view the documentation that goes in there, there are atoms; it actually references atomic design within the documentation itself. To me, that's incredible, that they've actually built this design system with atomic design at its heart. We can then move on to what Google has done with Material Design, published back in 2014. It's pretty old at this stage, but as a result we get a lot of applications now looking like Google, which is fine, but how does that work on iOS?

Building UIMF, a full-stack design system

[00:18:39] What I like, and I'm in an enterprise, a classic enterprise: we want things to look like Optum. We want things to look our way. But we want to allow our developers to code using Angular, using Bootstrap, using vanilla JS, whatever they want. But we want consistency in there. So about eight years ago, before I joined the company, we created the user interface management framework. We've been building this design system, this pattern library, this UI framework for about eight or nine years. In the last two years I've built a co-located team here in Dublin to evolve this, take it to the next level, and regenerate it. It's taken about a year, and we're going to relaunch it at the end of the year with a brand new team and a scalable platform behind it as well.

[00:19:26] Now, why a UI framework? A design system has these core building blocks: patterns, components and a style guide. What's missing from this? Accessibility. Are we documenting accessibility? Does our design system actually make affordances for accessibility? Does it make affordances for people who are going to be browsing using keyboard only, or for people who are browsing your website using assistive technology? It has to be there. Is your pattern library very visual, or does it actually contain code? Does it support frameworks? Does it support Bootstrap? Does it support Angular? Does it support Vue and React? And do you get design tools in there?

[00:20:10] When we look at all this together, we get this concept of a UI framework. A UI framework is sometimes called a full-stack design system, because it contains everything: everything for both the developer community and the design community, and product owners and everyone in between, to get results from it. So that's a UI framework. What I think is quite interesting with the UI framework is that it supports multiple web frameworks, not tying you into one. That's always been a barrier for us. When we created UIMF eight years ago, it was chosen to support Angular. Then Angular 2 came out; that's a big rewrite. Then up to Angular 3 and 4, well, up to 4, and now we're constantly having to support Angular; a new one is coming out maybe every six months. So we realized we've got to decouple that. We're actually decoupling Angular from our framework, and that's quite important.

The benefits of a UI framework

[00:21:00] So why use a UI framework? Why spend all this time? Again, faster speed to market. Any dev team consuming this doesn't have to start from scratch. We're an 11-person team building our framework, supporting today around about a hundred different products within Optum. They just come along, download this from GitHub and get going immediately. That's so important. It promotes a lot of code reuse and reduces ramp-up time, so that's the investment. Lower cost there, because you've got a foundation to start from. Improved consistency between applications, and we want that: we want to have one unified experience within the enterprise. And higher quality, because we're now getting code which has been tested. It's gone through a continuous release cycle, it's been validated with QA, we've had users test it, and we've actually done accessibility audits on it. So you're getting higher quality.

[00:21:55] Which brings us to accessibility audits. Yes, we're WCAG 2.0 compliant today, and we're looking for WCAG 2.1 compliance at double-A towards the end of the year. So anyone consuming our framework will get that out of the box, and that's pretty important. And UI pattern consistency: very important. Design tools: at the moment we are a company that's split between Windows and Mac, so we make tools available for the Adobe suite, we're moving tools over to Sketch, and we also prototype in Axure, and use Axure as our deployment for a lot of our designer-type tools. Design consistency, responsiveness and testing: ten core benefits, if you're looking for benefits to justify investing in or using a UI framework.

[00:22:41] How do we actually use this today? We've got developers and designers all using our design system and our framework today. The designers can use our Adobe plugins, they can use our icon libraries, and they can use our Axure components; we've got Axure in the cloud for that. Our developers are using our Angular components; we're moving it over to be more vanilla towards the end of the year. Easy to install: npm install, and there you have it. It's just so straightforward.

[00:23:10] And we've got a showcase. This is our showcase, which demonstrates everything. It's so important to have a showcase where you've got all your code documented, your UI libraries, your patterns, your anti-patterns, and anyone can come in. This is the very latest version, released April 10th, version 6.100, and every five weeks we're spinning out new versions of this. It cannot stand still. We've got customer sessions every five weeks where we engage with our customers: what do you want, how do you want us to develop this? We're developing this for the greater company. If our users aren't using it, then it's simply not going to be adopted. So this showcase is very, very important.

Summary

[00:23:50] We've come a long way over the years, from just coding freehand, to using UI libraries, to using web frameworks, and now ultimately these full-stack design systems. It's really bringing the design and development teams together so they can speak in uniformity. For me, I think it's great having events like this to bring these worlds together. And for me, the cornerstone behind my team and what we're doing in our studio is this design system. It's firmly owned by the design team and then gifted to the rest of the company. It keeps everyone aligned.

[00:24:25] It's nothing new. Everything here goes back hundreds of years. We've constantly been on a search to create uniformity and document it. We've got examples of patterns going all the way back to the 1500s. I personally quite like the NASA one, if you can take a look at that PDF. The web explosion has been really interesting to see, and design systems have supported that web explosion. And then atomic design allowed a standard vocabulary that we can all understand. The UI framework, or the full-stack design system, is essentially the modern evolution of that. With Optum, we use UIMF, the user interface management framework. So that's it in a nutshell. For me, design systems are pretty powerful; they're pretty incredible. I spend at least half of my week with my design systems team, constantly evolving our roadmap and pushing things forward for the greater good of the rest of Optum. So with that, I'll open to any questions.

Q&A

[00:25:55] Patrick: [The audience question is not captioned.] ...it's important to you. We do open source, but it's called inner source, because the GitHub repo we have is internal to the company. It's designed to be extended. So if you create a new component and you want to gift it back in again, we encourage you to do that. We will bring that into our backlog, we'll do the accessibility checks and auditing on it, make sure it's compliant, and then we'll make it available for everyone. Having it in one location means that it will happen. If we're dependent upon the kindness of strangers, it simply is never going to happen, or we'll end up with a Frankenstein design system. So we have to have ownership of that.

[00:26:31] One thing we've changed in the last year: we used to have design spread out. We had design councils, and we'd have a design council working on a new pattern here, a new pattern there, and as a result we had inconsistencies. They spent a lot of time doing administration. So in the last year I've actually hired a dedicated design and research team for this, in addition to the development team. Again, it's ownership. But we do use the process of crits to get as much input into it as possible. We're constantly validating; we've got continuous research now embedded into it, so constant validation of what our users want. Because if our users aren't using it, we're not going to get the tacit funding and it's simply going to die. So you have to keep it fresh. But having that central ownership is pretty critical, and it is why we've been so successful over the last eight or so years.