Ricardo Ortega, co-founder and head of design, Keep It Usable:  There are many elements to user experience (UX) and many skills, practices and techniques that go into it. One of the techniques we use in order to improve the end user experience is to devise personas that characterise the target users.

We research our target users and get to know them – their likes and dislikes, the software that they use on a daily basis, some of the internet sites they use, their preferred devices and much more. You can then use these personas as the reference point when designing your software.

The gov.uk websites are examples of sites that are designed around the end user and work on any kind of device using best practice. They have some good processes and techniques in place to build their website that includes a lot of research, prototyping and testing. 

There is an iterative cycle that goes on until they're really happy with the designs. Only at that point is the project handed over to the development team. But the team is what I'd call an 'agile team' – you've got the researcher, the designer, the software engineer and the project manager. That way everybody understands the project and is completely behind it.

Neil Cameron, managing director, Neil Cameron Consulting Group: So at some point do you have to take the software away from software designers and give it to the graphic engineers and user interface experts?

Ortega: Of course, but the technique is moving towards using agile teams which include the software developers alongside the interface designers, copywriters and visual designers. They're all working together. This means the designers can push the boundaries a little bit because they understand what is being built, while at the same time the developers are completely behind it.

Mark Garnish, development director, Tikit: We used to design the software first and then build the screens. Then we'd tinker with the screens and add more bits and pieces and they'd become more and more complicated. So, for a recent project we consciously set out to do things differently.

We employed a UX expert, and we did nothing except prototyping for months and months. We actually created working prototypes and this gave us a bit of a problem, because it meant that last August we were showing people the prototype to get their feedback and they didn't appreciate that there was no code behind it whatsoever. People were saying 'Fantastic, I'll have that next month', and we were months away from releasing the product because we were going to design everything before we wrote a single line of code. 

Building personas was an important part of this process and something that we hadn't really done before. We actually started referring to these people by name. I remember one of them was Lauren, who was a senior associate who worked in the litigation department. We mapped out exactly how we thought Lauren worked. We had five different lawyer personas. That helped, because then when we were actually looking at the designs we were saying things like 'Okay, so how would Lauren want to work in this instance?' 

I would have preferred, if we could have done, to have had more access to actual lawyers to discuss some of this stuff, and we tried, but that was actually quite hard.

Cameron: Lawyers from clients?

Garnish: Yes, from clients.  We had an awful lot of people that we spoke to who said 'Our lawyers would work this way' or 'Our lawyers would work that way', but we didn't actually get to speak to very many lawyers and I think that's really got to change. If we're designing software for lawyers it would be really helpful to speak to the actual people who are going to use it rather than the people who are speaking on behalf of those people.

Another key goal of this project was for the software to work across every single device. This is really important.  We also need to make our products easier to use. It is said that nobody is ever taught how to buy a book on Amazon and we need to adopt that philosophy.  We had to make the software as simple to use as we possibly could. It should be obvious what to do when you use the app. You shouldn't have to go on a two-day training course to use it. 

Cameron: Did you learn lessons that would lead you to do it differently next time, apart from getting more lawyers involved?

Garnish: Yes, we learned that the big challenge for us was to try and get every bit of functionality working across every device that people will be using.  What we did wrong was that we failed to realise how different mobile devices are from desktops. You can make it all fit, but just because you can make it fit, that doesn't necessarily mean you should make it fit, so we had to make some adjustments to make that work. If we did the process again we would spend more time thinking about the mobile experience early on rather than having to redo that further down the line. We would have also spent a bit more time recognising the fact that on desktops everybody wants to click or drag and drop, but on a tablet they want to poke it with a fat finger. They don't like the concept of dragging and nor should they, although you can do this on a tablet. In hindsight we should have spent a bit more time on this rather than leaving it to the post prototype phase, which is when we ended up correcting some of those mistakes.

Mark Mountford (pictured), applications manager, Bird & Bird: We've also been looking at how to make information available across different devices. I've been overseeing a project to provide the members of our management committee with all the information they need ahead of their meetings. We've come up with a solution whereby all the documents are bundled together and then made available for everybody to use on their iPad, their smartphone, or on their desktop.  That way they can access their papers when they are flying over for a meeting. I think you need to find areas where people are struggling and say 'Let's find something that we can do with a full user experience that's going to improve that for you'.

Cameron: Do you now have people that are exclusively going to be focused on the user experience as opposed to software design?

Mountford: Yes, because they are two completely different disciplines.  With all due respect to the UX people they are interested in maximising the design and the experience, but they're not developers and they probably don't want to be. User experience is a science, there's a lot to understand about how people interact with these devices and it's something we have to take into account.

And in the future everyone is going to want to do everything on mobiles and tablets as well as on their desktop, and they're going to want to do it in the way that's most convenient for them, rather than in the way that we have traditionally been able to dictate to them. This is a challenge for us, but we are expected now to make sure all of our software works properly across all devices. As part of this process I am looking at what technical skills my software development team need to achieve this richer experience which moves away from some traditional software methodologies and practices.

Cameron: Do you employ specialists?

Mountford: Well yes, that's me, although I'm from a software development background. But we are starting to understand that we might need some specialists in this area to help us.

There are some vendors that are starting to try to come up with an all-device, all-computer type of experience.  We do develop some in-house software but, like I suspect a lot of the firms here, we are reliant on the vendors to bring best of breed technology to us.