How co-design can shape big companies from the inside
This is the transcript of a talk I gave in October 2019 in Bologna for the XIII Summit Italiano di Architettura dell’Informazione, organised by Architecta.
The main topic of the conference was “Designing for Communities” and I was invited along with my Creative Director at the BBC danramsden who presented the talk “Two heads are better than one”.
My contribution to the talk consisted of a set of case studies, focused on central topics such as collaboration between interdisciplinary teams and design approaches and techniques.
I explained through a set of real working life scenarios how I managed to help people to bridge the gaps between disciplines, to build a good shared understanding and to communicate effectively. I stressed the concept of how important is to pick the most effective tool at any time to communicate across disciplines.
I explained how to make possible a collaborative design approach in such a complex organisation like the BBC.
Please note: The information in this case study is my own and does not necessarily reflect the views of the BBC.
Presentation
I work at the BBC in S&SD (System and Service Design) as UX Architect.
I work on the design and the user experience of the tools used internally by the BBC, trying to make complex things more meaningful.
We can say that, in a way, in S&SD we take care of everything behind the scenes.
For example, just to quote a few of them, in our team we work on the CMS used by journalists in BBC News all across the world, on many different web-based video editors and on commissioning and scheduling softwares for Radio and TV. We deal both with the final users and the stakeholders.
There are literally hundreds of internal tools, used by hundreds of teams and thousands of people.
I’m going to talk about organisational silos, reusability and scalability.
We’ll see how a good reflective practice can help in the design process. We’ll see how important is to pick the most effective tool at any time to communicate across disciplines, to build shared understanding and connect effectively.
Organisational silos and everyday life
Big companies are prone to a so called “silo mentality”.
It refers to an organisation that is made up of divisions that operate independently and avoid sharing information.
Silos can affect both the communication between entire departments and the communication between small groups of people within a single team.
Why this happens?
There are several reasons for this. The reason can be “political”, but it’s quite often psychological.
While preparing this talk, a colleague of mine, a Senior Product Manager, popped up at my desk because he needed to ask some questions about a project we are working on together. He saw me reading an article on my computer about organisational silos.
He went “ Oh, I love silos!”. He was joking, of course, but I’m sure that, in a way, he meant it.
Why am I saying so?
Let’s have a look at the Maslow Pyramid of needs. An all time classic.
The pyramid is the graphical representation of Maslow’s hierarchy of needs, a theory in psychology proposed by Abraham Maslow in his 1943 paper “A Theory of Human Motivation”.
Needs lower down in the hierarchy must be satisfied before individuals can attend to needs higher up.
As you can see the very basic needs are physiological. Fair enough. Not going to argue about that.
But security, safety… they reside just right above and have definitely to be considered among the most relevant needs for any human being.
That’s essentially why people love silos. They feel safe inside!
The thing is that they can provide benefits in some contexts and be harmful in others. Especially when it comes to agile environments.
At the BBC we constantly try to mitigate the way silos impact everyday working life.
Most companies nowadays work with cross-functional teams (a group of people with different functional expertise working toward a common goal), and it’s important to find a way to remove any obstacle to collaboration.
That’s why we tend to adopt a collaborative, workshop-based approach to achieve this:
- Aligning people and raising awareness of the common benefits in sharing technology and best practices.
- Create a meaningful network of people across teams.
- Validate some hypotheses and assumptions we might have.
The Tools Framework Case
Speaking of silos let’s have look at the Tools framework case
Content silos are evident in our tools, making it difficult for producers and product teams to discover, share, and reuse content. Not to mention that content silos drive to the increasing of software development costs.
Considering that several users’ tasks are rarely confined to a single tool, some years ago the BBC developed the Tools Framework, which is a set of libraries and API driven services that aims to provide a way for task-focused web activities to interact and collaborate with each other.
It is essentially a framework to create and manage reusable components that can be used by the developers in order to allow them to just call the element they needed when building a new tool.
It revolves around the concept of activities, borrowed from the Android Activity Model.
The Activity Model
An activity (in the Android world and in the Tools Framework sense) is a screen or series of screens that satisfy the intent of a user to perform an action.
An activity could be for example “ Browse/list articles” or “Add image”.
The Workshop
Cool! We had our framework and it sounded amazing. But something didn’t work.
People were not using it consistently. We wanted to discover why. We had some hypothesis and we wanted to validate them.
One of the strongest assumptions we had was they essentially were using another open source framework (React) instead of our internal framework to perform their tasks.
We wanted to validate our hypothesis using a human centred approach.
That’s why we decided to run a workshop with some key stakeholders (12 people) in order to learn more.
Adopting a diverge/converge design thinking approach, we asked the attendees to assess the positives and negatives of using Tools Framework and React in relation to their specific tools.
Attendees discussed all positives and negatives established for both options and grouped all comments into common themes with an affinity diagram.
They then dot voted which of the grouped themes they wanted to talk about in the final discussion, what we called the “Roundtable”.
What we found
What emerged was that Tools Framework didn’t work well.
It relied on obsolete technologies (still too many iframes!), there was not enough shared support, it was not scalable and flexible enough…
Someone could say that we killed an idea. I’d prefer to say that we discovered it had to be radically reframed.
But — most importantly — we contributed to get the stakeholders in the same room working in a collaborative way on something. We got them aligned.
We worked with the developers using a human centred approach.
Reusing components is easier said than done
As you might have noticed from the Tools Framework case, reusability is a core concept.
Every developer and every designer should be committed to reusability, and most companies are working in that direction, either building a new framework (at the BBC the Tools Framework project is going in that direction) or adopting existing ones like React.
Reusing Components, avoid duplication…that’s not easy.
We need to work on our culture, attitude and strategy: reusability has not to be seen just as a set of tools and standards, but rather as a development strategy which goes far beyond mere technical aspects.
Striving towards reusability means allowing the teams to think of everything they build as something that can serve other people and parts of the product.
At the BBC we are committed to create the right environment for a more efficient workflow, and as UX practitioners we use our expertise to put in place strategies to foster the communication between people and teams, and promote the adoption of shared standards.
That leads us to the next case study.
The Partner Platform Case
Partner Platform is the tool developed by the BBC to manage the authentication to our systems for both employees and external collaborators and contractors.
Like we said, at the BBC we have hundreds of internal tools and an effective system to grant or revoke access to users is vital.
These days, the team behind Partner Platform are working on boosting up the system, turning it into a proper Authentication as a Service system, enabling simple and secure access to the BBC’s systems and resources for internal and external users with a self service approach.
It is a big change of mindset to them (before they add to enter manually the data).
They asked SSD to help them finding a way to keep the momentum and making it clear among all the members of the development team what this goal means and how they can achieve it.
The Workshop
We wanted to question, push and validate the new model underlying the new Authentication as a Service system, using a collaborative approach and getting all the members of the team involved. We recruited 10 people between developers and technical architects.
The aim of the exercise was to move from a higher level of abstraction (the logical model itself) to a set of actionable and potentially reusable activities.
This process would have helped the team to design a more effective system architecture and efficient reusable UI components.
Before running the exercises, we drafted with the help of a couple of senior members of the Partner Platform team a set of statements according to the new logical model. We tried to translate into statements some aspects of the model.
Considering that the logical model shows the concept of “group” of users with specific capabilities as core concept, an example of statement could have been:
- “A group contains people”
- “A policy allows a group to access a resource”
We then printed all the statements, sticked them on the wall and we asked participants to write down on posits what activities (in the Tools Framework sense) would be needed in order to make the model statement a reality for users.
After less than one hour we had a set of actionable activities on the wall!
We ended up with a wall like this (this is the final deliverable, the digitised version of the wall with post its notes)
We then moved to the next exercise.
Before the session we produced 5 scenarios and 5 proto-personas.
We split the participants into 5 groups and we asked to test the model statements against each scenarios and to create a storyboard (they had to use the post its with the activities previously created)
What we found
Different teams came up with a slightly different workflow / model for their scenario, which was fine because it fostered a final discussion about to which model works best and why.
The work we did together let us identify how much flexibility the model enables, and made the team feel more aware of the importance of taking into consideration reusability and scalability since the very early stage of the design process.
