Style Guides with Josh Clark

Josh Thanks for having me, I'm such a big drooling fan of you two!

Josh Sure. I run a design studio called Big Medium and Brad, you and I have worked on a bunch of projects but my role in doing these projects, whether it's for the web or for mobile apps or connected devices, is simply to look out for the overall product from a user experience point of view and interaction design but also really making sure that the thing is meeting the goals that it's set out to do, so there's some design strategy to it, to make sure that there's real consensus for why we're building what we're building, what it needs to do and to make sure that each stage of the result is supporting those goals and the things that it needs to do both for the company, the patron of the project, as well as for the people who will use it, and I think that stuff that you guys have been talking about and working on with Design Systems is super relevant to that.

The interesting thing about that is, of course, the patron and the customer are often one and the same in that case, you're designing something for the people who are also using it.

Josh Well, I think it's a great question. I think that one of the real considerations here is, who is this Pattern Library or Design System for? In a sense I've got a Pattern Library and a Design System for my own site but I hold it in my head because I'm the one who uses it, who created it and consumed it; there's no other audience for it except for me and so I'm content to hold it in my head in a sort of a system of files and references that is, the organisation of which is only understandable to me, right?

Josh And I think that, as you start to scale that up to more and more people that effectively, most design projects and development projects wind up with a Pattern Library of some kind: here's the parts of the stuff that we used to make the thing. I think that a lot of times you need to refine those Pattern Libraries to meet the needs of a broader and broader audience, the more people that you want it to touch and I think a lot of times, a lot of Pattern Libraries stop at the small team level and say hey, we made some stuff, maybe you guys will find it useful but implicit in using it is the adoption of a whole lot of new standards or tools or even design patterns and it just doesn't make it easy enough to adopt or it uses a technology that we would have to bend over backwards to use and to incorporate into your own project.

And so I think that a lot of it is really being clear about what you want this Pattern Library or Design System to do for the larger organisation, assuming you are designing it for a big organisation, and making sure that it fits the specific workflow of people who are already there.

I think there's often a hope that I've seen when you're creating, trying to launch something like this into an organisation, a Design System or a Pattern Library that you're going to really effect change with it and I think that in some small ways you can make change in an organisation with these but I think even more it's really about trying to corral consensus about the best way that an organisation does things and in a way it means that you're really not so much trying to be a leader but a documenter and to sort of say, here's the way that we solve problems at this organisation; in a sense, that's often the most boring stuff, it's here's the stuff that we find ourselves designing over and over again: here's the best way we've found, just do it this way so you can work on better problems but if you're going to do that and approach it with that kind of level of humility and service where you're really just trying to capture the best work of others in a sense, you really have to make it also be as digestible as possible so that different production teams in an organisation can quickly adopt it and make sense of it.

Josh I think it's a great point, Anna. I think especially the larger the Design System and the larger the audience for it, the more that you really have to be disciplined about thinking of it as a product and bringing to bear all of the good design and development practices and UX research practices that you would bring to any large system.

And in fact, a marketing effort to that too, which I think goes really to that language stuff that you're talking about is, how do you share and communicate the utility of this in language that people will be excited about, but also just in terms of the benefits that it will offer people, that this is, I think particularly for very distributed groups like government groups which are huge, vast, where you have very little leverage, it's like there's not a case where you must use this: you have to really make it so that people want to use it. How do you make the best thing to do, the best practice also be the easiest or even the most fun thing to use, the most productive thing, the one that you're like, why wouldn't I use this?

And so again, it sort of comes down to this sense of humility and service for this where you're not being, this is the coolest thing to use which will have some appeal to people; or this is the newest thing, but really it's this is the thing that will simply let you do your job faster, easier and maybe with hopefully a sprinkling of fun too.

Josh Yeah, I think one of the core things for any project and the bigger the project the more important it is, is to really try to get consensus about wait; why are we building this? And what you'll find is, particularly if you have a lot of people involved in it and when you're talking about a big Design System, like the Fortune 10 project that you're talking about, Brad, when you're talking about a big organisation and a full Design System, you're talking about many different disciplines having to be on the same page; you've got a Marketing Department, you've got Developers, you've got Designers, you've got the product owners of all the different products, all of these concerns and disciplines and while they might agree on the list of say, ten or fifteen goals that they would like to see this Design System achieve, what you'll find when you dig into it is, they may not agree on what's most important among those goals

So I think one of the things that is really important for us is just to get a real sense of, what do you want to accomplish with this product, really, like any product and then really get everyone into a room to sit down and agree, you know what? This is a rough priority of the things that are most important so it will always be able to focus on this.

Usually around Design Systems, the big levers here are around budget and time and UX quality and consistency, so it's development efficiency, in other words, it's how much the stuff will cost and it's having a good quality assurance in a sense, a good quality level to the products that will come out and a lot of different goals within.

I think one thing though that you'll find is that there's some little sneaky goals that will get in there, that are often specific to a specific person or group's agenda, that it will be my secret agenda is that I want to get everyone to use… you mentioned Bootstrap, let's make this thing a Bootstrap thing and impose a technology or a way of thinking and as I mentioned earlier, my experience has been that these systems are not great at imposing new technologies on large groups, partly it's because there may be legacy technologies already there, so actually adopting this example of Bootstrap-driven system would actually prevent adoption of the system because it's like, wow, we'd have to re-build the whole thing from scratch.

Josh Yeah, and I think that frameworks are often awesome for an individual project where you've chosen the framework specifically for a job to be done but of course the problem with frameworks is exactly their advantage which is that it forces you to do things a certain way and while that can be good and can streamline projects, it also can be very constraining or may not wear well over time; the whole thing about all of these frameworks or technologies is that they have a shelf-life and now jQuery had a great run but you can kind of see people starting to move into a new level of elegance and structure of the way that these things… maybe a better way to say it is like a more holistic kind of fuller, robust system than the one-off pieces that jQuery suggested.

Josh It seems not, it seems not!

Josh And you know, I think that in a sense it's somewhat inevitable I think, for that to happen downstream, to have different versions of a Design System. So, if you think of a Design System like Material, there's all kinds of implementations of Material; Material was not designed for anything originally other than for Android and yet it exists in a whole lot of different ways and forms that have extended beyond it.

So, I think that there's always a case where there's going to be a sense, a developer Pattern Library: here's the project code that we're going to use to actually make this happen and then upstream from that, there's a little bit of kind of a more implementation-neutral Pattern Library and Design System which frankly, I think that HTML, CSS and very light JavaScript are the best way to demonstrate that. When you look at the longevity of HTML; sure, it's developed, we're on, I understand, the fifth version of HTML…

Josh But it's been constructed now to be very backward compatible and it's just so robust, it lasts. What other kind of technology mark-up or language has had the kind of success that HTML has had and I think it's never say never, but it feels like it's got at least another twenty five years in it. So the idea that, if we're going to make lasting design and interaction recommendations, my sense is, let's make those in the rendered HTML and that that becomes the thing that evolves rather than having to be chucked out every time there's a new framework or underlying technology that comes around. But you're still going to need to implement that rendered HTML, so, however you decide to do it and hopefully those developer libraries get shared, just as… I'm sort of saying developer; it's really an implementer library that I'm talking about…

Josh Yeah. I think when we designed the Unity Design System for ExxonMobil I think that one of the things that at first seemed really daunting but I think in the end turned out to be a favour to us and to the system was the fact that it was going out to [Editor's note: updated number of developers] five hundred developers who didn't have a single technology; it was really up to each developer on each project to choose their own technology, which is a messy technology stack, but what it meant was, we couldn't actually go in and say here, use this one and then in the end we were just sort of saying, here's what you should strive for to make as the rendered HTML; this is the standard both in terms of interaction and solutions but also, this is the way it should look and feel and it's not as convenient in a sense, for developers just to be like, great, here's my… Angular mark-up, but it also sort of says, here's a fully rendered example, no matter what technology you use: you decide this is what to develop it to.

Josh You know, it's such a great question. I think there has been an evolution. I would still say that there's a case where people don't necessarily realise that they need one but we'll give one to them anyway and here what I'm really thinking about is in the process of doing, say, a big website re-design, the deliverable ought to be the pages, sure: here's the website, that's ultimately what they're interested in, but if you're building it with good, current pattern-driven best practices, you should give them the Pattern Library and the implicit guidelines that go with it, so in other words I would say that as what I am hearing a lot from clients, whether they're asking for Design System or not is, please help us get out of this horrible spiral of building a website, sitting on it unchanging for three or four years and then until we just can't stand it any more and we blow it up and we build a whole new one and the cycle repeats.

Josh Yeah, not so much in a formal way. I think that for this type of client that I'm talking about that has a website and where the website isn't necessarily their core business; this could just be, we've got a couple of developers on staff who help us do the maintenance but say it's a marketing site or it's an e-commerce site but the company isn't really a commerce company, like, we just make the products, so particularly for these companies where the website is certainly the main view of your company but it's not their core competence, for those folks often they don't have a proper Design Library; they have whatever they inherited from the previous vendor and I think one of the things that I try to do with client engagements is not just to deliver the work but to help to up the organisations game.

I think that all three of us are educators and we like to share and help people be better at what they do and I think that that's something that really animates the work and the projects that I do, is to be how can we make your team even better at what they're doing and so part of the thing is, I wouldn't say it's a hard sell of having to say, here's a pattern library or a design system but just kind of saying, here's how you use one and here's how you can do it to make your own work better to make changes faster, to know how to build new pages or even full applications without having to hire outside designers to help you to do it because we're going to try to build and anticipate those needs that you can do that yourself. So, a real sort of teach a man to fish situation, but also, here's your tackle kit.

Josh Yeah, that's right, that's right. Again, I think when it's something that it's accepted really easily when you're saying, we're just going to collect this set of solutions that you've already got in hand or that we're developing with you and just want to make it really easy to access those so that you can assemble them yourself in new ways.

Josh Yeah, wow, well… I think every component has its own story in a sense, of what it's role is and in particular, how it can be adapted or adopted to do new tasks. I think that there are some types of components like a header navigations that, wow, has to do a lot of heavy lifting and be responsive in all these ways and the menu has to change up and do this and shift around in all these different screen sizes, really complex machinery and when you're trying to build a generic re-usable component that could do things for different applications, being really clear about saying what's OK and what's not and telling the story of what this thing can be used for and particularly what it shouldn't be used for. When to consider another component and here are the family of components that you might consider as an alternative.

Josh Yeah, that's right. What is the super-power of this thing and what's the super-villain it's good at fighting? I don't know, something-something. Superhero something-something. The superheroes are popular now, right? I heard a rumour!

But I think Anna's question early on about language or observation that language is really important is really a part of it and I think that it is again, so much of this sort of presentation of Design Systems really has to be done with real humility and to not let yourself as the creator or manager of the Design System put too much of your own ego into it and that means not writing too much, not over-documenting either.

What's the right amount of documentation for the audience? I think that it's fair to say that a lot of developers who are there to grab up some code and figure out how something works don't want to read a novella about that component; so, what are some of the shortcuts?

I think that often when we're working on these, we have a design principle of just enough documentation and it's just like, how can we express how this thing works, what some of the rules and guidelines are, what some of its cool, non-obvious flexibilities are in terms of just by adding these couple of class names, you can get these effects. How can you do that not just with words but also through quick images and do this, don't do that kinds of shorthand, so there's a real… what's the Mark Twain line… I didn't have time to write you a short note so I'm writing you a long one. Taking that time to be really discerning about what you share and how you do it and what you do with images and what you do with text, just so that you can make it, again, feel like you're helping people rather than giving them a new chore to learn something.

Josh Yeah, it's a great question. I think one thing that I'll mention is that you're right that I do have a focus on designing for what's next and how do we prepare organisations and products for what appear to be emerging technologies that are likely to be really important in the next year or two and I do think that a really important thing about Design Systems and Pattern Libraries is being kind to your future self; it's creating this documentation, this sort of stuff that, so for the next project, my colleague or me, I'll have all of this stuff at hand and so I think part of that is also trying to be future-friendly which, Brad, that's a term that you came up with several years ago that I think is great, which is to think about not just what's the next project but how might this be used and I think that it takes less and less imagination now to see that things like speech and in particular, but also some artificial intelligence aspects are going to be coming into these things, that our interactions are going to go well beyond keyboard and mouse, as we've already seen with touch-screens although we still for some reason, still very focused on the keyboard and mouse experience as designers, which I don't think is a great thing, but I think that a lot of this is, I'm pleased to see more and more focus on accessibility for designers as a default, learning that, oh, if I create an accessible website, it still can be visually creative, it doesn't have to be boring, which I think is an association of this stuff, or it doesn't have to be limiting and I think that one of the cool things about embracing accessibility is that it tends to also embrace future and emerging technologies. In a way, these speech interfaces: hello! If we'd designed for the visually impaired for the last several years, you'd already have your speech interface. It's like good mark-up, good accessible mark-up designs for the future and so I think that in a sense, just having good standards sets you up for these emerging web technologies because again, they all just come from HTML, this incredibly durable, amazing mark-up

Josh But I think also that it's also the case that we're going to have to start developing some new UX practices for how to anticipate speech, that it's a very low-resolution interface; how do we create some new speech patterns that prompt and offer suggestions for what it is that you can do in ways that you would just read a menu quickly off of a screen. What are the emerging patterns that sort of suggestion and anticipation that we need to have there. Those are essentially new patterns that we haven't had to deal with on the keyboard and mouse web but that we will have to develop for others but I think that those will sit alongside other solutions.

I guess I'll say, what we're seeing right now, I think that some people who are very big enthusiasts of bots and chatbots will suggest, oh, this is the end of the web as we know it or the end of apps as we know it and I think really what we're seeing instead of one thing replacing another is just an explosion of new interfaces and what that means is that we'll have an explosion of design best practices for each of these new channels and what that means is that we have to get a lot better at documenting all of them and that's what Pattern Libraries and Design Systems are great at is, how do we share what your colleague has discovered to be the best thing, the best way to solve a problem, that you can just grab that up and solve your own new problem.

Josh It's interesting; I think that people began associating the pattern library as the system and realised, oh wait, we can add more if we pull in that the brand people have done with the brand guide and bring in all of their things around colour and the notion of the brand. Oh, and over here we've got all the copywriters who've put together their voice and tone guidelines and you get the visual pieces of the Design System and so it's adding what you see, the typical Style Guide layout with that left column of aspects of the Design System that you can click on to learn more about, that left column is growing and it's going to continue to grow because design is becoming more complex and the disciplines that go into design is becoming more complex and as we add more and more interaction channels, more kinds of interactions, I think that it's all going to have to be folded into and adopted into this overall Design System and it doesn't mean that everybody has to become an expert in each one of those left-column menu options but it does mean that the whole story is becoming a bit longer and more convoluted and it helps if all the disciplines share their knowledge with the rest of us.

Josh That is my goal, that is my goal. I mean, I think that broadly, what is emerging with all of this Design System work is just how many disciplines and kinds of brains and kinds of creativity go into creating large and complex design solutions and the way that I think of Design System work writ large is that it is a container of institutional knowledge; it is a collection of solved problems and an example of the best of what a company does when it comes to design and the more that you can use that to build a real platform for that kind of communication, and I know I keep saying this word, humility, but I just think it's so important for the people who are designing these systems not to impose too much of themselves into it but to really work their hardest to make it a reflection of the design values and brand values and development workflows of the organisation because that is the way that you're going to get people to be really enthusiastic about it and to adopt it.

Josh It's been a real treat to be here; did I mention I'm just completely such big fans of you two.

Josh Well, that sounds pretty good. I'd like to meet that guy!

Josh Well, thanks so much, I'm glad you're reading and thanks so much for all that you two do! I'm glad to know that Brad can read!