Understand you web team and let them out of the box

Reading Keith Frankel’s post ‘your designers are not artists, and you need to stop thinking that way’ has reminded me of the many struggles you encounter when trying to find a fit for a web team inside a large organisation.

In many organisations no-one quite gets what the web team’s role is - including the team. There are conflicts between creativity and delivery, expectations are often mismatched on both sides, and no one can actually articulate what success will look like. We all head off in different directions and steer our own courses towards failure of one type or another.

Bridging these misunderstandings has been one of my main tasks over the last five years and while there are many subtleties, not least the ones Keith Frankel touches upon, getting the business to understand how the web team approaches problems is central to delivering successful solutions.

Business problems vs. perceived solutions

Often one of the biggest hurdles can come when an area of the business already has a clear idea of the solution it wants, before it ever approaches the web team.

We have often had people come to us saying “we need a portal” or “we want an online form to do this”. At this point much of the value that a web team can bring has been lost. A good digital team’s value to an organisation isn’t in its ability to implement predefined technical solutions it’s in its ability to translate business problems into workable solutions.

Technically implementing a portal isn’t where the real business value is. Articulating why you do or, indeed, don’t need a portal is of more value. We have, in the past, told people a website wasn’t the answer to their problem - implementing something that wasn’t going to help would have wasted a lot of time and money that could have been better placed in delivering the service.

It’s not an easy message to deliver. Many business are geared to technology as the answer, and someone who is perceived as technical telling you it’s not, can take some adjusting to.

Design Thinking

Design thinking is the method of applying the principles of design to the whole problem - rather than putting design in a box that is only concerned with what something looks like. Tim Brown gives a typically concise TED talk that describes this much better than I can.

The first step in a design thinking approach is empathising with the customer. Most organisations start their processes at defining the problem, skipping the opportunity to understand their customers - the people who will be using whatever they produce.

Stages of Design Thinking Stages of Design Thinking - Stanford Institute of Design

I recently presented at an internal management conference, where we wanted people to resist the temptation to jump in and define a solution straight away. Instead, we tried to get them to reframe their thoughts around the questions their customers are asking, when they are using their service. Not “We need a portal,” but “How do I find out x?” and “Where can I pay for y?” This was a first step in getting the web team and the business to think in the same way about problems.

By first understanding your customers, you are then better able to define the problem and work through possible solutions. This thinking also underpins the Government Digital Services Service Design Manual, which puts the discovery phase, understanding your users, front and centre - indeed their first design principle is “Start with needs* (user needs not government needs)”

Getting an organisation to think in this user centric way is no mean feat. Often, web teams have been exposed to this way of thinking first, because the nature of the web has already forced them to respond in that way – and in many ways, it is their responsibility to bring the rest of the organisation along.

I know this is easier said than done. I have been there, and the temptation to tell everyone else why they are why their ideas are so, _so_ wrong, when they ask for yet another “portal just like Amazon” is sometimes very strong. However, just taking one step back, and getting people to think of the questions their users are asking when engaging with a service, is better way to start.

It’s not just the organisation that needs to ask questions

As the web team you should also turn this method inwards. When we looked at the questions our customers were asking they were “Why can’t I have the portal I’ve asked for?” and “Why are the web team making this more complex?” Working out how to answer those questions is the first step the web team can make in helping the organisation understand how they tick.