Category Archives: User Experience

From Void, to Matter, to Meaning

2 Replies

Earlier today, Dan Klyn retweeted a piece by Cennydd Bowles entitled ‘Void and matter’. It’s an interesting spin on the age old question of ‘what is information architecture?’, and more specifically, how the practice differs from other types of User Experience Design, such as Interaction Design.

Back in 2008, I had no idea what information architecture was. I started to attend the BBC’s IA team meetings, thanks to the generous invite of Karen Loasby, despite me not being a member of that team just yet, and there was plenty of talk of ‘defining the damn thing’.

More recently, Abby Covert, amongst several others, has done stirling work to reinvigorate the practice and consideration of IA. I’m loathe to open up the definition can of worms, but I started thinking about it in response to Cennydd’s piece, and I came up with this:

Information Architecture is the design of structures and/or systems that communicate meaning.

By which I mean — almost everything in the world conveys meaning of some sort, whether it is intended to, or not. Hence apophenia (23). But when you do design things in order to communicate some kind of meaning or idea, you are designing an information architecture. This, of course, sounds similar to ‘information design’, I suppose — though I’d argue the latter is perhaps less focused on structures and systems.

If you ever find yourself looking at a piece of web design (let’s narrow it down to that for now), and you wonder — but what does it actually mean, what is it trying to communicate? Then you’re thinking with an information architecture hat on. And, more importantly, to not consider the meaning, or indeed the perception, or what exactly someone is meant to take away from your design, is a huge failing. Which is why I can’t understand UX processes that don’t seriously make time for IA — and probably why IAs who do care so passionately about the meaning of things do get so easily drawn into ‘defining the damn thing’.

Anyway — to Cennydd’s piece directly. What I very much like is the distinction between designing “things that are smaller” than the designer, and “things that are larger”. It reminds me of the old adage that you should always design your product, system, platform or service to be able to fit into a larger system. Don’t just think of your work as the be all and end all — allow it to enable things you’ve not even thought of.

Cennydd also makes an interesting metaphor in “designing the void” versus “designing the matter”. But here’s where I’d like to stress something — designing the matter is absolutely information architecture as well. This isn’t a criticism of the piece — there are no definitive ‘correct’ answers here — I’d just like to offer my spin on something I feel really needs to be highlighted, else IAs (and other UX folk) feel they’re off the hook.

The examples that Cennydd gives — “the tools people manipulate. Materials with properties and responses”. Now, more than ever, information architects need to get involved here. Because the matter we’re creating on the Web is made almost entirely of information structures.

Think about APIs, think about URIs for Things, think about domain driven design with its classes and properties — those are the tools we make available to manipulate, these are the things that we grapple with on the Web.

Information Architects need to be involved in designing the matter on the Web. Interaction Designers need to understand APIs, URIs for resources, linked data (yes, I know), REST and so on. Because that is the raw material we’re dealing with here — networked, interactive information. Designing the matter is the real Web design. And whatever your UX leaning, understanding that is key to harnessing the wonderful medium we have at our disposal.

This post is also available on Medium.

Some quick thoughts on URLs

Leave a Reply

This past week, there’s been a kerfuffle about an experiment within Google’s Chrome browser which hides URLs from the user. Lots of good folk have chipped in (three posts there, to give you an overview), which is good, but here’s a few thoughts before I forget to write this at all:

– As with any design decision, this has good and bad points. The discussion needs to be level-headed and focus in on the issues that the decision is trying to solve, and work out, clearly, what those issues are, and whether there are better ways of solving them.

– For instance, this has been described as (and I’m paraphrasing here) ‘using a sledgehammer to crack a nut’. That may well be true. What’s important, I think, is to have a public, open space where someone can say ‘hey, this is an issue in all modern browsers, let’s discuss how we might solve this’ – rather than announcing that some internal team has made a design decision and haven’t (as yet) explained their rationale. Again, this last point is key – show your working, explain your thinking. If you don’t, someone else will try to join the dots for you.

– The security faults and general ‘WTF’ of URLs to the ‘average’ user is such an issue. But I’m not convinced this is necessarily the best way to improve it. I might well be wrong, but let’s discuss it.

– Sir Tim Berners-Lee’s first browser didn’t show URLs. URLs were never designed to be seen by the user. Indeed, being visible leads to one of the most unfortunate side effects – people feel they have to be human readable. Now, I’m not saying that they shouldn’t be human readable, but it’s more that people often prioritise that aspect over, in my opinion, their key feature – they should be permanent and unique. Human readability is the next step after that (as is a clear, logical rationale, that makes them hackable).

– URL design, however, is, in my experience, a very sadly neglected art, with key principles, hard decisions and a profound impact on the user experience (if you read one article from this post, make it that one). Hiding the URLs, I agree, could easily lead to less effort being spent on crafting them well. Out of sight, out of mind, as it were. On the other hand, as above, it could take them out of the spotlight and therefore more easily kept in the hands of those who care about getting these things right.

– Equally, talk of ‘the death of the Web’ can be mis-interpreted, very easily, to have the same effect – those who don’t follow this stuff closely will thus assume that they don’t need to care about such things, and it all goes to hell. Basically, drama can multiply the negative effect, as well as drawing attention to the potential damage being caused.

– Whilst I don’t think there’s necessarily a sinister motive behind the experiment, I do agree with ntlk that this kind of thing could easily play into the hands of entrenched, powerful players – sleepwalking into an I intended consequence – and we shouldn’t let that happen without a fight.

– I dearly hope that the idea of the sustainable Web comes to fruition – as Dan Hon says, “One that is kind of adjacent to the indie web, but that builds long-lasting, reliable services, not ones that disappear”. I hope this happens in the industry. Because then we might finally start taking URL design, and hey, maybe a site architecture that is a Web, rather than a hierarchical file directory, seriously as a topic, both in terms of development and UX.

Update One: As expected/hoped for, Michael Smethurst has written something more precise on the topic – go read that.

Update Two: Please don’t get me started on these really, really stupid vanity TLDs like .london and so on. They are pretty much pointless, for people wanting to be duped into paying money for the latest fad. Sorry. It makes me angry. But hey, if it’s ‘seen to be important’, why not go ahead and buy a .HORSE domain name?

On Design as a Service

Leave a Reply

Yesterday, Tom Maslen wrote this piece, on responsive design and how the BBC’s User Experience and Design (UX&D) teams are set up to work with the various BBC ‘product’ teams. It’s good, you should read it, and then come back and read the rest of this.

I agree with almost everything in there, but thought there were a few points that needed fleshing out, perhaps with a slightly different viewpoint. Obviously everything which follows is personal opinion, and is offered up in the spirit of open communication, with the aim of making things better, rather than personal attack or criticism.

Some background

From October 2008 to December 2013, I worked in the aforementioned UX&D team. From 2008-10, I was part of an embedded team within BBC Audio & Music (A&M). From 2010 onwards, the department, alongside most of BBC Future Media (FM), was reorganised several times, and we became more of a central team.

It’s fair to say that I found the time embedded within A&M much more productive and fulfilling, though of course there were rough patches too. I strongly believe that the embedded nature of the team was a big part of why it worked so well – but there were plenty of other factors.

Although Henry Wood House wasn’t the shiniest of buildings, the three floors that we were based on were open plan and yet small, giving the air of a small business. Open enough to share, and not large enough to be overwhelming and faceless.

Thanks to the sterling work of Tristan Ferne and others, we had what was known as 10% time, similar to Google’s 20% time, which was a chance for anyone, of any discipline, to work on their own personal projects, as long as they were somehow related and beneficial to the BBC. We had monthly show-and-tell meetings, where people could come with ideas or requests for help, and this all promoted a very positive atmosphere of shared expertise and mutual learning. I’d bring it back in a heartbeat. But anyway…

Taking the emotion out

One thing it’s important to state clearly, is that any critique of current practice or organisational structure has to be divorced from personal criticism. As Jake and Crystal both pointed out, correctly, there is no-one at the BBC, either within or outside UX&D, who is actively trying to keep designers and developers from working together. There is no evil master plan. That said, several very good ex-BBC people cited this way of working as one of the reasons for leaving the BBC, so it’s something that shouldn’t be swept under the carpet as a non-issue.

Most of the designers I worked with in UX&D are great people, who would be more than happy to work alongside developers. And there are good people within UX&D working on figuring out how we should adapt to responsive design and the main truth that Tom, and others, have pointed out – online, you simply can’t control completely, how your users will experience your content. How do we provide the best possible design solutions with that in mind? I agree, we start from the bottom and work up.

And finally on this point, I think it’s important to have this discussion in the open – like I say, no-one wants to make things worse, so we need more discussion between developers and designers – and I know that there are plenty of people at all levels of the UX&D structure who want to make things better. So let’s make something good happen.

Here be problems

That said, there’s no denying that there are problems with how things are done at the moment. Again, this isn’t necessarily the fault of personalities, it’s just the way the organisation is structured, and how working practices easily fall back on ‘traditional’ waterfall-esque design approaches. This really needs to change. Everyone needs to be focused on delivering the real thing, and realise that User Experience includes loading times, page weight, caching and so on, all the way down to how you structure your content and your data. As Tom says, start with understanding your content, not just your users – really understand it, and design around that.

Tom is also right that the ‘4-screens’ mantra, and break-points approach, is holding us back as much as it is helping. Again, I think both of these things have good intentions – the first is to underline, to those of us not familiar with the mobile web at all, that we need to change from simply designing a desktop site, to something which works across multiple screens. The second is simply an attempt to be able to design *something* given the vast array of screen proportions.

But ultimately, both things are flawed – Tom advocates ‘all screens’ – I’d go further and say ‘no screen‘ – because what’s really important is the information, the content, the meaning and interaction with your users, and this needs to be designed to work in any possible medium. That’s why I’d start with designing your domain, API and URIs, then build up from there.

Defending the Centre

And yet. I’d like to somewhat defend the ‘central UX team’ approach, just a little. Or, rather, extend some empathy towards understanding why such an approach has been taken. Because one of the problems of such a large organisation such as the BBC is its’ traditional silos. The ten products strategy, although great at reigning in the sheer volume of wildly-varying-in-quality online output, has, unfortunately, reinforced silos as much as it has broken them down.

And so having purely embedded design teams can lead to massive differences between the ‘products’, and a lack of joined-up thinking or overarching strategy. With that in mind, a central team which can work across many products, makes sense, of a sort. It also helps foster a community spirit, and shared knowledge and expertise between designers.

However, it also encourages and highlights the differences between disciplines, and, just like with the different products, a separate team with separate objectives will lead to people pulling in different directions. It also leads to organisation structures and layers of process and management which result in unexpected side effects like completely separate desk spaces for different disciplines.

To be clear, I think there is a very good rationale behind the idea for a central UX team – from within News, or any other single product, it may make perfect sense to have an embedded team, but when you’re responsible for establishing a quality standard of design across the whole of the BBC, you’ve got a more macro-scale problem to deal with.

Forever Cycling

The other problem Tom highlights is the cycling of UX&D staff through different products. Again, having witnessed things from the other side, there are good intentions behind this. As David hints at, rotating staff gives people a chance to try new things, to learn from different teams. It helps spread knowledge around, so that if a member of staff is away or ill, and again, reinforces the sense of a consistent approach to design across all areas of the organisation.

And yet Tom is right – it also means that you have to spend an overhead of time training up new joiners, a lot of expertise can just disappear overnight, and, quite frankly, the resource management of all this can be a nightmare from the UX side of things too. Personally, I also felt under more pressure in this system, as I was never fully in control of my own resourcing (but then unless you’re freelance or run your own business, you’re never fully in control, so that’s almost certainly just my hangup!).

In Summary

Overall, then, I think Tom is pretty spot on, if veering a little towards a too-negative perception of the people that make up the UX&D team. But a) I don’t think that’s intentional, and b) this is exactly why open discussion, sitting and working together is needed – because the more we continue to define ourselves as separate and different, the more that others will make assumptions about our attitudes, and communication breaks down, being replaced by suspicion. Gosh, that’s just defined multi-cultural tensions in a nutshell.

I would advocate embedded design teams, or rather, completely multidisciplinary teams, focused on the same goal – making the best possible thing, for the most number of users, via any form of interaction. But I do think there’s important and complex problems to be solved on a more macro level across an organisation such as the BBC, if we are to maintain a good level of quality.

I’d suggest this can be achieved not by separation of disciplines, but more by a loose and regular discipline meet-up/network type approach, perhaps, so that people of similar skills can keep some sense of community and share ideas and expertise. Having said that, the sheer size and geography of the organisation doesn’t make that easy – but it’s not impossible, we just have to try.

And finally, as Michael quite rightly points out – all of this is pretty useless if the rest of the ‘business’ is unengaged and even more separated from development than design.

There are good people who want to help solve this. Let’s keep talking, but more importantly, do something. Maybe moving back into Henry Wood House is a (completely impractical and impossible) start.

Designing Webs – Euro IA 2013

Leave a Reply

On Saturday, I presented a talk at Euro IA 2013 called ‘Designing Webs – Information Architecture as a Creative Practice‘. Rather than write the talk up in full, for now, I’ll just link you to the slides (with my speaker notes), Martin Belam’s write-up, and Boon Yew Chew’s sketch-notes (ooh, my first ever sketch-notes!).

This talk was a long time in coming. The ideas contained within have been bubbling around my head for most of the year, indeed, ever since I (re)discovered TARDIS Eruditorum and, at the same time, was pointed to John Higgs’ book about the KLF (thanks, Libby!). Reading both at the same time, the connections between Alan Moore’s concept of magic, the ideas of alchemy, and linked data/internet of things, were both fascinating and strangely familiar.

I wasn’t the first to make these kind of connections – Dan Catt has touched on similar things with his Artisanal Numbers project. Indeed, a lot of the content of the talk owes much to others – Michael Smethurst, Leila Johnston, Alyson Fielding, Tom Coates, Tom Armitage, James Burke, James Bridle, Russell Davies – all far cleverer and more accomplished than I. And yet, I wanted to draw all these threads together. I’ve had about three draft versions of blog posts just touching on the magic/alchemy thing sitting on WordPress for ages, and I could never quite get it to gel. The talk, being forty-five minutes (or just under, once I’d cut out the various comedy clips I was going to include, given the rather tenuous Edinburgh Fringe connection), doesn’t cover all the ideas I would have liked to, or in enough depth. I’ve probably been far too simplistic about the ideas of the people I’ve mentioned above, but there is frankly loads to say. Indeed, I’m hoping that an upcoming episode of Henry Cooke‘s Unevenly Distributed podcast will expand on a few of them (it was recorded a month or so prior to writing this talk).

I’d also like to explore the themes a lot more – getting my hands dirty with Arduinos, bringing to life the Internet of Fictional Things and so on. Also, I can certainly see how the talk might be perceived as a little too wooly, hand-wavy, naive. In response, I’d say that yes, the magic/alchemy thing is just a metaphor, albeit a really interesting and fun one for me, but there are practical points underpinning it. Not least that by thinking of your product, service or creative work as a web, rather than purely as a website, you get to the absolute essence of what it is – which helps you design for both now and the future. Martin makes the point that when redesigning the Guardian’s Culture section, he tried a similar approach – yes, it’s not necessarily easy or possible to complete the task straight away, but remember, you’re trying to build something that will last, something that will add to human culture and society in the long run – something which one day we may not even need a screen or visual interface to interact with – we might be able to appreciate each web for what it is.

So, yes, there it is. Thank you to all those who encouraged me to write the talk, refine it and so on – oh, and one note of caution – the domain model for sport (really just football) which is at the beginning (and you may have seen in a much more visually appealing state in some of Mike Atherton and even Louis Rosenfeld’s presentations) – that’s not actually the official BBC one, it’s one I created myself a while back, but has influenced the BBC’s Sport Ontology.

On a difference between TV and Radio online

1 Reply

In the pub last night, Jonathan made a very good point, I thought, about one of the differences between TV and radio production teams and their approach (and/or ability) when it comes to online – and why, historically, radio has tended to have a much closer relationship with Web teams.

The reason being, simply, that the proportion of live to pre-recorded shows on TV and radio is significantly different – almost opposite, most probably. Radio typically has a lot more live, or very-nearly-live, output, and thus the production teams are still around and engaged around the time of broadcast. Therefore, they are much more likely to be interested in committing resources to improving the available information about their programme online.

In contrast, TV production teams are, more often than not, completely disbanded, or at least concerned with a completely different piece of production, by the time transmission comes around. Thus, there is, if not less impetus and drive, certainly less possibility of being able to commit resource to supporting the actual broadcast.

Which is a shame, really. Because despite this difference in production practices, I don’t think that should be a barrier to becoming more engaged in creating experiences online. This isn’t an intrinsic, insurmountable barrier. It’s just that we need to adjust our mind-set and processes – both on the tech and production sides, and engage at the right time.

The difference doesn’t mean it’s impossible for TV to catch up with radio in this way, but it means we all need to be considering not only how we make new formats for TV shows, nor how we package up, distribute and explore existing content, but how we really integrate with production teams and work together to create a single experience.

The fact that a standard approach to getting tech involved with production processes tends to side more with broadcast technology, and/or smoothing the production process itself, is not a bad thing per se, but why not consider the eventual audience of the production at this stage, too? After all, the rest of the production team is already taking this into account – set design, lighting, scriptwriting – all of these balance the need to make production as easy as possible, with the ultimate goal of conveying something to the audience. It’s the latter which we take for granted as our mission when considering traditional ‘web applications’ and so on, but not when we think about getting involved with production teams themselves.

I’ve always been a proponent of getting tech teams much more involved in the production process – harnessing what we can from the exhaust (and, perhaps, the energy within) from production. Cast lists, locations, there is a wealth of data there which is not only useful from a production workflow and archiving point of view, but things that could provide real audience benefits, far beyond the easy to see but niche ‘location spotting’ uses. Yes, this has been the realm of massive IT projects in the past, but their fortunes shouldn’t dictate whether or not we at least attempt to do something in this area, on a more sustainable, smaller, dare I say more agile scale in the future.