(retro electronic music) (audience applauds) - Thanks, thanks for that intro.
I'm just waiting for Tim to get miked up.
Mark, looks like you've got a career maybe in advertising ops in the future.
Might be good for you.
So, yeah, that was a great talk from Mark, and I think maybe an interesting parallel for us. We're going to present Equinix's personal journey, along the same path but maybe less about the tools and more about the way we got there and the history.
- [Tim] Yep.
So, one of these, this one? - [Tim] One of them will work.
- One of them? No, no, what's going on? Is there a cursor somewhere, where's it gone? There it is.
All right and this one? - All right. - Okay, we're away.
- Yeah so this is very much our journey, I suppose. We're a 17 year old company going from being a startup moving really, really fast with just a few developers right through to having several international teams and trying to wrangle all of those towards a single goal. - Yeah, so in the beginning, Equinix was a small startup, essentially.
Melbourne based, five engineers, five or six engineers, all Java engineers, no designers. And by virtue of that, they were just pumping out product as fast as they could, building page after page after page, drawing inspiration from what they could see on the screen in front of them, which was either Linux or Windows, and it was not great.
Equinix grew and grew, and we had one engineer who thought he might do a bit of UX work, but it was kind of hit and miss.
Fast-forward sort of seven years to 2010, and Equinix hit version 10, 2010, we did a big rebrand, decided that we should take this ugly-looking beast that we'd created and try to make it look nice. - So, when you're in an organisation that is predominantly developers, what you do if you don't have those resources is you go external.
So that's what we did, we went to an external party who didn't really get what the app was, focused very much on the aesthetic.
And at the time were, form a waterfall in the way that we approached things.
So there was a whole lot of design up front, and then there was the handball to the developers. - Yeah, and the handball for the developers is obviously a problem 'cause you get this PDF, and you're looking at it and you're like, hmm, this kind of fits a little bit but then after a while, some of it doesn't fit and there's components that you have that don't fit the star guide, and so you end up making up a lot of stuff. So this is the document, this is a current example of the document you would have got. And there's a whole range of the app that doesn't fit this thing correctly, and you have to kind of just figure it out and make it up as you go along. - So as we progressed we thought, maybe we should get this design thing internal, but the artefacts that we were dealing with were still kind of the same sort of thing.
So building up big, heavy documentation and then handballing it across, and the really easy thing is when you're designing in Photoshop is to get it all pixel perfect and all that sort of thing, but then handballing it to a - I'm doing a lot of handballs.
To the developer, you know that translation, I think. - Yeah, so we were getting these, essentially, more PDFs, and whilst we could go to the designers and say, 'look, what you've written doesn't make any sense' 'what do you actually mean there' or 'how does that' 'fit into this context', it was still a PDF, and they were predominantly from print backgrounds and still learning the web as they were going. And so, iteration after iteration, building a new page, which was just a copy of the page before with slight variations, slight variations, things got-- - So the product end-- - Pretty bad. - Our teams grew and grew, we got to a point where we're probably around five designers embedded in each development team and trying to do that whole agile thing, and the design intent - and even when you're developing, you don't want to build shit, you want to build something that's good.
So invariably what would happen is this wonderful loop of having a look at what we had, going, hmm, I think I can design that one better, doing that design, and the intent is always to kind of flush it through. This is the new design, everyone will do it this way, and it'll be great.
- But the developer spends a week building this brand new component which is a slight variation on the previous one, put it into the page, deliver the feature to the customer and go, okay, now we need to go back and fix up the rest of the app, and they go, 'no, no, we've got no time for that,' 'we have to move on to the next thing,' 'the next thing's way more important.' And so you end up with these six designers in six different teams with six different engineering groups, half of which don't have UI developers in them, and it just kind of cascades. We end up with multiple versions of every single thing you can imagine, confirmation, dialogues, etc, etc, and it just got kind of crazy.
So...
2015? - So at this stage we've kinda got four or five designers, introducing new people into the design team was really difficult.
One of the first things that they do when they went to design something was, 'hey, how should I design this model?' 'How should I design', you know, whatever it is. And that was really difficult to communicate. We'd go, 'oh, well, look over in this spot,' 'there's that thing, and then if you go' 'down here then there's that other thing,' and it became really difficult.
So we thought, how about we try and wrangle all of this, we'll capture everything that we've got, and try and document it.
And we kind of had several go's at that.
First we kind of tried in Google Docs, then it was in Confluence, then it was Drupal. And none of them really worked, it was usually one designer going through and trying to screenshot and capture all of this variance across the entire system. But you'd get about that 80% mark and get busy, it grew stale, no one used it, it was useless. - And as a developer, you'd see this activity going on and you'd be like, yeah, yeah, we really need to clean up the site, what should we do, what should we do? Maybe there's some colours we can merge together or something like that.
And that'd always be, almost getting to the end and then didn't quite ever make it there.
From our point of view, we were producing, we had the same problem.
We had this CSS, we were introducing build systems and we had CSS everywhere, and there was all slight variations and so we thought, great, we'll catalogue everything.
And we actually produced our first live component library, but it was essentially just one gigantic page which had every single dome structure that was somewhere in the app rendered in every variation of that. And we say, 'hey, developers, you know that thing' 'you've been trying to do on Drupal or whatever' 'we've actually built it, come over here' 'and have a look, it'll be great.' But it was useful for us to help us refactor and get a handle on the CSS.
- But not very useful for designers.
One of the reasons was that it only actually ran on developers' laptops.
So half the design team didn't even know it existed, but the other thing is, it was very developer-focused. It had every pattern, which meant that there was no way of annotating it, and communicating both to designers and to developers which patterns are current, which things should be retired, and looking forward to where do we want to head with some of this stuff? - So, me and Tim kind of got together and we're like, 'I'm trying to solve the problem,' 'you're trying to solve the problem,' 'maybe we can solve the problem together'.
So star guides were kind of the hot new thing back then in 2015, we're like, obviously, the solution is probably the star guide, we've got all these development teams, now, and by that stage I think we had teams in London and San Fran, so geographically distributed, and we also started doing microservice architecture, which is great for the engineers, but our backend engineers just copied the UI from the core app, put it in a microservice and went, and then started going off in that direction developing their products, and then there were six of them and they're all going off in different directions. And so we really needed to get a handle on it. So we were looking for that thing that would sit in the middle, something that would be great for the designers, but also capture a live representation of what was really true in the app. - So Ben and I kind of thought we know what we wanted to do and were socialising and everyone's like, yeah yeah, great idea, but there really wasn't that buy-in, people didn't feel empowered to actually do that. So the next stage for us was really trying to convince the business that that was what was needed to happen.
So we did a whole lot of research, provided a whole lot of information, and presented to the founders.
And they had a really surprising response.
They said, 'that's great!', 'why aren't you doing it already?'.
So we had the blessing, and I think the most important bit was a champion for the work.
Now, while we didn't get a whole development team or a dev ops role, what we did get was that ability to communicate with different teams throughout the world and to say, 'this is blessed,' 'this is something you can spend time on,' 'this is something that we need to do as an organisation'. - Wouldn't necessarily hit the other teams on the head with it, but at least we had something to do, something to tell them.
So we were aware of the open-source model, we'd both contributed to open-source products in the past, And we thought, how can we foster collaboration with this thing that we're gonna build that's gonna sit in between the engineering team and the design team. And so we built something on the open source model where there would be a core group of engineers who would understand the technology and be able to shepherd the component library, and really take ownership of that component library. And then there would be sort of a secondary layer of contributors who would probably be engineers within teams who would be beholden to their team delivery, so they could say, 'I need this component' or 'I need that component' or 'I need this changed', but maybe create a merger quest back into the core library. And then there'd be that outer layer who aren't developers who would still be able to interact with the patent library through chatting on Slack or raising an issue or something. And then also the designers, most of the designers were in that outer layer, unfortunately.
- (chuckles) A few of us like to tinker with code, Ben won't let me do very much these days.
So the same model kind of holds for designers as well, we have an inner group of three designers who are our custodians of the platform and the style and the direction that we're going. Or librarians is another great word for it. And then that next layer out, it's the designer that's embedded in the team.
And I suppose what that designer within the team is doing is really focused on the business problem or a user problem, so they're sort of heading off in that direction and saying, 'hey, we really need this thing' and then we've got the librarians on the core part of the team that are really rationalising and questioning whether that is a good thing to add into the system or not. - So we built it, and there's a partial screen grab of part of it.
It's a pretty standard kind of component library, there's a list of components and then you can see the components, and it's live in the sense that they're real components rendered out of the source code.
And for the engineers it was great, we got a few of those big copy and paste blobs out of a service and put the component library in and it was versioned, and it was a dependency, and it was all wonderful and good, but it wasn't really all things to all people. - So the bit that was more difficult for designers is that to get something in there, they had to code to mark down, work out how to do some magic with git, which most people weren't interested in doing.
The other thing is, really what we wanted with this is for it to be quite pristine, and just define, what are the designs that do fit in the library? And it didn't allow us to develop and evolve. So for that we kind of looked to different tools, so we use Confluence to research particular patterns.
You saw screenshots of all the variants that we had so, this is where we might capture all of those things, discuss which of those are the best to use for now, or, are there other, modern patterns that would be better to use? And we utilised their templates to effectively have a pitch.
- Yeah, so in this world, the component library captures what's real, and what you should use, and the Confluence is the place where we're kind of doing what could be, what might be, bit of research, bit of the grey stuff.
And I guess there was another problem, a parallel problem the developers faced, where we had this central component library, which was managed through an open source model and versioned, and of course you can submit a pull request, but those core maintainers, they might be busy or they might be doing something else, and at this time as well we had significant time zone differences between some of the development team. So there might be three or four back-and-forths in a merge request that might take two, three, four, five days. Maybe it's over a weekend or you got a public holiday, who knows.
But that team over there in Munich is trying to get something done, and they're waiting for their merge request to go through, and they're waiting and waiting and waiting. So, the way we solved that was by pulling the component library apart and going, there's a core component library, which is the blessed part, and then each team will have their own component library, as well. And those component libraries contain just what's unique and interesting about what that team is building, and then the idea is that they can develop as quickly as they need to in that component library, and then say, 'hey, I've built this thing' 'maybe you want to put in the core library'. And in theory, there would be a process for taking those components out of those subordinate libraries, and moving them upwards.
- So the concern here is that we've empowered teams to move super fast again, and what we don't want is for them to go designing off in different directions.
And that's where, as a design team, the practises and the communication between us has had to increase and change and evolve from the ways that we used to do things.
We started by having a weekly design meeting, and the intent with this was to meet weekly, and get from beginning to end of a particular design problem that we're trying to solve. But what happens when you get 20 designers in the one room? No one makes any decisions, and it didn't go anywhere. So this was where we've had to be quite reflective, we did a retro and changed tact with that.
So now, basically what happens is within a particular stream, when a design pattern comes up that needs some resolution or some decisions about, it's a communications opportunity.
So that's usually pushed into Slack, someone says, 'hey, I'm working on tables' 'our filtering sucks, let's create' 'a really cool pattern around that'.
And pretty much always, someone else is like, 'yep, I need to do that as well'.
So we empower those teams to join together, they do the research together, and then at a fortnight (mumbles) we get together and effectively do a status update.
And that's the check-in with the broader team to make sure that those patterns are consistent and able to be progressed.
- And having the UX team have that process means that as an engineer, I can be confident that when I'm looking at a pull request from someone I barely know in London for some component that I'm really passionate about, I know that there's been a discussion behind the scenes around that component. And all I'm doing then is I'm analysing the code and making sure the code is fit for purpose, not, is this consistent in our design language or anything like that, I know that discussion's already had. And one of the interesting lessons that I think I had was, that when we started, I thought that we were gonna build Bootstrap for Equinix. We were gonna go, there's Bootstrap, it's great, we'll just do that, but instead of looking like Bootstrap, it'll look like Equinix.
And in fact, one of our early experiments, we took Bootstrap and we redesigned it so that it looked like Equinix and it was all the same class names and everything.
But I'm glad we didn't stick with that, we built our own thing from scratch.
This is maybe like a sub-illustration of that. We had hundreds of icons in the system and we rationalised it down to a sensible set of, I don't know, 99 or something, and we named them all what the icon looked like, 'cause that's what Bootstrap did.
And then we looked at it, and we went, hang on, a magnifying glass, we always use a magnifying glass for search.
And the cog, we always use a cog for settings. Another good one there is the red exclamation mark on the far end.
In Equinix, for the last 17 years, a red exclamation mark means confidential.
- [Tim] Rightly or wrongly.
- Maybe it's not the best design decision, but that's what our users expect.
If a designer came along and saw, 'ah, red explanation mark, and I'm gonna use that to mean' 'important' or 'I'm gonna use that to mean alert', that would be totally confusing for our users. So we went through and renamed all our icons to not what they looked like, but their purpose within Equinix, and I think that's the real lesson for me about this whole thing is that, when you're building a patent library and then a design system, as it evolves, you're really designing it for your company specifically, and it's not just...
yeah, really designing it for your company specifically. And we can take that a step further.
Oops, gone too far.
We can build really rich components that bury deep down into Equinix's infrastructure and ecosystem. We're a construction information platform, and document control is a big part of that, and so we can build really rich components around searching for documents, or finding users that really specifically target what our application does.
And then when a team needs a doc search to their feature, they just plonk that component in. And it's really deep, and then expects there to be a backend service there, backing it.
And there is, because you know it's our product. - So when we began we kind of dreamed, there's a whole lot of great examples of really good design systems out there.
Apple, Google's material design, Lightning design system, there's a whole lot of really great things out there, and we kind of assumed that we could get there really fast. But, I think the thing particular about Equinix has been the importance of where the teams are at, and how they behave together.
And so while there are millions of things that we could do, the things that we've been focusing on have been those team dynamics, changing the culture around how we think and how we do design and development. - [Tim] Yeah, and it's grown to a point now where the design system is so large and complicated, it doesn't really fit in anyone's head, any one person's head.
And so the design system that we're trying to build now is not just about capturing every component that there is and putting it in the component library, it's really a system that helps us innovate and develop as fast as we possibly can whilst allowing a cohesive design approach.
And really, that's the takeaway at the end of the day is that, a design system is not just built for, to capture the look of a company, the look and tone of a company, it's really about capturing the processes and the people, and the culture of the company, as well.
Thank you.
- [Tim] Thanks.
(applause) (retro electronic music)
