Talking Timeline with Isobel and Jake

‍Sarah: Let’s kick off with the why: why the Timeline, and why now?

Isobel: We worked on the job page last year and decided not to rush this feature with it. Instead, we took our time. We went all the way back through years of feedback and old timeline webinars to identify what needed to be done. We didn’t want just a visual refresh — we wanted real functional changes that actually improve how you use the timeline.

Sarah: It’s a mammoth task: how did you end up piecing it together? Sometimes it’s hard to start with such a large piece of functionality looming over you.

Jake: We started with a blank canvas — literally a calendar that could scroll and zoom — and built from there. One big goal was making interaction feel really smooth. The old zoom jumped between levels; the new zoom is continuous, and it animates, and that took a lot of math. There are lots of subtle animations throughout to make everything feel nice. That was something I really think set the foundation for anything else we layered on top. Poli [formerly Product & Operations, now Customer Success] helped plan out stages of the project to keep the pieces achievable. Once the foundation was there we were able to consider what to build on top of that.

Sarah: We started the project a while back, collecting insights and conversations from customers we’d already had. After collating that initial fact finding, we started to build what we thought would be a major improvement. Isobel, tell us about the user interviews we held after the first round of build. You and I went in with certain assumptions and predictions. Did some ring true? Were there any surprises?

Isobel: There were some things that we expected, and some that we were taken by surprise. For example, the first version of the client share link had a different flow, and we found that users were missing certain things that we didn’t expect. We went back and reworked that so that it’s much clearer. Ultimately though, I thought there would be good response, and that proved correct. Everyone we showed were really positive. I wasn’t surprised by that because I think deep down I knew that the work was good, so that was really reassuring.

Sarah: Jake, from a development point of view, how did you balance the requirements from design and customers with the way that you have to consider how it actually works?

Jake: That's an interesting question. I feel like, especially from the customers, there were a lot of requests, and even more from user testing. There's a lot of different ways that people want to be able to use it. And we just can't do everything because then it’s too hard to build and too complex for the user. And I don't think people know exactly what they want sometimes!

So the first part was just getting what we already had there done, so we don't regress, really trying to nail down the basic ideas of what you do. From there, things just sort of came along that we realised were most important. For example, recently we wanted to add in better milestone functionality. And we realised, oh, there's so much of these other things we need to do to help milestones along. Rather than just this one small part of it.

Sarah: Did you have any arguments between you? About what was and what was important?

Jake: Ha, not really arguments. Isobel's too nice to argue. There was something recently where I was just like, no. Think that was working days.

Isobel: I feel like I always put everything into the design. It’s always the Peter Pan version. It's whimsical… “if it could be this, this would be great!” When naturally, I know it's not going to be quite that, but what is that saying? Reach for the stars and then you'll reach the moon? Or is it the other way around?

Sarah: I get this mixed up too, so then I'm like, which one is closer to Earth? Moon. So you try for stars and hit the moon, right?

Jake: A lot of the requests, the words of them, sound easy to do. But then when you pull it apart, some of those ones are really hard, like working days. It seems so simple. But there's so much to do for that. That's why the instant no... it could take so long.

Isobel: So, it's not arguments or fights. It's more like me being super hopeful and then Jake not beating around the bush and just saying no. And I'm like, okay. Then we just move on to the next thing. No time wasted.

Jake: But you know there were some that are super quick. I remember adding the add inline item button in to the side bar. You [Isobel] just said, “Oh, we should put this in. We need to do something.” You showed the animation, and then it was done in an hour.

Sarah: That's the thing, isn't it? We don't always know which ones are going to be quick until we think about them a little bit more, but it’s always worth a try. That's the shooting for the stars bit.

Jake: I feel like I've got better at estimating how long something will take to do after having done this project.

Sarah: Is that because you know the codebase more or because the development modernisation has given you a bit more confidence on the things that you haven’t experimented with yet? Fewer unknowns?

Jake: Maybe it's the fact that I probably had to take on a lot more with this project. At the start, there weren't hard edges like oh, we're going to do exactly this. We did a lot of refining and thinking along the way as we understood the whole scope more.

Sarah: When you closely work together on these types of projects, I'm sure that has an effect on working relationships. Do you think that working on it has changed the way you communicate, and collaborate?

Jake: Probably. I feel like we've had to, like, just message a lot.

Sarah: I mean, would you have done something like ‘that’s a hard no’ to Isobel before this project?

Jake: Probably not. I would have been a little bit nicer. Maybe, ‘these are the reasons why we can't do this’ rather than just ‘yeah that’s a hard no from me.’

Isobel: I think it's how we tend to all communicate as a product team. We all kind of know that we're working towards the same goal and we trust each other a lot. So when there is a hard no, for example, I'm not going to take it to heart because I know it’s not personal at the end of the day. That comes from a place of trust… though I already trusted Jake before timeline!

I suppose it's interesting reflection on us as a product team that we all trust that we're all working towards the best version of whatever it is that we're working on. So if there is any, I don't know, disagreements, or differences and opinion, we know that it's coming from that place of just wanting it to be the best it can be.

Jake: I do think we started out very ambitious. Let's try and get everything in that we can. Rather than hard no from the start. Let's try and do all the things. And get them in.

Sarah: The tricky bit is finding that okay, well, at this point, we do want to release it and get people using it. Then we have to be more ruthless and cut things out based on time. I was going say the same thing, in that it’s an expression of trust — probably from all the messages — that Jake felt he could just say, Nah. And you'll get it and say, “Yeah, okay. I thought I'd try.”

Isobel: You never know.

Sarah: We'll always try. Okay. So, in the process of developing and releasing, we always have to make trade-offs. What were some of the things that we had to let go of for this release that were the hardest to lose? You both already mentioned working days and therefore duration. While that’s not in this release, it doesn't mean it's not coming, but, it's its own piece of work later on.

Isobel: I think duration is a good example. I don't want to say it came from a selfish place, but because I used to build so many timelines when I was working in agency, I relied so heavily on duration as part of my job then. That’s why I wanted to put duration in there.

But it is more complicated behind the scenes as it affects more of the product. It was a moment where I had to step back and reframe and think, what's going to be better overall and try and separate myself from it a little bit. That was a good overall lesson, but it’s starting to pop up as requests again from the webinar we did last week. It's still valid, but also, I think we did make the best choice to bench it. For now. And revisit.

Sarah: It’s not completely off the table. Just this version!

Jake: Yeah. There's probably a couple of examples of that. I think it probably comes down to the fact that we did have to redo the whole thing. There is, you know, solid time spent just getting it to what it currently is. There's lots of polish and things that it does like way better, but we concentrated the additional functionality in the new client share link. Now though, we're in a position that we can easily do more after the fact and keep on improving it.

Isobel: Don’t underplay the polish parts. I think some of those changes that seem small make a big impact. Even for instance, when you're, like, resizing or drawing a dependency off the viewport and it drags, kind of chases along with you.

Jake: Oh, yeah, that's such a little thing. That is when you're actually using it, it makes a big difference to the overall experience. I actually think people aren't even going to notice that. They're just going to assume that's how it's always been, because it feels like the natural thing.

Isobel: Well, that's what they tend to say, right? The best design is in the pieces that you don't even notice because they integrate so seamlessly with your life. That’s the goal.

‍