Whilst transcribing my EuroIA lightning talk into blog format, I found I had more that I wanted to say. Rather than create a behemoth 15 minute read, I decided to dedicate an entirely separate post to the backstory. I think that’s good reader experience architecture.
1. Sketch until it makes sense
Initially, I underestimated the magic of manual sketching. I’d always seen it as inefficient because:
- I can’t edit it (unless I use pencils — UX heresy)
- I can’t immediately share it and export it in a variety of formats
- I’m killing trees
It was a then Junior UX Designer, Ash Middleton, that began my conversion. “Just sketch it!” was basically how she started every collaborative discussion we had.
Fast foward to July 2016, and I rotate into the GEL team — responsible for maintaining and growing BBC UX&D’s Global Experience Language. After settling in, Dan (my Creative Director) asked me to talk about what I was working on. As I talked, he sketched.
As the picture built up, it became apparent that I really didn’t have a high level handle on everything I was working on. The GEL ecosystem is broad, and I had a lot of plates spinning that I would struggle to keep moving if I didn’t even know which ones were starting to wobble.
I took the sketch, and had a go myself. Then I took that sketch, and iterated. Sketch, rinse, repeat. By the end of the day, I had a really clear set of workstreams split into quadrants according to how established the work was.
Iteratively sketching my domain until it made sense helped me get a handle on my responsibilities. Since then, I’m now much more likely to be raiding the printer drawer than booting up Omnigraffle.
2. Show something wrong to make it right
This particular lesson also came early in my UX career, albeit from a slightly different perspective. My first UX rotation was working as part of the team working on the BBC’s suite of Connected TV apps, led by Ray Mosley. My working life up to that point had taught me to always hold back on presenting recommendations until I felt I had fully thought through and anticipated every possible objection stakeholders could throw at it.
Thankfully, the UX/Product relationship at the BBC is pretty harmonious. In his direction of the team, Ray always pushed us to get our bare bones concepts in front of our Product Owners as soon as possible. This also extended to Developers, Tech Architects and Business Analysts— it’s arrogant to think we would be able to foresee everything they would, so including them in the discussion is just good business sense.
Having learned to get our ideas in front of stakeholders early, I took it a step further. I used it to get my understanding of other people’s ideas out in the open.
When rotating into BBC Education, I needed to get to grips with the Curriculum Ontology and its back-end implementation so I could work on the BBC Bitesize product. I spent some time with Eleni Mikroyannidi, and we sketched as we talked. I went back a few days later with a formal map of what I understood from our conversation:
Eleni pulled it apart, clinically (but politely) — as a good Data Architect should. I got the part about how Levels are constructed pretty wrong, and some of the relationships were superfluous, or just plain not used in our implementation of the ontology. I knew I’d probably be wrong, but I also knew that my understanding would be corrected by sharing it with Eleni.
3. Embrace your Imposter Syndrome
When I started putting my lightning talk together it together late last year, I took a defensive attitude to the points I would include and the way I would present them. I deliberately tried to make my slides as bare bones as possible by scribbling down the first sketch I came up with to illustrate each of my points. Here’s one of my original slides:
I passed this off as good ol’ prototyping, but really it was about my simmering feelings of impostor syndrome working in a department full of extremely talented designers and UX professionals.
As it happens, the simplicity of my sketches was one of the things people loved most about the presentation I was putting together. I also got useful critique on the lessons I was considering for inclusion. By letting my impostor in as a kind of conscientious objector, I actually ended up with something entirely more interesting than I would have created otherwise.
4. Make sure the project can pivot
Honestly, I really struggled to illustrate this one. Here’s my first prototype:
Here’s my attempt at using future cones:
And here is the sketch I ended up using with my fortune telling UX professionals:
Even though coming up with the right picture was a challenge, I still wanted to include this tip. It feels so fundamental to what a good Information Architect should be doing.
And it’s hard. When siding against a folksonomy implementation in a prototype component library, one of my strongest points (I thought) was that we were making for a more limited set of futures. It was always going to be more difficult to close an open system than open a closed one.
Ultimately, we went with open tagging in the hope that it would help us collect data on the language our users employed to describe the components they were adding. I won’t say it wasn’t hard to have my recommendation as an IA discarded. What it did teach me was to (wherever possible) look for factual or historical backup for my recommendations over reasoned predictions.
5. “Si parem fortunae commemoras picturas populus”
“If you show a quote, people will take pictures”
This started as an amusing observation that I thought would make a nice meta-joke. I did genuinely observe people at conferences and meetups snapping shots of slides before the speaker had qualified the quote’s inclusion.
When I took the first draft of this talk to the weekly meeting of BBC UX Architects, they liked the joke, but reflected that it was slightly wasteful to not go further. I was describing an actual behaviour, what could I actually learn from it?
The thing that stood out was the “snackable” nature of quotes. They can work in isolation and as part of a bigger picture. Therein lies their power: an anchor point in the midst of deeper content. Looking beyond just quotes, I realised this is something we naturally do all the time, and to great effect.
We delivered an early version of our Diagrams, Maps and Models workshop at World IA Day in London. For a fun hook, Senior UX Architect Jo Chambers suggested we toy with an applying mapping techniques to ‘Eastenders Murders’. For the unitiated, Eastenders is a long-running BBC soap opera, in which a LOT of people die at the hands of their neighbours.
Though I was admittedly skeptical at first, it paid off spectacularly on the day with high engagement from the workshop attendees. My particular contribution was an attempt to map the stakeholders involved in influencing how a character should be removed from the show:
Incidentally, we decided not to carry the Eastenders theme through to EuroIA simply because it was much less likely our workshop attendees are even remotely familiar with the TV show.
6. There is no single, personal source of truth
Personal organisation is something I’ve battled with my entire professional life. For a while, I fought my haphazard nature with dogged scheduling. Every single task was assigned time on the calendar, which meant when people needed my time, my default answer was “How about next week?”
The BBC emerged as an entirely different proposition. Working in UX&D, supporting development teams employing different flavours of Agile, we have to be flexible and ready to respond to unforeseen technical challenges that affect our designs. At the same time, our calendars fill up quite quickly anyway, meaning that filling the gaps with planned tasks is a risk. Mix in the unrealistic expectation I placed on myself to exhaustively track everything and I was dooming myself to failure on an almost daily basis.
What I discovered was that if anyone asked me where a task was at, I could answer almost immediately. Granted, this is somewhat useless because:
- They have to come ask me in the first place, and
- It’s not a reliable way to keep track of deadlines
Even on the days when I did get everything in hand (which would always follow me spending at least an hour updating Trello), the feeling didn’t last long. My thinking would change almost hourly, especially after a long train ride of mulling things over.
So assuming my task tracking could never be perfect, why strive for it? I decided to co-opt the strategy of “just enough documentation” in my work management. In practice, this just means keeping the high level workstreams ticking over with a weekly review, whereon you can dump your brain buffer and move on.
7. Find a way to do things in ANY order
In my work at Smaller Earth prior to the BBC, I was familiar with most of the technologies and constraints that affected what we could ultimately build. I also had a close working relationship with the developers responsible for it all, so could always bother them for a chat when I needed to know more.
As a BBC newbie, I wanted to dive as deep as I could on the underlying architecture so I guide the UX Design with a firm handle on data models and feasibility. With this in mind, I was completely unprepared for the vastness of the BBC estate.
For every audience-facing product, there are at least a dozen more plodding away in the back-end. When I say a dozen, I really don’t know. It could be 100. I honestly don’t think any single person has an idea of everything that is out there. When we decommision legacy architecture, there’s always a fear that something we didn’t know existed will stop working and cause a chain reaction that brings about the apocalypse.
I mention all this, because with many systems comes many stakeholders. Every new acronym I heard added another hypothetical person to my list of people to introduce myself to. As mentioned in my talk, I wanted to try and meet people efficiently. Like the Travelling Salesman Problem, I wanted to plot the optimum route through stakeholders and end up back home as quickly as possible. Taking the metaphor further:
- I don’t know where all the cities are
- Even if I do, they might have moved when I get there
- I don’t know how far apart they are
Thinking about it, there’s a parallel to draw here between Agile and Waterfall and ways of working. I could try and find EVERYTHING out and plan a route according to the depth of dependency a particular stakeholder inhabited. Or, I could just talk to the first one I found and use what I found out to inform my next move. It almost certainly will be an inefficient route, but at least I’m on my way.
Final Thoughts
I hope you found a nugget or two amongst my ramblings. I don’t write often, but speaking at EuroIA felt like an opportunity to put something out there and see what stuck.
If you have comments or questions, I’d love to hear them. You can bother me over on Twitter @robscottsays, or drop a reply below.
Thanks to everyone at the BBC that has helped me grow and learn since starting my role last year. I hope I can repay the favour.
