Creating Better Products Together. UX And Engineering Working In Harmony

Nikola Nevin at UXDX Community: Dublin. Video: https://www.youtube.com/watch?v=Suy9ggxHDyM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Who we are and what OpenJaw does

[00:00:10] Nikola: My name is Nikola. I'm a software engineer, as was just mentioned there, and I'm the technical lead of the OpenJaw digital experience team. And Mcgarrett[?] is our product owner, product manager, of the OpenJaw digital experience team also.

[00:00:28] Nikola: So I'm just going to talk a little bit about the background of OpenJaw digital experience. We set up this unit two years ago in OpenJaw. OpenJaw was basically an Irish founded company with 350 employees and with six offices around the world, and our main platform was typically a back end as a service platform. But two years ago the company decided to introduce digital experience, so we set up this team.

[00:00:57] Nikola: We have 30 customers around the world, mostly airlines, airline companies, and loyalty companies in the travel industry. So it's an e-commerce platform for travel companies. We're enterprise software. We sell our technology to travel companies and then they use it to sell their products to consumers, so it's B to B to C.

[00:01:21] Nikola: So what we're here to talk to you about today is UX and engineering, the structure of our teams and our organization, and our journey, how we got to that organization, and to discuss some of the things we've learned over the last two years while trying to figure out the system that works best for us. And then at the end we can have some question time.

[00:01:41] Nikola: So this image is kind of everything, joke, and her team. Often you get designers kind of feeling like the engineering team views them as just artists painting pretty pictures, handing them over and expecting them to be created into these fully fledged applications. But as a UI engineer you kind of get the same feeling from back-end engineers sometimes. They see you like you're just slapping CSS on HTML and making things look pretty, but it's a more complicated process than that. And so UI engineers and UX designers often have a natural affinity in that way, I think.

How digital experience is structured

[00:02:23] Nikola: So Mcgarrett[?] is going to talk about the structure of digital experience at OpenJaw and how we are set up.

[00:02:29] Speaker 2: Great, thanks. Yeah, so just for you to understand how we structured our team. We actually don't have UX design in house in OpenJaw at this point in time, but as Nikola said, we have a team who are familiar with, engineers and so on, who are sensitive to design. But we actually have a partner in Dublin who's Frontend.com, and we've been working very closely with the team there, Frank[?], Antsy[?] and Clayton. So they're kind of our extended team, and they provide interaction design, UX research and some UI developer consultancy and accessibility, because they work with a lot of different customers, different projects.

[00:03:11] Speaker 2: So we've been working on a kind of lean UX model. So it's a bit interesting, it's a bit different. It's supposed to be, in a smaller type company we weren't able to hire a full UX team from the ground up and just start off with like five or ten UX people, and I just felt it wouldn't be good to bring one or two UX designers into a company where they were so heavily outnumbered, because we're a very engineering heavy organization. So what we did was we partnered up with Frontend, and it's been really good, and now we have one UX designer in our team in house and we're starting to build up our in-house capabilities.

[00:03:46] Speaker 2: So that's the backdrop to this story. And then just about our own team, so this is our crazy bunch. We're very good at doing the da cymbals[?], so we're practicing a lot. We have eight React engineers, a product owner and a tech lead as well, and our three extended family UX designers.

[00:04:11] Speaker 2: So what we've been working on together with our, I suppose, insourced designers from Frontend.com and also from our own in-house team, is to build this responsive web app that sits on top of what's called the T-Retail platform, which means travel retail, and that's an e-commerce platform as I talked about. So it's a responsive application, a single source code, and as Patrick just talked about, it has to do all those things, accessibility. And we then offer that as a product to our customers who can rebrand it.

[00:04:43] Speaker 2: So with the additional challenge of rebranding, we have our own design system, within every customer we work for is their design system. So it's really complex to try and deliver a product that can be themed for every big airline, loyalty company around the world, and also still remain responsive and accessibility compliant. So Nikola is going to talk now about our journey and how this experience has gone for us.

When design and engineering are two separate processes

[00:05:11] Nikola: Yeah, so when we started out two years ago we were a very small team. I think it was just myself and Mcgarrett[?] in the beginning. We got more and more people as we went along. But in many applications I've worked on previously, the UX and the engineering processes are often considered completely separate processes with their own separate results. So if you think about it, even if your design team and your engineering team are both using an agile methodology, the outcome is still kind of waterfall, because your design team have to produce designs which are then passed on to the engineering team which have to produce a working application at the end. So designs are usually finalized or brought to a high fidelity standard before they're passed on to the engineering team.

[00:05:52] Nikola: And as Mcgarrett[?] was saying, we're building an e-commerce platform that allows you to rebrand, reskin to suit your brand, but it's also built on top of a lot of hotel suppliers, car suppliers, things that are quite old and are very resistant to change. We also have to take into account the fact that we are building one application to fit many different screen sizes. We're not building an independent screen for each possible thing. So we had a lot of considerations to make there.

[00:06:26] Nikola: And what we found, when we received high fidelity prototypes on the engineering team, we were running into all sorts of information problems. Like the hotel details page had a lovely list of all the features with your hotel, wifi, free breakfast, all that kind of stuff, but the information we were getting back from our supplier had that with each room. So we couldn't highlight that at the top of the page. So we had to find a way to work around it and kick the designs back to the designers to work out a solution to this. So we've got this big blank space at the top of the page and then we've jacked in a load of extra information to each result, and it just didn't look pretty.

[00:07:01] Nikola: Another problem is that we were getting in designs that work perfectly on mobile but then had a completely different HTML structure when you look at the desktop designs. And because we're building one application that's a huge problem for us. We had to go with maybe the mobile version first, which didn't look as great when you code the desktop version. So there was a lot of back and forth and kicking back to the very start of the process again.

Sitting in on the low fidelity designs

[00:07:26] Nikola: So this is kind of the process we worked on and started to work with us. Because we were such a small engineering team at the beginning, we were able to sit in on the actual design sessions, and we sat in on the low fidelity wireframes, the top left here. We started at that point, and we were able to decide based on the structure of these wireframes: is it responsive, is it going to work from mobile to desktop, tablet, all the iterations in between that, do we have that information in this place at this time on this page that we are looking at right now?

[00:08:00] Nikola: And this meant that we were catching all these issues really early on in the flow. We were able to resolve them with the designers then and there before moving on to high fidelity, which is a longer process where they may look a lot nicer and more complete. So we would work on the low fidelity wireframes together, the development team would go off and create a first prototype, get the functionality working, make sure the suppliers were all working, put it in front of the product owner, make sure it met her criteria. The designers would then be producing the high fidelity designs which we would apply on top and release a finalized feature. And that worked pretty well for us.

[00:08:35] Nikola: We also had a greater understanding of the overall user experience that Frontend were trying to provide for our application. So we had a lot less confusion. We weren't just receiving designs and trying to understand the flow that they were going for. We'd been in the room, we had asked all the questions we needed to ask and we understood what we were trying to deliver.

[00:08:53] Speaker 2: I might just add to that. As Nikola said, the iterations was what really kind of saved us as well, that we worked more to iteration. To be able to accept a low fidelity implementation of the feature very early, and the team were given a lot of freedom to make decisions, and then that would inform our designers to be more aware of the different states and scenarios that can arise. So instead of designing for a perfect situation, you're designing for a more realistic one. So we ended up then taking three or four iterations to actually get it right. So it was a bit more patience, but it also made the development team have a lot more insight.

[00:09:31] Speaker 2: Yeah, more freedom and insight to get it right, instead of trying to get it perfect on the first go. Incrementally we would actually have a second chance to get it right.

[00:09:42] Nikola: And one thing I was hugely worried about going into this process is, when you get designers and developers in a room together it can kind of turn into a battle of opinions, or a lack of understanding can come across as criticism when that's not truly the problem. We went in with the mindset that Frontend are the design experts, we are the technology advocates, we're both trying to produce the same goal and the same result. So UX and engineering are not two separate processes, they are two areas of expertise within the same process trying to produce the same goal, which is a great application.

[00:10:17] Nikola: And the results that we saw from this: obviously way less blockers, we caught them earlier.

[00:10:24] Speaker 2: We brought this in after about six to nine months in. We were struggling a bit, so we came up with a new, it was probably a standard thing a lot of you do, but we had come from a kind of sales and marketing place, so we had created a lot of designs up front to kind of get a business case through, and there was a kind of an inheritance of these designs. So that's how this whole situation arose for us, with these kind of handoffs of existing designs to engineers to implement. So it was kind of by accident we got there, but we had to go back and just start again, and we have a good process now. We user tested our own process on ourselves, basically. So we were releasing features a lot quicker as well.

[00:11:05] Nikola: And then the last one was kind of a surprise effect. Previously you'd see engineers, I'm one of them, I definitely got frustrated with the complex designs we were getting in that just didn't fit what we were trying to build, or the information wasn't present. But the designers were also becoming frustrated because some of us were arguing whether things should be done at all as well, because we had the lack of understanding. Having that time to talk through everything at the very beginning made it a lot easier for us to reach that understanding. We were both fighting for the same goal, which is a great user experience. So we had a bit more ownership over the designs, we had a better eye for detail when it came to applying the finalized high fidelity prototypes, for example. I think it benefited us all in a way.

Problem one: speak the same language with a design system

[00:11:51] Nikola: And now, I guess that sounds all rosy and bright in theory, but how do you actually put that into practice, and what kind of problems do you come across and how do you fix them? So I'm just going to talk you through some problems that we hit and where we overcame them.

[00:12:04] Nikola: As Patrick was just saying, use the design system. It's a really, really useful tool, and a UI framework is an even better tool. There's a lot of words for design system used. I like Airbnb's term for it the most, they call it a design language system. It's a lot easier to make progress quickly if you're both speaking the same language to each other when you're in the room.

[00:12:32] Nikola: For example, this is a really simple example, but if I have Button Large in my design system and I have Button Large in my code base, myself and a designer can get in a room and talk about how we're going to improve that. We both know exactly what we need to change. He needs to go change the symbol in the Sketch file, I need to go change that React component in the code base. It's a lot clearer to both of us what we're changing and what we're talking about, and where else in the application it's reused, which is a big problem.

[00:13:02] Nikola: And from that again, we were still working this process, so we realized we kind of had a visual toolkit there for us to pick and choose from. We had already developed the hotel booking flow, and we're looking at the flight and the car and the rest of the products that we need to offer through this e-commerce platform, and we realized we don't need fully completed designs to start working on flights. For example, you have a date picker here. Why does it need to be different for flights? If it works for hotels it should work for flights. You don't want to create two different solutions for that either, because your user will be confused if you have two completely different methods of interacting with a date field.

[00:13:39] Nikola: So we started to pull together all of the common components and work ahead, get prototypes out while we're looking at the low fidelity prototypes. It saved us so much time that it took us about half the time to develop the car booking flow as it had the hotel one originally.

[00:13:56] Speaker 2: One of the really interesting things from your work in a framework like React, where you're trying to reuse components as much as you can and you're trying to educate your designers that we already have a calendar, a date picker, for example, and it doesn't really need to be different from one product to another. We're not enforcing a straitjacket. What we kind of do is, well, if you want to make it different, give us a good case, give us some research, give us some data to say this is why it needs to be different. So there is a constant flow back and forth between consistency versus good design. As Patrick said, you don't want to confuse the two, because sometimes if you force the wrong component into the wrong flow it's just convenience for a development team but it's actually a Frankenstein.

[00:14:42] Nikola: Yeah, a weird-looking...

[00:14:44] Speaker 2: Or whatever. So we kind of have to balance that. That's a constant conversation we now have, is consistency versus kind of bespoke tailoring for that particular page or flow.

[00:14:57] Nikola: And as developers you don't want to be afraid of making changes to things, so it was helpful to be able to take these pieces and understand, if you're changing it here it's also changing on hotel, which we've already completed and signed off on. We understood that these components would be evolving, and that's natural and it's okay for us to do that.

Problem two: front-load the UX and the engineering

[00:15:18] Nikola: And so the next thing is front-loading the UX designs. I kind of touched on this earlier, but if we let the designs go to high fidelity we'd already wasted too much time, and we needed to get discussing them while they were low fidelity. We needed to do multiple iterations while it was just basic boxes of information on the page, so we got them in the right structure and the information is confirmed there at the right time. So we'd go through maybe ten iterations, I think.

[00:15:47] Speaker 2: Yeah, so we'd have blocking diagrams, mental models, user flows, different scenarios mapped out, and really, really simple black and white wireframes. And then, like Nikola said, we could go ten, fifteen, twenty iterations over a very short period before we go near InVision and Sketch and high fidelity stuff. So it's all very cheap and rapid, kind of lean UX. And we found that was really good because it just became too much of an overhead constantly trying to improve the high fidelity designs too early on, and it was really slowing down our team.

[00:16:22] Nikola: Yeah, and by the time it got to high fidelity then you had buy-in from the whole engineering team, product owner, everybody involved in the process. We all agreed on what we were doing.

[00:16:33] Nikola: So the next thing is kind of front-loading your engineering. Most of what I'm talking about here is doing so much prep work that you're almost sick of it by the time it comes to actually doing the work itself. So after a lot of trial and error we found our team sweet spot is three week sprints with all these stages of refinement.

[00:16:50] Nikola: So the first one is story readiness, where the product owner or engineers in the team come to a meeting. And if it's a product owner, you're suggesting user stories and you're explaining the acceptance criteria and the team are accepting them into the dev grooming, the rest of the process. If you're an engineer, you're showing up and you're going, this is tech debt that is extremely important, we need to get this in now, and you're explaining how it's going to be done, how long it's going to take. So we have a really nice even split of tech concerns versus actual features that we're trying to do.

[00:17:22] Nikola: The next thing we do is that everybody in the team gets an even split of all of the stories. So one of us might take four, the other might take three stories, we go through them, we make sure there's detailed notes on how you yourself would actually implement this. If there's any questions we ask the product owner there, we ask the designers there. There's a record of everything as we're understanding how to do it, there's a complete record of that.

[00:17:45] Nikola: Then the entire team meets in team grooming and we all discuss the stories, and often there's new ideas and better ways of doing things than the original person who looked at it. Standard sprint planning comes next, obviously, we figure out how long it's going to take to do these things.

[00:17:59] Nikola: We have an end of sprint ceremony, which is basically, if you've worked on something cool or interesting, or even if you've just read something interesting that's coming into React, Redux or any of the other technologies we're using, you present it to the rest of the team and we discuss it, and potentially it becomes a piece of tech work to go into the next sprint. But at least we also get that time to understand new stuff that's coming into the application, because when it becomes large it's difficult to follow all of the changes that are coming in.

[00:18:25] Nikola: And then I think the most important one of all is the retrospective, because each of these events exists directly because of a problem that we identified in our retros. So for example, story readiness exists because we were starting on tech tasks and there were still unanswered questions in it, there was still acceptance criteria or edge cases that weren't covered, we'd have to kick it back to that process again. Dev grooming, where we each go through them individually, exists because our actual team planning meetings were taking so long, and having one person in the room who's an expert on that particular user story and how you'd implement it cut our team grooming sessions down in half, I think, pretty much.

[00:19:12] Nikola: And I'm not suggesting that each of these five or six events is what you should implement on your team. What I'm suggesting here is, if you have a problem coming up in your retro, create a process that you think will ease it. If it works after one or two sprints, keep doing it. That's the way you'll work out the right process for yourself and the team.

[00:19:36] Speaker 2: You might not have that at all of your companies, and all of our teams in OpenJaw wouldn't be quite as disciplined as this, but there is a really regimented process, and there's also a design process leading into that. So there's a lot of wheels moving in parallel, and it's all synchronized to a great degree. So there's a lot of sophistication there to get a six to eight week turnaround where you get features out. It's not easy.

Problem three: diversify the skills in the team

[00:20:06] Nikola: Yeah, and it's a process that's still maturing. So, diversity in your team. When we were working with Frontend, there's one guy there, he's actually a designer-developer, I can't remember which he was first, Clayton. So we used to get him in for four hours every couple of weeks, because we were coming across, like the example I said earlier, the hotel features, we had a big empty block there and we had to shoehorn them into each single room result. There were tricky little edge cases that we didn't account for in the design that we needed help with. We used to call this the Clayton Clinic. And he'd arrive in like some famous doctor and everybody would have a list of problems, like please help me, this is going terribly wrong here, how are we going to fix this? He's a very experienced guy.

[00:20:48] Speaker 2: And he works in an agency, so he's working 25 plus years in agency work, so he sees everything, all kinds of weird requirements. And it's nice having outside. It's one thing about having an agency, it gives you a fresh perspective, so they're not bought into the kind of internal view of the world and they can challenge something. So it's kind of an interesting note, there's mostly UX designers here, but don't be afraid of bringing in an agency to freshen up your thinking, to challenge existing kind of certainties.

[00:21:22] Nikola: Yeah. So obviously we needed Clayton, and when he wasn't around we were kind of scrambling on what to do and trying to make terrible developer-based design decisions. So we got a CV in one day from someone currently working as a designer who was interested in learning React and becoming a developer, and she's now a super integral part of our team. We basically have our own tiny mini Clayton on our team. So the rest of the team are helping her learn React and she's helping us understand the design a lot better. She's able to make small modifications to things. So if you notice that you're constantly going outside your team for external expertise, consider embedding that person in your team, or bringing someone in who has that expertise.

[00:22:06] Speaker 2: Yeah, and they are pretty rare, like unicorns. It's not easy to find someone who can do both engineering and UX design and Sketch and all those different things, but they're invaluable to the team.

Problem four: too many product owners

[00:22:16] Nikola: Yep. And then this might sound obvious, but this was a problem for us, because we are building one application that sells hotels, flights, cars, and there's a product owner for each of those. So our team is kind of trying to, and you're the product owner of digital experience then as well. So too many cooks, probably.

[00:22:42] Speaker 2: Yeah, we definitely ran into this trouble where we had multiple product owners feeding into a team, and you can only have one product owner. I think that was the lesson we learned. Even though they had a kind of domain knowledge gap, it just ended up in a lot of disagreements and confusion with the team and not knowing what to do. So it's definitely just one chef in the kitchen, that's all we can have, that's the model. Obviously we've got multiple teams, multiple product owners, it's fine, but one per team obviously makes sense, that's the whole nature of the role. But from our point of view, for engineering and design there's so many conversations and decisions that have to be made, and the product owner has such a huge influence on the decisions.

Problem five: differences of opinion

[00:23:25] Nikola: Yeah, so obviously those were some of the problems we came up against and how we tried to get around them. But obviously the biggest one, when you get designers and developers in a room, as unproductive as multiple product owners, is handling differences in opinion. So we got into one situation where there was just too many opinions, nobody could agree, and we'd wasted a week looking at these two very nice designs that Frontend had produced for the flight summary.

[00:23:58] Nikola: So these are two alternative versions of the same screen basically, in our responsive mobile view. But on the left, obviously it's a bit more cluttered, and the right is very clean, a nice look, which the UX design agency wanted us to use, and the left was more about what our product owner base wanted.

[00:24:18] Speaker 2: So this became a political football, and it can potentially become kind of toxic as well, like people can fall out over positioning of a tiny button, you know, and not talk to each other. We've seen this. So we ended up like six, eight weeks arguing about this, and the whole team is blocked.

[00:24:40] Speaker 2: So we can't sit around waiting on our hands forever. Nikola took it into her own hands.

[00:24:47] Nikola: So Frontend kind of told us, guerrilla test, you need to get data to back up your decision. So that's what we did. So when your experts can't agree, you need to go and defer to your users as your experts. Creators, developers, even designers, become almost super users of that application, with bias that you don't even realize you have, code blindness, because you've been looking at something for so long. And it's really important to defer to those users as experts in their own way, because that's who you're producing this application for. And it gave us a clear path forward. We went with the bigger design on the left there.

[00:25:22] Speaker 2: More information. And because we were enterprise, we can't just deploy this out fast and wait for the metrics to come in. It could take a year to go live with a customer. Some of our customers are in China, we've got like seven or eight airlines live in China, so it could be in Chinese, so the metrics you get back are going to be useless anyway, because it's very hard to test for something like this and it's very subjective, and both versions might work equally well really in the end. So like Nikola said, the most efficient thing is just go down the hallway testing it, get a sense of it, and just make a decision and move on.

[00:25:56] Speaker 2: And I suppose the big lesson first was, you can always come back and do it better the next time. It's not the final chance you get to do this button thing[?] or whatever.

[00:26:03] Nikola: Yeah, you know, you could do it again in a future version.

[00:26:07] Speaker 2: But it really became, we got locked into this one in a big way, so it's just a good lesson we learnt.

[00:26:14] Nikola: Yeah, it is. And compromise is so important. You have to kind of go through a few rounds of engineering compromising and design compromising before you build that level of trust with each other.

Wrapping up

[00:26:22] Nikola: So I guess just to finish off, the main points I'm talking about here are: leverage your design system as both the visual language, so you're both speaking the same language to each other, and a toolkit to work ahead on your functional prototypes. Iterate in low fidelity, it has a way lower cost, it's a lot quicker. Evolve your sprint process around your team specifically, the things that they're telling you are going wrong in your retros, because everyone's process is going to be slightly different. Diversify your skill set in your team if you notice that people are waiting around on other experts to come and give them advice on things. And don't spend a week arguing over really small design differences or opinions, go to your users and get definitive answers on which one you should go with.

[00:27:10] Nikola: And we're just now starting to see the benefits of this whole process. We've a way lower cost of change, we don't mind taking in brand new updates to components and rolling them out. It takes us six to eight weeks from feature definition to release, which is a new record for us. I think we have a happier team, and we have happier customers. So thank you for listening to us.