RWD Podcast Episode #30 : Ulrik Hogrebe (part 1)

Justin Avery: Hi everyone. Just a quick note at the top of the show. This week, I had a few problems with connectivity to the interwebs. As a result, some of the audio is a little bit patchy in places.

This week, we speak with one of the creative directors for the BBC News and the 28 different country sites, so I urge you. Ulrik has a lot of awesome stuff to share. Although the audio does get a little patchy here and there, it does come good. What he has to say is amazing. Please bear with me, and
I’ll make an effort to make sure this doesn’t happen again. Big thanks to Ulrik for putting up with my bad internet. Here it is.

Hey everyone. Welcome to another edition of Responsive Design weekly podcast. This is episode number 30. This week, we have a very special guest from the BBC, but before I get over and talk a little bit about him, I just wanted to say thank you to Media Temple. They are our sponsor for this week.

Media Temple are a web hosting company. I’ve got a couple of my sites hosted on there. I go and use their DV hosting as well, which I think I might change soon because DV hosting requires quite a bit of CIS admin knowledge and I really don’t have much. I tend to break things more often than not, but
they’re actually really cool. If you do break them, they have ways of fixing it.

The other day, I accidentally deleted one of my friends’ website domains and WordPress instance that they had had up and done lots of work for their business. Media Temple restored that for me at a very, very reasonable cost and got everything running again. I didn’t actually have to worry too much
about it. Very reasonably priced. They’ve got a whole bunch of different products. I’d highly recommend. Go check them out, MediaTemple.net [00:02:00]. It’s what I use and will continue to use for a very long time.

Let’s move across, away from our sponsor this week and get onto our guest. Our guest this week is Urlik Hogrebe. He is one of 2 creative directors for BBC.co.uk/news. He’s responsible for the UK site and some 28 language sites as well. Welcome Ulrik.

Ulrik Hogrebe: Thank you. It’s good to be here.

Justin Avery: It’s really good to have you as well. You’re dialing in from London as well?

Ulrik Hogrebe: I’m dialing in from Hackney of all places, so very much London.

Justin Avery: Of all the places. I’m just on the other side of the river over on Waterloo, so I’m just as bitterly cold as you are perhaps. It’s not too bad.

Ulrik Hogrebe: Believe me, our house is leaky at best, so I know what you mean.

Justin Avery: That’s good. Just for the people that haven’t heard of you before and don’t follow you on Twitter or anything like that, can you just give us a bit of background about how you got into your role?

Ulrik Hogrebe: Yeah sure. I’m originally from Copenhagen. I guess I have a checkered past in the sense that I got out of high school and then just goofed around for a while and then got into all sorts of weird universities. I did some business and this, that and the other.

In the meantime, I landed this internship at a Danish strategic design company called e-Types and started working there mainly on the branding side and then slowly got more and more interested in the hands-on doing side of things. Had the opportunity to go to Copenhagen Institute Of Interaction Design.
At that point, I’d been quite into design, but not really a [00:04:00] practitioner. Went to CIID, as it’s called.

Then as I came out of there, I was lucky enough to meet one of the former heads of design for the BBC, a guy called Michael Albers. He asked me to join. Then I was at the BBC as a senior designer for about 3 years or so. Then a little bit shy of a year ago, I started as creative director for what we
call core responsive, which is essentially the responsive site and World Service, which is the 28 aforementioned language sites.

Justin Avery: That’s cool. When you were doing your internship in the branding company and working at the … Is it the Interaction Design? Copenhagen Interaction Design, did you say?

Ulrik Hogrebe: The Copenhagen Institute Of Interaction Design. It’s not the most forthright name.

Justin Avery: CIID or something? Were you working digitally or physical products, print products? What was it like?

Ulrik Hogrebe: e-Types did a lot of brand identity work, so a lot of graphic design. We were doing a lot of letterheads, corporate identities, all that kind of stuff. They had probably what I think are some of the best typographers in the world working with them. We were heavily immersed
in this very print heavy brand identity world, but then, of course, as things were becoming digital, we were starting to do websites.

Then slowly, I helped start up what became e-Types Digital at that point, the digital division, where I was just basically interning and helping out, sorting stuff out. It’s definitely a company [00:06:00] that was very steeped in print [tradition 00:06:02], then quite quickly has become actually astoundingly
good at web as well.

Justin Avery: That’s awesome. When you started [crosstalk 00:06:12]. When you started as senior designer at the BBC, what were the kind of things that you were responsible for?

Ulrik Hogrebe: Basically, we got hired onto this team that was called the service design team, which was a bit of a misnomer really. What we were doing was we were looking a little bit more ahead of the day-to-day at the BBC. The because of various reorganizations that team then got
absorbed back into what we call UXB at the BBC, the bigger UX division.

I started working quite heavily on personalization, looking at personalization patterns not just for one part of the BBC, but essentially for all the different what we call products, sport, news weather, iPlayer, radio, music, kids, etc, trying to figure out how do you develop one pattern that can
sit across all these different products.

We were working to this called GEL. This is the Global Experience Language, which is our visual guidelines, our interaction guidelines. The philosophy is that we try to design things once and then try to make them work for the different products as best we can. Obviously that doesn’t work all the time,
so we have to come up with new stuff. That drives the wheels of innovation around patterns and stuff. It’s quite a good system really.

Justin Avery: Pattern libraries and style guides and stuff are starting to really become something onto their own these days. I’m seeing more and more that Brad Frost and [00:08:00] Anna Debenham are doing a podcast just about style guides now and patterns.

Ulrik Hogrebe: Absolutely. I think how do you do not just style guides, but responsive style guides that work across devices and break points and screen sizes and all that kind of stuff is incredibly interesting. I think the general feeling, at least from my team of designers, is that
we can design as much as we want and illustrate. We have this template system where we say, “Well, we design to 4 different break points.” We open up our art boards and we’ve got 4 different art boards in different sizes. Then we try to make things work within those 4 art boards.

Then, of course, as soon as bring this into a browser, everything breaks because they’re not static as such. My team … The teams across the BBC are trying to do more and more stuff directly in browser. Also we’re trying to get our styles guides and all that kind of stuff and our documentation as
well, trying to figure out how do we put them basically in the browser so you can see them work at different sizes and stuff.

That’s a challenge. Not all of our designers are super fluent in code, so it’s a gradual thing that we’re doing that moves ahead. I work with the developers to do it. We’re just trying to work it out and make everything easier for all of us. The developers don’t have to sit and look at art boards and
flats and go, “Oh, I wonder what that looks like in this and this size. We don’t have to do reams of documentation for every possible permutation.”

That’s how we’re approaching it, but it’s a tricky thing. I don’t think we’ve cracked it quite yet [00:10:00] to get the workflow going. We can do it, but getting the workflow doing, doing it in the day-to-day, slightly more tricky, I think.

Justin Avery: Yeah, sounds like you’re on the right track though with these things. It sounds really cool. I used to have this discussion with a designer at our previous role. I would always try and get him to get into the code more. He was always of the opinion, “The
more in know about the limitations, then the less I’ll push you to [inaudible 00:10:29].”

I thought that was just a cop out that he didn’t want to learn anything anyway, but it seems great that your designers are learning to code. Is that something that you see designers should be looking to do or would you … Have you seen things like [Mccore 00:10:46] and Webflow and [Frunes 00:10:49]
and things like that are more like the Wizzy Wig that designers can explore upon?

Ulrik Hogrebe: Yeah, absolutely. I’ll try to answer. I think every designer that does digital should have a basic understanding of HTML and CSS and JS just from a basic understanding and a communication point of view with the people that will actually be doing the work in browser. I
think that always helps. I don’t think understanding what the CSS can do, especially when you’re moving toward a world of transitions and motions and that kind of thing.

I think that is by no way, no means, a limitation. On the contrary, I think, for most of us, as we find out what CSS can actually do, it becomes a source of inspiration. I urge every designer to at least get into the code and just understand what it is, even if it’s just opening up your inspector and
fiddling with a couple of values and it will preview in your browser.

I think even that base level [00:12:00] understanding of how it works is enormously valuable. Then, for my team, I encouraged them to play around with the different tools. One of my guys, he loves working in this thing called Hype, which is this half illustrator/ half coding hybrid thing. He does amazing
work in it. He does amazing work in it. It really works. I think he’s become quite specialized in it, but whatever rocks your boat. I have got another designer who has a software development background, so he just does everything in code. Amazing.

I’m learning code slowly, so I don’t do everything in code, but it’s that kind of dynamic. Then we try to get together and learn from each other and look at how these things, they work and try to figure out what is the best tool for what time. We do prototypes as well, which don’t have to be pixel
perfect, so what’s the best tool for that? Can we do that quickly, etc, etc? Really it’s the right tool at the right time, I think.

Justin Avery: That’s really refreshing to hear that. I’d say a lot of people sometimes they decide that, “We are using Photoshop and we are using WebStorm,” and you just learn it. It might not actually be applicable to the particular project that you’re working on, so
it’s good to hear that someone the size of the BBC enterprise level isn’t being that prescriptive, that you are following that process.

With the process as well, you touched briefly on the workflow. You were saying that different people within your team have different sets of skills. How does the creative process go in any particular project within your team?

Ulrik Hogrebe: Again, it’s the right tool for the right thing. [00:14:00] Ideally, in a perfect world, we were in a relatively agile fashion. When we’re working with so many designers … We have so many workstreams going on. The developers as well, they’ve got tons of workstream. They’re
not just working on front end stuff. They’re working on backend stuff. That really tight integration between developers and designer sometimes just for logistical reasons just doesn’t quite work as much as we’d like it to do.

We generally try to be relatively agile. Let’s call it that. Agile brings up a number of other challenges around when you’re doing it at scale, like we are. We have these 28 language sites, and we have the UK site. Then we’re doing elections. Then we have an app. Then we have this, we have that. From
a design point of view, of course, what you want to be doing is trying to get some sort of consolidation and strategic direction about what all of these different products and platforms are doing.

On the one hand, Agile is an enormously powerful software delivery tool, and it’s great for that. You know where you’re going. You just bang out and you iterate and you test and you try and that kind of thing. Defining, A, where you’re going can sometimes … Having that rough idea, “In the future,
this is where we want to go,” where you need sometimes to step out of that Agile process and have a little bit of time to think sometimes, especially when you’ve got, like I said, multiple platforms, multiple things that need to work together.

“Is the app really doing the thing that it’s good at for our audiences?” “Is the responsive website doing that good thing?” Then down to the micro level, which is just about, “Have we got a [00:16:00] consolidation of patterns?” “Are patterns consistent across everything?” Sometimes you just have to
step out a little bit and have a good look at that and say, “We need to fix these things.” We jump in and out of an agile process, a little bit depending on what we’re doing and what kind of project we’re working on, but once it comes down to delivery, we try to be as agile as possible.

Justin Avery: Nice. You’ve just delivered a couple of projects recently. There’s a launch I think of the tablet and maybe the full responsive design site.

Ulrik Hogrebe: Yeah. Just before Christmas, we relaunched all of the 28 language sites to responsive. That is everything from Russian to Sinhala to Persian. Basically, we launched them all the way up to desktop, so they are the default sites that you go to if you punch in BBC.co.uk/Persian,
for example. Of course, we’re looking to do the same thing with the UK site. Was it last week? I think we put the desktop opt-in out. .

If you go to the static site, in the indexes, you should be seeing a banner that will redirect you to the responsive site. Obviously, once we’re offering you to opt into the desktop experience, then we are not far away from actually having released to the responsive site. We’re almost there. Pretty
exciting.

Justin Avery: That’s really cool. How did you approach the language sites? What were the differences around the language? Did you have to use different fonts? You had different languages, different encoding, right to left [00:18:00] stuff. That must have been a nightmare.

Ulrik Hogrebe: I have to say that I came into the project relatively late where a lot of this heavy lifting around typing scripts and that kind of stuff was already done by one of the former creative directors called Kutlu Canlioglu. He’ll hate me for mangling his last name there.

Justin Avery: A bit like I did yours at the beginning.

Ulrik Hogrebe: Actually, if you’re interested in that kind of stuff, there’s a nice little talk that he did for Ampersand in Brighton in 2013, where he talks about some of the difficulties of designing for things like Arabic scripts. Arabic, obviously, it’s right to left, but not only
is it right to left, it’s also got several different variants based off the same alphabet [reading 00:18:57]. They change a little bit depending on which region you are globally.

If you look at the standard system fonts that were available at the time when they embarked on all this stuff, essentially there was 4 standard system fonts that would do Arabic and they would do a simplified version of Arabic. All the glyphs would be the same, so it would essentially be 4 different
type faces with one Arabic glyph set in something called simplified Arabic.

They were just not really cutting it. They had no cultural differences. It completely undervalues the calligraphy tradition in each region and all that stuff. Kutlu actually worked extensively to work on a font that was already created called [Masin 00:19:50] by a typographer, whose name escapes me
right now.

To actually create [00:20:00] localized versions and actually really beautiful scripts that would work in web browsers across all these different nations. We’re doing quite a lot of that. From the design side of course, for each script that you’re using, they’re slightly different line heights because
of the ascenders and descenders and all that stuff, but luckily, bless his heart, Kutlu worked out all that detail before I joined. They are now embedded in code, so we have those different line heights.

Justin Avery: I’m thinking this is not front end of your strategy. I come from more of a CMS background. I’m just thinking that when people are writing copy, you usually … They go, “This is a headline. It has this many characters,” or “This many words are allowed to
be within that headline.” Does everyone work off the same restrictions for languages because I’m thinking that a headline in Arabic could be a hell of a lot longer or in Russian it could be crazy long, right?

Ulrik Hogrebe: Yeah, the Russians have extremely long words. That’s definitely one of our main challenges around the way that we’re … It will pay off if I talk a little bit about how the design of the website or how we’re building the websites at the moment. Essentially, what we’re
doing is that instead of looking at pages, we’re looking very much at components and modules.

For us, a page is essentially just a stack of modules that we put together in different ways. What that allows us to do is we can then design a module and then we can draw up that module different places in different pages. The way that we design those modules is that we then design them from the start
so that they work not only with Latin scripts, but also with left to right [00:22:00] and with all the other different scripts that we’ve got.

We take a very language agnostic approach to how we design the sites and such. Every module, regardless of whether they’re using it on a Latin script site or an Arabic site will work. At this point everybody in the team has quite a bit of experience in this so we per gut feeling, we can see, “Ah, this
is not going to work for Russian.” It’s too tight. It’s never going to fit. Words without brakes and orphans and all that kind of other stuff. Essentially we will do some language testing. Typically we’ll choose 2 or 3 of the most difficult scripts, then we’ll run the modules through them so we’re sure
that they’ll work.

Justin Avery: Do those modules go back into the global experience language or is it something separate?

Ulrik Hogrebe: They’re slightly separate. They’re built on the global experience language, the foundations of that. We work to a set grid that is more or less consistent across BBC. The patterns that we are creating for news obviously are pretty specific for news, a lot of them. We
have a separate pattern library for that, this responsive pattern library, which essentially shows every single module in a different permutation at different break points.

In that way, we are building up this pattern library, a module library. Really also just let’s us drop things onto pages. If some of our indexes for some of our pages at this point, we almost don’t have to do any designs for them. We can more or less just do [00:24:00] wire frames and say, “This is
a 3 module. This is a 2 module, and that gets followed by a 5 module,” and they all react responsively and they just work.

Because we’re doing it that way, that also means our designers don’t have to do everything from scratch. We tend to do mock up sometimes to show stakeholders, “This is the final thing that you’re getting.” A lot of it, in theory, we could basically take requirements and plop them down on page and they’d
kind of work. Of course there’s finessing in there as well.

Justin Avery: I can imagine there’s a lot of finessing to get these things to fit together, especially across, as you said, 28 different languages. [crosstalk 00:24:39]

Ulrik Hogrebe: Oh yeah, absolutely.

Justin Avery: With all those different languages and stuff, the BBC, and not just the new site as well, even at a greater level after anything BBC.co.uk/whatever. There’s so much content. It has to be one of the largest, if not the largest, news or content creation area
outside of things like Twitter and YouTube and Facebook, but that’s people creating, that’s us, me and you creating that content. What are some of the challenges around all of that different … What is the biggest challenge for the BBC and for you around all that different content?

Ulrik Hogrebe: There’s a lot of challenges around that. First of all I have to say, that is a luxury problem for any organizations that have too much content. It’s almost unheard of, and that’s such a privilege to be in that position.

When that’s said, then one of the trick thing for us is how do we then surface all this content to the user and make sure that it’s interesting [00:26:00] and appropriate depending on devices and all that kind of stuff.

That also comes down to, especially with a news site, which is very … News is traditionally a print led. Then it became a desktop led. We talked very much about things that are above the fold. That’s your premium content. As soon as you go responsive, then that fold becomes slightly meaningless.

One of the things we do around content is trying to figure out what is the relative hierarchy of this content? What do people want and is there a system where we can start putting content into the right brackets at the right time with the right device. That can definitely be challenging because there
is a lot of good content. Choosing which ones, what is the most important one, is a really difficult … It goes back to print times. What goes on the front page, essentially.

Justin Avery: When there actually was a fold.

Ulrik Hogrebe: When there actually was a fold, yes, exactly. That can be enormously tricky. We do different things. The way that we think about responsive let’s us do things, for example, we can position things relatively high up in desktop, but then instead of doing the simple reflow
where everything …

Ours is a 2 column system. We’ve got a primary column and we’ve got a secondary column, a left hand and a right hand for [inaudible 00:27:39] and scripts anyway. Normally what you do is you take that right hand column and you shunt it below so that everything is linear on a mobile device, for example,
but that doesn’t work really well for our content because some of it …

We want to take advantage of the 2 column system and say, “Well actually that means that we can have 2 pieces of content [00:28:00] of equal importance on a desktop next to each other, but if we then do a simple reflow, then that 1 important piece of content then falls below.

WE’re doing these things where we’re saying, actually we’re going to have 1 thing reflow under the other top most important thing and then all the other stuff in the right hand column reflows right at the bottom. We’re trying to do all this kind of stuff that let’s us think a little bit harder about
where we place our content and how we make sure that things reflow so that the importance of the content doesn’t just disappear just because technically it’s the easiest thing to do. Does that make sense? I feel like I just ramble the way.

Justin Avery: No, no, it’s good. The more you run away with these things, the better these tings go. That’s really cool.

Ulrik Hogrebe: I have Post-its and markers, and then I sketch things.

Justin Avery: It’s always easier to explain things when you have a white board or something to draw. That is actually really good.