Accelerating Development Using UI Frameworks

So thanks, Catherine, thanks for the opportunity to speak today. This is a really exciting topic for me, and hopefully you will get to understand the importance really of a UI framework. So UI framework, it's a very odd term. It was actually my manager said to me about a year and a half ago, Patrick, I want you to write an article about UI framework. What's the UI framework? I've heard of web frameworks, design systems, pattern libraries. So I want to explain what a UI framework is today. So just to recap on who I am, so I actually wrote my first application back in 1991 sometime back at this stage, and it was an interactive adventure game where you can 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 word star. Remember Word star and MS-DOS. It was, yeah, it was a challenge, but it was the first thing I did when I got my first computer was build an interactive application and spent actually in total about 18 years with British Telecom, various careers. My background is in software engineering, but I moved into design because I realized, Oh, I've got a calling here. My calling is actually user experience as a name for this. So that was quite interesting. Various roles. Their content management was really the core of my career there. That's information architecture. Yeah, I do run in UX, but my day job, which is essentially my evening job, my weekend job as I'm sure some of my team members here will can testify is actually running the design studio in Optum. So I've got a little video here. I want to show you about Optum to get some context as to what we actually do and why we do it.

That's our new brand campaign, and I think it really resonates to what we actually do and what we do as a studio. We're a small company. I'm sure maybe one or two of you may have heard of us. Our revenue last year was one hundred and one million. We actually report into the UnitedHealth Group’s two hundred and twenty six billion. So a very large company, there's about 3 00 000 of us working in the company today. And within Optum are eighty five thousand nurses and doctors working for us. So what do we do? We're actually out there and we're enabling people to live healthier lives, and we're making the health system work better for everyone. I went in the studio here in July and we're actually designing solutions, which practitioners, doctors and nurses get to use on a day to day basis. And members and patients will also interface with. So it's a very noble cause. Now, most people will recognise me from Dublin UX, which is one half of who I am. The other half is actually 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 really nicely with the team where you exceed that shared understanding of bringing developers and designers, researchers, product managers, everyone together into the one conversation. So, so important. So we're a studio about one hundred and sixty strong.

We are user centric, we are full service, we do everything and we are the powerhouse behind NPS. I'm sure a lot of people have heard of NPS Net Promoter Score. We're the ones who are basically driving our NPS figure up through a user centric approach. Now I'm here today to talk about UI frameworks. So design systems. 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. Ok. Fantastic. So 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 about where they came from and how they've actually influenced web frameworks today. The benefits of using UI framework and how we would in my team have gotten an 11 person team working for me in Dublin who actually build a UIMS is the user interface management framework. Well, let's rewind a little bit. This tale is one you will definitely recognise is that we tend to work for global companies, Zendesk, as we mentioned earlier, we're looking for a connection with clients in the US and stakeholders globally. 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, really, because once communication breaks down, you get a trust issue and you basically get people going off on different tangents.

Pressing deadline. 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. Now that's called a Frankenstein website. I'll talk more about Frankenstein websites later on, but that can be a result of those quick decisions. There's no alignment that you can get things looking a little bit odd and you're wondering why is the case and that introduces technical and design debt down the road? A good example here is that Mary is working on feature one, as you can see there, and I sign in system in the same application, but a different part of it. You can have James working on another feature a separate team not necessarily talking to each other, and you can see, OK, it's more or less the same. But no, it's completely different. You've got like the labels in different locations. Along comes Josh, working on feature three different colours. Yeah, it's all functional at the end of the day will pass QA testing, but when you put it on a wall and you 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.

The next thing is 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 into 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. It's a set of connected patterns and shared practices which are coherently organized to serve the purposes of the digital product. So you've got two core elements there. You've got your patterns and you've got your shared practices. So a pattern. I've got a small screenshot here from the BBC GEL. Well, I love what the BBC are doing. They've really documented this. What I feel is this first class. A pattern is basically describing how something should work under the preferred conditions. So that's how something should work. A navigation system, an accordion, a button, a sign of journey. Whatever it is, the pattern describes how something should work on the preferred conditions. It's repeatable. It can be reused anywhere within the interface. And most importantly, it's minus skin. There's no there's no colour. There's no there's no real sort of skin applying to this patterns if they're used correctly or independent skin, which means you can retain it. You can white label it, you can reuse it over and over again.

The pattern remains consistent. So it's being 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 and maybe just gray sort of diagrams. You know, you're not dealing with a pattern system. You've got lovely colours in there. Or if you're dealing with code or you're dealing with other ways in which you can actually document it, it's really heavy in documentation. So let's rewind a little bit. Where has this concept of patterns actually come from? We can go all the way back to the fifteen hundreds. I think this is wonderful, the four books of architecture. It's one of the first sort of reference books that talks about patterns, and Andrea Palladio produced this book to document how construction was going to be done within Italy when in Venice. And it's a series of rules and vocab and patterns and principles for any new designer or architect to actually build a structure so all the way back in the fifteen hundreds. 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 as to how something should work, something we don't talk an awful lot about is anti-patterns that you should actually document how things should not work because sometimes that's more important.

If you give a design development team a series of instructions, they can interpret that it's all up for interpretation, but it's good to actually document the anti-patterns as well. So back to the fifteen hundreds. Let's move on to about the 70s. This is a very interesting book, and actually my own manager has named his kids, Christopher and Alexander Offender as a result of this book. He is so passionate about pattern libraries and systems. So this is a pattern language and if by Christopher Alexander. And the purpose of this book is to document how urban planning occurs to discuss if you're going to have a network of connected facilities, houses with shops to post offices, what's the best pattern to actually build a village? And so it's going to be effective and it's going to work correctly and again. This was designed to be rolled out at scale to build up new communities. It had a very clear structure, had a name. I 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 looking not at digital interfaces here, we're looking at physical environments and we're using patterns again in the software industry. This is a very popular book in 1994, and it's all about object-orientated patterns. One of the first books on this topic, and again, it aligns software engineers to basically reuse these patterns. There's no need to reinvent the wheel every single time.

This is one I quite like back in the days of the seventies again when people began to start documenting their visual identities. We had another pattern system. This is the NASA Graphics Standards Manual. This is open sourced. It's available on Twitter at this URL. Again, it's available as a downloadable PDF, or there's a Kickstarter to actually get the printed copy of the book. And I thought, this is quite interesting because NASA in the Seventies. Space, race and so on. They created this pattern library. It's enough for the web, it's enough for apps. So what was in this? What was documented was the typography for consistency, the layouts for mailing envelopes and press releases. That's pretty incredible publication grids. We're going to write some articles with the publishing books exactly help to lay things out. Branding of vehicles. Pretty fascinating. The branding of clothing. And of course, they have to brand the shuttles. So this guideline, this set of standards for their visual identity was produced pretty iconic. It's open sourced. It's a really interesting PDF to download and actually read. So we got into this sort of practice of documentation. We like to look at rules and look at process and especially in UX. UI is all about process. So this is a great example from Apple. Back in 1986 was their first human interface guidelines.

This has continued to evolve at one point in time. They are publishing these documents now. They're available as live websites and it's continually changing. Now it's a live website because it's changing so fast. 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 nineties for Netscape browsers and i.e. Tree, as it was. But we've all these changing sets of standards with the web browsers, so we're using Blink and Marqués and everything was all over the place. Apple, of course, brought out the iPhone and we noticed that there are competitors now. But look at all these different various shapes and sizes of iPhone. You bring out a pattern for one. How do you grow that? How do you keep that consistent? Again, we like to document and look at these sample books from a Riley phone from 2005 to 2014. And there's many more in between. For some reason, we just love the concept of writing books and documenting it. This is the right pattern to do. Get it out there. Everyone do the same. That's interesting. So that's a pattern. Let's look at components. Components are how something works. Inclusive of the constraints and which it's being exposed in. So a pattern could be an accordion. How is that going to work on a mobile versus a desktop? So 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 pattern library. That's the tool to capture and collect the patterns. And that's traditionally focused on style doesn't necessarily include code. So it's a pretty fragmented market. Here we're looking at patterns, components, style guides and pattern libraries. Let's talk about pattern libraries for a moment. Does anyone remember this, the Yahoo Pattern Library? Yeah, it's no more. This is a screenshot I got from the Wayback Machine, it's gone and the history, this is quite interesting. It was back in the Ajax days of 2005 after the Ajax summit, and I remember writing my first Ajax applications. I thought, Well, this is going to change the way I did. 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? So about a year later, Yahoo released this pattern library and essentially you go 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 a visual pattern, you were getting code and you could actually use that in your applications. That was great. There's about 13 of them in there, 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. That was one way to do everything. So a year later, a Danish web developer came along and created this site called Design Patterns, which is still alive today. Now what's quite interesting about design patterns is you can go along to it, 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 a pattern is meant to be the way something works, the functions. And then the component is essentially that the actual interface put on top of that. So pattern libraries have evolved. At the same time, our development community have created web frameworks jQuery, on this jQuery UI, we've got bootstrap download the CSS and the HTML from that. You've got angular and you've got react. And again, this is a market that's changing and you're getting these web frameworks tying you into maybe to particular look and feel just fine. But we've got to respond to that. So I'm just going to introduce atomic design for a moment. Hopefully, we're all familiar with atomic design, so I can go pretty quickly through this. Brad Frost actually introduced this back in 2013 and it is essentially using chemistry to understand how we build applications where you've got atoms, matter comprised of atoms which are bonded together into molecules combined into organisms, and then you've got ultimately the universe.

So when we look at that, here's some examples. And atom here could be an input form, a button or a label. Combine them together into the molecules. Combine them even further into getting a basis of a website here. We can take that further into page templates and then the pages, wonderful concept. And most of our modern UI frameworks will be built on atomic design as atomic design principles. But there's a problem. What happens if you start taking these molecules, 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, a little bit of that, and all of a sudden you get a bit of material design thrown in a bootstrap training with Salesforce Lightning, and it's like, Oh, what's going on here? And it just looks incoherent, so you got to 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. So there's some great examples out there. For example, Salesforce Lightning is, I think, one of the great examples.

And when you actually view the documentation that goes in, there's atoms. It actually references atomic design within the documentation itself. And to me, that's incredible that they've actually built this design system of thinking of atomic design at its heart. We can then move on to what Google has done with material design publishing 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 its on iOS? So what I like, 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 it was about eight years ago before I joined the company, we created the user interface management framework. So we've been building this design system, this pattern library, this UI framework for about eight nine years. And in the last two years, I've built a co-located team here in Dublin to evolve this and take it to the next level to 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, a scalable platform behind it as well. Now why are UI framework so a design system has these core building blocks, patterns, components and a style guide? What's different? What's missing from this? Accessibility. Yeah.

Are we documenting the accessibility? Does our design systems actually make affordances for accessibility? Does it make affordances for people who are going to be browsing it using keyboard only for people who are document or browsing your website, using assistive technology? There has to be there. This is your passion. Library is very visual. Or does it actually contain code? Does it support frameworks or bootstrap? Does it support angular this support view and react? And do you get design tools in there? So when we look at all this together, we get this concept of a UI framework, and 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 this. So that's a UI framework. I think it's quite interesting with a UI framework is that it does support multiple web frameworks not tying you into one. It's always been a barrier for us when we actually create a UIMF. Eight years ago, it was chosen to support angular and then angular two came out. Then there's a big rewrite of two angular three and four. Well, up to four. And now we're constantly having to support angular coming out every six months. So we realized we got to decouple that. So we're actually decoupling angular from our framework, and that's quite important.

So why use a UI framework? Why spend all this time? Again faster speed to market, any dev team consuming this does not have to start from scratch. So we have an 11 person team building our framework, supporting today around about a hundred different products within them. And they just come along and they just basically download this from GitHub and they get going immediately. Whether that's so important promotes a lot of code reuse and ramp up time. So that's the investment lower cost there because you've got a foundation to start from to improve 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 been gone through a continuous recycle. It's been validated with QA. We've had users tested. We've actually done accessibility audits on it. So you are getting higher quality. Which brings us into accessibility audits. Yes, we're a WCAG 2.0 compliant today and we're looking for a WCAG 2.1 compliance with AA towards the end of the year. So anyone consuming our framework will get that out of the box. And that's pretty important. UI pattern consistency, a very important design tools. So at the moment, we are a company that's split between Windows and Mac, so we make our tools available for the Adobe Suite. We're moving tools over to sketch and we also prototype in Azure. So we use Azure as our deployment for a lot of our designer type tools.

Design, consistency, responsiveness and testing. 10 core benefits You're looking for benefits to justify investing or using a UI framework. So how do we actually use this today? We've got developers and designers all using our design system on our framework today. For the designer, they can use their Adobe plug ins, they can use our icon libraries and they can use our Azure components. We've got Azure in the cloud for that. Our developers are using our angular components. We're moving that over to be more vanilla towards the end of the year. Easy to install, npm install and voila, you have it. It's just so straightforward and we've got a showcase and this is our showcase that actually demonstrates everything. It's so important to have a showcase where you've got all your code documented, your UI libraries there, your patterns, your anti patterns and then anyone to come in. So this is the very latest version that was released April 10, version six one zero and every five weeks we're spinning out new versions of this that 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 not going to be adopted. So this showcase is very, very, very important. So we've come an awful long way over the years, from just coding freehand to using UI libraries to using web frameworks.

And now ultimately, with these full stack design systems, it's really bringing together the dev and our development teams together so they can speak in uniformity. So 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 keeps everyone aligned. It's nothing new. Everything here is going back hundreds of years. We've been constantly on a search to create uniformity and document this, so we've got examples of patterns going all the way back to the fifteen hundreds. I personally quite like the NASA one. If you can take a look at that PDF. with the web explosion really, it has been interesting how the design systems have supported that web explosion and then with atomic design allowing that standard vocabulary that we can all understand. The UI framework or the full system design system is essentially the modern evolution of that. And within my team, we use the UIMF user interface management framework. So that's 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 team. So with that, I'll open to any questions.

Q
You mentioned your science systems team. Do you think that it's kind of critical that you have ownership within one particular team?

A
It's important to so we do open source, but it's called inner source because the GitHub repo we have is internal to the company, so it's designed to be extended. So if you create a new component and you want to give it back in again, we encourage you to do that. We'll bring that into our backlog. We'll do the accessibility checks and audits and on that and 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 are 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 do ownership of that. One thing we've changed in the last year is we used to have design sort of spread out. We had design councils and we'd have a design council working on a new pattern here or a new pattern there. And as a result of it, we had inconsistencies. I spent a lot of time doing administration. So in the last year, I've actually hired a dedicated design and research team over this. In addition to the development team, again, it's ownership. But we do actually use the process of crits to get as much input into that as possible. We're constantly validating. We've got continuous research now embedded into it. We're currently validating what our users want because if our users aren't using it, we're not going to get the…funding and it's simply going to die. So you have to keep it fresh. But having that central ownership? Yeah, that's pretty critical and it's critical. And that is why we've been so successful over the last eight or so years