Couple of quick show of hands so we can gauge the make-up of the audience:How many of you work in complex organisations where web governance & management is a challenge?Do any of you have a style guide or pattern library that informs how you design & develop websites?Just to set some expectations at the start – we are still INTRODUCING our design language, we haven’t yet INTRODUCED it (past tense), so my talk is really about:The challenges of the environment that I work in, & that I think many of you may be able to relate toThe thought process that went into our design language – our proposed solution for some of those challenges.…& will finish with a little on what we’ve done so far, & the challenges aheadStruck me that almost nobody that I’ve spoken to since arriving in Aarhus has heard of UCL, so I think a few nuggets of trivia might be good.
UCL stands for University College London. Founded in 1826 – first university in London, & also first university in GB open to students of any sex, race & religion. And we’re still very proud of that heritage.These days, we have about 30,000 students, but these numbers are growing all the time, mostly because govt has recently lifted cap on student numbers we can recruitWe’re very keen on the QS world university rankings, which puts UCL 4th. Conveniently forgetting that there are plenty of other rankings & we don’t always fare as well…UCL’s foundation was inspired by this guy – utilitarian philosopher Jeremy Bentham - "the greatest happiness of the greatest number”. He’s still seen as spiritual father of UCL – embalmed & kept in a box, rolled out for committee meetings. story about head being stolen by KCL students.And we have a large number of very famous alumni….
…none more so, of course, than ColdplayI can only apologise.
Before UCL I worked at City University, also in London : smallish number of schools & departments, & highly centralised IS & marketing functions with tight control over content, branding, technology, web development. About a year ago I started at UCL, & immediately saw that is very different place: For a start, I was surprised to find out that the central web team, within which I sit, has no mandate to enforce anything on anyone. UCL operates its own internal market, & we have to bid for UCL work against 3rd-party digital agencies.The other obvious difference was sheer size.10 faculties,>40 depts, >110 principle units, e.g. institutes, research centres, laboratories, 820_ websites Which translates into about 1m unique URLs – we’re not too sure exactly how many because we don’t have analytics on all our sites
Looking around UCL’s website, very quickly notice how huge & fragmented the site is. Want to give you quick flavour of this.Here’s UCL Engineering – a big site with a strong brand identity, built on a bunch of different CMS’s & Sharepoint
This one’s The Bartlett, a faculty covering disciplines relating to things like architecture, planning, energy, sustainable resources. Also, very keen to have a highly stylised website.
Here’s the website for our Australian campus based in Adelaide.
And this is the homepage of the Slade school of fine art – again sees itself as world leading in its field.Aesthetically, these sites all look fine, & aren’t necessarily bad on a case-by-case basis. But they ARE very different, & they don’t know anything about each other – in terms of navigation, they exist as if they have no association with any other part of UCL - they have no common navigation elements at all – navigation is only local to each site in turn.And as we start to drill down into lower-level org units, the quality of our sites starts to degrade quite quickly…
A couple of examples of this:This one’s about Positron Physics – notice the unusual typography, the tabs for navigation, the random use of colours for links…maybe just because pretty!
This one is for the Institute of Ophthalmology, who – ironically for an institute concerned with vision – have a completely inaccessible site build with flash.Saved the best til last…
This one is so brilliant that I had to create an animated gif to show it in its full glory.As can see, these all look very different because all these UCL faculties, depts. & research institutes want to reflect their own org independence by breaking out of constraints of corporate templates.
And this diversity has a negative affect on UCL’s presence as a whole. Recently commissioned a strategy report to underpin our argument that we need to transform ourselves digitally, & they independently came to exactly the same conclusion – that our online presence is damaging our reputation. But why is this DESIGN DIVERSITY problematic?
Big Problem #1: Poor UX & navigation. Aside from fact that a good number of our sites look plain bad, there’s no overarching IA or common nav elements, nothing binding all these sites together.Harry Brignall, in his excellent talk about dark patterns, mentioned Jakob Nielsen’s 10 usability heuristics, and those usability principles are being broken over & over again.
Big Problem #2: We design & develop highly stylised, bespoke websites without thinking of re-use. In desire to make our websites look different, one of two things happen:Either departments commission a 3rd-party digital agency & build their own bespoke thing, usually on another CMS, Or we use our central CMS & override our corporate templates with brute force by adding lots of local CSS & JS hacks
One example, but representative of many thousands: http://www.ucl.ac.uk/teaching-learning/default: Quite an important page, & looks fairly innocuous. But under the hood it’s a mess…40 stylesheets, & because of the bloat I was just talking we get rules overwriting other rules, & loads of redundancy:about 2,562 unused selectors…translates to 2,562 lines of code that we could get rid of without changing the way that this page renders& this stuff really hurts performance.And this is a serious problem….
The reason that it’s a big problem is that we’re in the middle of a ‘Perfect Storm’ of trendsLots of evidence that we’re serving ever more bloated websites…At the same time users are expecting these very same websites to be served ever more faster…AND they want those really fast response times across a huge array of mobile devices & network conditions.So just wanted to take you on a very brief detour to touch on web performance…
The basic advice regarding response times has been about the same for thirty years:0.1 second is the limit for having the user feel that the system is reacting INSTANTANEOUSLY1.0 second is the limit for the user's CONCENTRATION IS UNINTERRUPTEDBy 10 the user's attention has been lost, but these days we’re looking at 3 seconds as the max recommended load time for a site.This has genuine impact on bottom line…
Amazon recently commissioned serious piece of research using big data analytics of their users’ behaviour – crunched numbers from a massive number of user sessionsFound that for every 100ms they could shave off their page load times, their revenue grew by 1%
Translates to a lot of money. Not saying that this kind of equation meaningful for a university website, but you get the idea – performance has become a serious concern for us,
And all this code bloat gives us technical debt, which really hampers our productivity. It becomes really difficult & time-consuming to unpick & debug problems.Might be thinking that this isn’t a realistic model for a university web team, but remember, we operate as an internal agency & fund ourselves by charging for project work – so this is a really accurate presentation of our situation.
Knew we had to fix this. But we’ve got serious tension here, becauseOn the one hand, a key strand of our web strategy – our vision, even, as you can see from our vision statement – is about bringing consistency to our web estateOn the other hand, we have to service the desire of all UCL’s constituent parts to reflect their INDEPENDENCE & UNIQUENESS online.So how do we reconcile consistency with flexibility demanded by all these world-leading institutions?
Pondering on this when I stumbled on a slidedeck from Andy Rader, Principle Designer @ Boston University.It’s a talk about the use of design at BU & it goes well beyond online into the realms of brand, photography & print, but I really recommend it.Really struck a chord – idea of ‘cohensive diversity’, of being able to offer design & UX flexibility while at the same time retaining a FAMILY RESEMBLANCE between sites, a DNA OF DESIGN.
Got me thinking more about style guides, & in particular about how we might use a style guide as a way to:- Bring some consistency to our out-of-control design & development processes, &- Tackle our IA, UX & web performance challenges.
But as I started to research style guides & pattern libraries, quickly found out that it’s a fairly confusing picture.Traditional style guides with very rigid rules about branding & use of visual assetsOff-the-shelf toolslike for creating pattern libraries & style guides Things like boilerplates & component libraries like the excellent Pattern Lab Developer-focused UI frameworks & toolkits like Foundation & Bootstrap that could be used as out-of-the-box style guidesIn early stages of project we experimented with a couple of these ‘off-the-shelf’ options. But none of these were quite right , & these experiences really underlined need for us to ask the difficult questions upfront:Exactly what is this thing that we want to create?…and what purposes do we want it to serve? Fundamentally, what are our requirements?
Definitely approached the idea of spending time/money on style guide with degree of trepidation.Saw this tweet about a year ago when was starting to investigate style guides in some depth, & got really worried that they’re actually a complete waste of time. This point of view has some merit, but the problem is with the implementation, not the concept:One one hand, we have traditional “graphic standards manuals” that are written as though they are carved in stone and ruled with an iron first.And on other hand, I’ve seen style guides that seem like complete afterthoughts and aren’t enforced in any way at all.So our first requirement: we need to find the middle ground. It must be flexible & easy to maintain - we need a living, evolving pattern library, not static archive - collaborative tool for developers & designers to work on together.
Our second requirement was that buy-in is absolutely critical. We have no stick, so we need to create a PRETTY BIG CARROT!Ultimately, we need to make something SO GOOD that there won’t be any good reasons for NOT using it.We want all those hundreds of departments & units to be queuing up to use our design language.It needs to work especially hard to:prove its scalability & flexibility to challenge the preconception that our design language will prevent different UCL brands/units from differentiating themselves. So whatever we deliver needs to act as a communications tool & create a shared understanding of our guidelines; - it must be well documented & of interest/value to stakeholders, managers, marketing functions & of course designers & developers - both internal dev teams & external developers/agencies.
(This is the obligatory Lego themed slide)Our third requirement was that we want a standardized, consistent, universal experience.To do this our design language needs to be able to support a shift in mindset, getting our designers & developers think about DESIGNING SYSTEMS NOT WEB PAGES.We should be able to construct pages using the component parts defined in the system. But what does this mean in practice?
So that means we need to define the system in its entirety:From the macro IRREDUCIBLE principles of usability & interface designFoundations – scaffolding for all UCL websites, like grids for responsive design, typography, colourDown to the micro - any person working on a UCL website should have access to info about how to use all the HTML elements & design components at a granular level, along with code snippets for quick implementation.A ‘UCL theme’ built on these foundations & patterns, but with flexibility to enable other themes to be created using the same assets.And of course this approach should afford us the opportunity to:tackle all that code bloatstrip away the cruft and deliver a high-performance website
Our final requirement may sound obvious, but it’s really important to emphasise:Design language HAS to be completely clear and simple to both understand & use. If its intended users don’t understand what it is, or how to use it, we will have failed.These are tweets from a guy called Mark Boulton who’s working with us to develop our design language – he’s very well respected in web design & front-end development circles, & has a lot of great contacts. He spoke to a number of web professionals who already have style guides, and they had the same advice – keep it simple to understand.The other thing that they all agreed on came as a bit of a surprise – they said “give your style guide a name”.When something’s called a style guide, people tend to think of it as restrictive & dull, but when we call it something else these constraints are removed, & it creates a common reference point that really helps with adoption….
So we’ve given our style guide a name!So let’s have a quick look around - & please remember, this is still very beta & incomplete…A few things to point out:We’ve tried to explain what this thing is, & the benefits of using it, as simply as we can. This info should be the first thing users see.We’ve thought about the most likely audiences, & have provided the most relevant links for each.We’ve exposed the different layers of our system – from the macro stuff like principles & foundations, down to the micro patterns for front-end developers.We’re also making it as easy as possible for designers & developers to download the whole lot as a single zipped resource, or pick’n’choose just the bits that they want. Maybe they only want the grid system, or just the CSS typography rules, or just the common navigation elements.
We’ve got our principles, which we’ve tried to make useful for all audiences & keep as simple as possible without patronising anyone…which is proving tricky!See that we’re surfacing some of those usability heuritsics at this level.We want these to be seen as the necessary ingredients for a successful website. If you start a project with these principles in mind you should end up with a good result.
Here’s another example of one of our foundation information pages – this one’s about our grid system, explaining how the grid behaves across different screen sizes.
We’re also working really hard to explain & showcase how it’s possible to build on the foundation & provide the design flexibility that we know will be demanded while still retaining that UCL family resemblance. And crucially we’re specifying both the constraints, & the circumstances under which deviation from these constraints should be allowed. (Not that we’ve tackled that bit yet!)
So the proof is in the pudding, as they say, & we recently re-developed our new homepage using the design language foundations & patterns.You’ll notice the global masthead, which is one of the must-have constraints for all new UCL websites.And it’s really, really quick –…
Just to revisit performance.Really seeing the benefit of having a lean code-base.
ChallengesAre we going to get the balance between creativity & flexibility on the one hand vs. control & constraints on the other? Is our design language going to allow the UCL’s org units to brand themselves effectively without losing the sense of family resemblance that we’re seeking? How much resource is this going to need once it’s a production service? We need to both actively support its users, & prove its worth by contributing to it & curating it over time.Could we perhaps open source our design language? Stick it on github & let 3rd-party developers contribute to it & fix bugs as & when they get involved with UCL projects?What’s the process for changing or extending the design language? What’s the workflow for acceptance?What are the criteria by which we would allow a deviation from the design language?All really difficult questions, & I’d be very interested to hear your thoughts on all this.
Get in touch with me on TwitterAlso created a storify page with lots of links to tools, articles about style guides, & quite a few style guides & pattern libraries in the wild.One final thing – if you work for digital agency & would be able to road-test Indigo for us I’d love to speak to you. No money, just eternal love.
Introducing a Design Language at UCL
Dan Jackson, Senior Web Architect, UCL
“4th best university in the world”*
“As the users’ experience of the UCL web estate
reinforces and shapes their perceptions of UCL
as an institution, the total UCL web estate will
consistently reflect the excellence and
distinctiveness of UCL by being
professionally developed and managed.”
UCL Web & Mobile Services‟ vision statement
“A style guide tells the story of a design system,
explains the design thinking and enables other
people on your team, or a future team, to take action.”