Visual Studio Code: Bringing UX and engineering together

I gave one of the short talks last night at UX Glasgow (https://uxglasgow.co.uk/). I really enjoyed listening to the other talks and Bobby King’s wearables exercise was great fun too. It was a great way to interact with other people at the event and was refreshingly different.

Last night I talked a little bit about how the UX and engineering teams work together on Visual Studio Code (our newly released cross platform, lightweight editor - https://code.visualstudio.com/). We follow an Agile process and I was asked afterwards if I could write a little bit more about this as finding a good way to get UX integrated into an Agile process can be a challenge.

I don’t think that we have reached nirvana yet but on the whole, what we do at the moment seems to work. To explain what we do now, it might help to describe what we tried to do in the past and how that failed. It might also help to understand that our team is distributed geographically between Redmond (USA), Edinburgh (Scotland) and Zurich (Switzerland).

Back when we started working on Visual Studio Online Monaco (our browser based editor which was the precursor to Visual Studio Code) we initially thought that it would not be possible for the UX team to design an experience in the same sprint that the engineering team would implement it. It wasn’t that we had tried this and found that it didn’t work, it just seemed obvious to us that it couldn’t work. How wrong we were…

Anyway, to begin with, we thought that the best thing to do would be for the UX team to work on a design in one sprint and then have the engineering team implement that design in the next sprint. That way we would have enough time to work through most of the design issues so that the engineering team had something solid to implement.

We were very conscious of not simply ‘throwing stuff over the wall’ once our design was complete. So we made sure that we interacted regularly with the engineering team while working on our designs. We would meet at least once a week and share what we were working on and listen to feedback.

Then once our design was complete at the end of the sprint we would meet and present our designs to the engineering team.

And then our designs would get ripped apart. We would hear lots of valid and well reasoned objections - “Have you thought about this?”, “This won’t work, it can’t be done”, “That doesn’t seem like the best way to do this” etc. It ended up feeling like we had to defend our designs from attack, rather than sharing them. We were on the defensive and indeed, before some of these presentations, we would even discuss what the main objections might be and how we should respond. This didn’t feel like we were one team, working together.

It wasn’t that the objections were unreasonable. In fact, they were more than often really good objections that helped us improve our designs. But because they meant that the designs needed reworked, that meant we had to spend the next sprint on the next iteration of the designs and the engineering team would spent the next sprint on something else, rather than implementing our original design. And at the end of the next sprint, we would repeat the process.

It wasn’t fun and we weren’t making anywhere near as much progress as we wanted so we had to change how we worked.

Why did it take until the end of the sprint when the design was complete to hear the detailed feedback from the engineering team? The problem was that while UX and engineering were working on different things during the same sprint, each time we met to discuss what we were working on, the discussions were superficial at best. We were each focused on different objectives. It was only when the engineering team and UX team were focused on the same objectives (implementing this design) that we had a richer and more meaningful conversation about the design. But this happened at the end of the sprint. How could we make sure that these conversations happened during the sprint?

What we had been doing was what is euphemistically called a ‘staggered sprint’. It’s really waterfall in disguise I think. We were kidding ourselves thinking we were being agile. We had to instead think about ways we could build a team focused on delivering the same outcome in each sprint. We had to face our fears and see if we could design and implement an experience in one sprint.

As we learned, key to making this work is carefully defining what we are going to do in one sprint. It’s all about small batch sizes. We had to be careful about scoping what could be done in the time we had. We were constrained both by what could be implemented and what we could design. But whereas before these had seemed like constraints that would needlessly hold us back, it turned out that they actually helped us. We were able to focus on tight, well defined outcomes. UX and engineering were very clear on the desired outcomes we wanted to achieve. We didn’t have to try to design everything before we could start implementing anything. We could start small and grow from there.

At the start of the sprint, we have our planning meeting where the whole team discusses and reaches agreement on what we are going to work on in this sprint. Then we get working.

For the stories that UX and engineering will work together on, we discuss what we are going to build. We talk about the customer problems that we want to solve (often these have been identified in previous UX studies and other forms of feedback that we have received) and different ways we might solve these problems. We might walk through some quick rough mockups that UX has created or some quick prototypes that the engineering team has. From these discussions we generate a list of action items that we need to do – UX needs to detail out some aspect of the design for example, while engineering might need to build some back end service that the experience depends upon.

We meet frequently during the sprint and discuss progress. Since we are all focused on the same outcome, we have rich conversations about what we are doing. We learn quickly about what is technically feasible and why it is important that the experience be designed this way. We work together as a team because we are focused on the same outcome.

This way of working is a lot more fun than how we began. We don’t get defensive, we don’t have a ‘them and us’ situation – it’s not UX against engineering. We are all working together on the same team.

One of the challenges though is keeping an eye on the bigger picture, making sure that all of these little steps we take in each sprint are driving towards an overall vision of the product and the experience we want to build. We aren’t completely there yet but we are making use of Lean Customer Development to increase our understanding of the customer, the problems they have and the outcomes that we think our product will deliver. As we develop our skills in this area, we think that we will be able to use this to better shape the direction of the product so that the small steps we take in each sprint lead to a great end to end experience across the whole product.

Comments

• Anonymous
  May 12, 2015
  That's my experience of working with the MCS guys in Reading. A recent project went very well and delivered over and above what was intended due to this close integration. For many organisations (not development houses), the difficulty is recognising that there is a difference between engineering and UX. In many cases UX and wireframes are created by a 3rd party externally and just presented to the engineering team at the start of the project. Having seen this model in action, I have to say, it's how all modern app development should be done.