Designing and Developing a New Product: Relentless Collaboration

Sofia Ruiz at UXDX Community: Driving Innovation & Collaboration in Product Design. Video: https://youtu.be/Y-6adFMrDsI

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.

Why the discovery phase is messy

[00:00:07] We're going to talk a little bit about driving collaboration as product designers. I'm Sofia. I'm a lead product designer at Atlassian. As you can see by the photos, I enjoy eating cake. I've been enjoying that since I was a little girl, and so that is my personal fact for you guys.

[00:00:33] Now, professionally though, I've been at Atlassian for about two and a half years. I'm really enjoying my time there. At Atlassian, we literally build collaboration and teamwork tools, so it's very fitting for what I'm going to talk about today. But also, it really aligns with what I'm passionate about, so that's cool.

[00:01:01] Let's dive into it. Designing a feature or a new product, no matter the size, in an agile company can be really, really messy. And so I decided to put here the double diamond model. I'm assuming we all are familiar with this visual. It's a visual representation of the workflow representing the design process. So we have the discover, the define, the develop, and the deliver phase.

[00:01:32] Now, what I've always found interesting about this visualization is that it seems so perfect, so pretty. Especially in that discovery phase. Throughout my career, that is not how I felt during the discovery phase. To me, it feels something a little bit like this. I don't want to say most of the time I feel this way, but definitely some days. Me and my researcher always laugh about this. We love this meme.

[00:02:09] To me, the discovery phase is super messy. It can be stressful at times, but it's also the most rewarding.

Collaboration is up to you

[00:02:20] So how do we come out — oops, sorry — how do we come out victorious out of this messy phase, to be able to achieve our goals and get success in the project? To me, the most important thing that will get us closer and faster to success is relentless collaboration.

[00:02:42] Talking a little bit about collaboration itself, I don't have to tell you what it is. We all know what it is. But what I do feel is that when we think about collaboration, we tend to think, "Oh, it's the other person. They're not good at collaborating." Or, "It's them. It's not me." To me, collaboration is 100% up to me, up to you, and it's a skill that I think it's important to hone in on and really pay attention to as part of our work.

[00:03:15] And to me, it's not just only about designing software. As designers, I believe it's part of our role to also design collaborative ways of working that will get us closer to our shared outcome and keep us sane in the process.

[00:03:29] Just a little bit about Atlassian values here, which is something that I've learned while working at Atlassian. Atlassian has four core values. You can go to their website and check them out if you're curious. But my favorite value that frames the work we do is: be the change you seek. So if there's one outcome I want you all to leave from this preso with, it's that it's really up to you to drive collaboration and change in your work every day.

[00:03:58] But what can we tangibly do as product designers to drive design collaboration? I'm going to talk about two points. First, about embracing ambiguity, and leveraging our craft to drive collaboration.

Embracing ambiguity

[00:04:16] Starting with embracing ambiguity: lack of clarity is your opportunity to set and influence the direction. It is also one of the fastest ways to drive collaboration. And yes, ambiguity can be super uncomfortable, but it's the opportunity that we have for growth. So embracing it allows for flexibility, adaptability, and the ability to consider multiple perspectives. And also, there is no better way of building trust with your teammates than sitting all together and saying, "I have no idea what this is, but let's figure it out together," and being vulnerable together.

[00:04:56] Now, this might be a little bit of a spicy take, but just as an example, something that especially young designers do in their careers is sort of relying too much on other teammates to provide that direction, especially in the discovery phase. To me, product specs, really detailed product specs, can be detrimental to driving collaboration. I really don't think they help. Also, don't make me sit in front of a long document written by a single person in isolation. This really takes all the fun out of the discovery process, and nobody likes to collaborate in front of a Word document.

[00:05:43] So don't look toward your product manager or product owner to provide all the answers. Shifting to a mindset of embracing ambiguity together will accelerate the discovery process. Consider meeting more frequently, use other tools such as whiteboards. The point is that all questions can get answered in real time. Stakeholders are included from the very beginning, and people feel more comfortable with the direction.

[00:06:11] And just as detailed product specs can kill the mood, so do detailed roles and responsibilities. In order to move fast, you're going to have to let go of hard boundaries of what your role looks like, or what you think you're responsible for versus a product manager or a researcher or an engineer. This is especially true in the discovery phase. Of course, as you go along and you start to have more clarity in building the product, not so much. But in the discovery phase, just leaning into this ambiguity — the point is that everyone is welcome.

[00:06:49] Everyone should be included in the early kickoffs and collaboration sessions. All perspectives are good. All perspectives are valued. Ensure, for example, that your product manager knows that you don't expect them to have all the answers. Ensure your engineers feel like they can bring their perspectives to the table, not just about technical constraints, but about design, about components, about the flows. And ensure everyone has a chance to be heard.

Create something first and take the lead

[00:07:19] Be empowered to ask for what you need to be successful, but don't ask as if it's another person's job or responsibility. Create something first, whatever it is. Just create it, share it, and get feedback. And this goes hand in hand with my favorite Atlassian value that I was talking about: be the change you seek. It's important to have the awareness of what and when to ask your manager and cross-functional leaders exactly what you need to be successful at your job. But before you ask, and especially if you think that ask may traditionally fall under somebody else's role, create something first. Take the lead.

[00:07:59] At Atlassian, I don't work for Jira or Confluence, by the way, the most well-known products at Atlassian, but I work for a tool that aggregates data. So every time I need to make a mock, I need data, fake data. I can't tell you how many times I've stopped myself on Slack and deleted messages on this exact same situation. "Oh, I think the PM should give me the data." Doesn't matter. Create the mock, use fake data. Use whatever data you have in hand. It doesn't matter if it doesn't make perfect sense. It doesn't have to be perfect.

[00:08:35] The point is that you now have something to show, and it's a starting point for a conversation. You made something out of nothing, and the cool thing is that now you put that in someone else's court. People will feel more inclined to collaborate because you didn't call anyone out. You took the initiative. And also remember that everyone is busy, so help yourself by helping your team by taking the lead.

Leveraging our craft to drive collaboration

[00:09:08] The other point I want to talk about is leveraging our craft as designers to drive collaboration. As designers, it's our job to master visual communication and to use this as an effective tool to drive collaboration. So when the team is staring at an empty canvas, you've got the upper hand.

[00:09:32] And how do we do this? We do this by visualizing. As soon as you can, start visualizing. Move away from writing a long document, or in my case, a long Confluence page. When I started at Atlassian, I thought the way to give visibility to my work was to write a document about the work that I was about to do in Figma, or whatever design tool of your choice. Don't do that. Just go straight to the visualizations. Even when you're out of ideas, when your team has no sense of the direction, start visualizing.

[00:10:07] And it doesn't have to be low-fi in the discovery phase. I know that a lot of designers like to use more low-fi designs when landing on the direction. Do whatever is comfortable to you. Personally, I like to use mid to low-fi designs. I think it shortens the feedback loops a little bit. But use a whiteboard, use whatever tool, as long as it's a visual tool.

[00:10:33] And I recommend starting this process on your own. The most important thing is for you to not take too long. Don't take more than 10 minutes on a particular screen. If you really cannot think of anything, really start little. Draw on your intuition. You will always have some type of idea of what the experience is calling for. But if you're blocked, just keep going. Move on to the next thing. Don't get stuck in one thing for too long, because the important thing is to gather feedback in real time as soon as possible.

[00:11:12] Have a session with your cross-functional team, and use these collab sessions to jam on ideas, refine direction and scope, and get feasibility checks with your triad partners. And the important thing here is to make sure that you document your decisions. How many sessions and workshops you lead will depend on how big the feature is — or if it's a new product, there will obviously be more — or how many people are involved: more people, more sessions. But the important thing is that these decisions are collectively documented somewhere, in case any other stakeholder needs visibility into why certain decisions were made.

[00:11:54] If applicable, provide options with all the designs you make. I like to say that three's a good number. The way we do it at Atlassian, we work with a framework called good, better, best. Good is the design that if you had to ship it tomorrow, you would be okay with it. You'd be like, "Yep, this is a good design. This is a good experience. I'm confident that it covers all the pain points for customers, and it looks and feels right."

[00:12:21] Best is pushing it a little bit further. So you make it a little bit better — sorry, that's better. And now, best is your crazy idea. Best is what you think we could do if we had all the resources and all the time available. Your best should be a design where the first reaction from stakeholders is like, "Whoa!" A little bit scared, but that then turns into excitement. And I think it's really important to always provide these options when you're presenting any type of idea, any type of design, within the discovery phase. It will shorten the feedback loops. It would get people talking. And it can inspire more and better ideas.

[00:13:10] And interesting as well, I would also suggest you visualize the not so great ideas. I can't tell you how many times I've been in meetings and everyone is talking about what they think the best thing is. Everyone in their head has their own idea or construct of what we should be doing. And right there I'm just in Figma, and then I'm like, "Wait, do you mean this?" And straight away, it's like, oh — when you visualize the idea, you don't even have to explain. People then know that maybe that's not the best course of action. So obviously, you don't always have to mock up all the ideas that come up within the group, but if you feel that the idea that's being pitched is not the right way to go, this is also your chance to demonstrate that to the group.

Record your demos and decentralize communication

[00:14:03] To shorten the feedback loop and reach a wider audience, I would also recommend to always record your demo or your prototype and share it as widely as you can. So after having one of these cross-craft sessions, once you have designs to show, you can make a demo and record it. Now, as well, a shameless plug to Atlassian: what we use at Atlassian is a tool called Loom, which is essentially like an internal YouTube. So you can record your demos, you have your little face at the bottom of the camera, people can comment on it, and it can be shared.

[00:14:40] This is great to not only showcase your work as a designer to secondary stakeholders, but also great to enable collaboration with team members in different time zones. So for example, at Atlassian there's a huge team in Australia, so it's really handy to just be able to send a video and be able to shorten the feedback loops and align quicker.

[00:15:06] And yes, of course, when possible, always do a prototype. Again, rely on your craft and your superpower. The more interactive, the more impactful your idea will be.

[00:15:19] And last but not least, decentralize communication as much as possible to drive maximum collaboration. What I like to do is I kind of stop relying so much on sending private instant messages. So whatever tool you use, either a team chat or Slack, what I started doing is creating a channel for my particular project. There we talk about the work or share the work, but the point is that everyone who participates on the project or is interested in the project can access and see all communications. And obviously this gives visibility to every effort the team is making toward the shared goal, and ensures everyone is aware of the discussions.

[00:16:10] So collaboration and success is definitely up to you. And your superpower to achieve this is the ability to make ideas tangible. The best part of this for me, and the reason why I enjoy what we do so much, is that nobody can stop you, because nobody else in the team has the skill that you do to be able to visualize. So when you think the idea is not the best, visualize it. Nobody can stop you also from visualizing what you think is the best idea, and thinking divergently. So that will be my main advice for you, for all product designers there. That's it. Thank you so much.

Q&A

[00:16:58] Host: Thank you so much. Yeah, that was awesome, Sofia. Some of the stuff, it seems like it's common sense until it's actually crafted in a well-presented manner, then it makes a lot more sense. So yeah, great job on that. We do have a few questions from the audience. We have three minutes to go through them. Bill, you want to take the first one?

[00:17:22] Bill: Yeah, sure. First, just a quick comment. I really loved your presentation. And one thing I'd like to say is I love hearing about other companies' and teams' frameworks, especially in product design. To me, that's really important, and things that you learn from these that I'm going to take to my team, like good, better, best, because we don't really do that and I think that would be such a fun, interesting thing to introduce. So thank you for that. Okay, so I'm just going to go with the first one, and it is: does Atlassian use the double diamond, or which framework?

[00:17:53] Sofia: Atlassian has started using their own framework, but it is essentially a double diamond. I think we call it make, explore, discover. So it was the same thing. But as we're developing products faster and faster, the phases become almost together at times. But I would say it's the same framework overall.

[00:18:22] Bill: I don't understand why we always do that. We make our own version of the same thing.

[00:18:26] Sofia: Yeah, it's the same. It's the same. You have discovery is messy, finally you have an answer, and you just have to make a lot of product trade-offs to make sure you reach the deadline.

[00:18:42] Bill: Okay, let's jump to the next question. How do you balance detail versus no spec without crashing?

[00:18:51] Sofia: That's a good one. I would go back to my own advice, which is: over-communicate. And as well, I just want to say, product specs and detailed product specs, I think they're really useful. But what we have found more successful, at the project that I've been at, at least at Atlassian, is having that decision register instead of a detailed product spec. So once you're starting to build, you already know the direction, but you really need to give a detailed document, especially for the engineering teams, to know exactly all the edge cases and things like that.

[00:19:30] Sofia: A detailed spec is useful, but before that, having a decision register I find a bit more useful. You're collaborating together, you document the decisions you've made and the questions that might come up. That sort of serves already as a high-level product spec. And then of course, when you're building, you have this detailed thing with all the edge cases laid out. But I think that balance works well.

[00:19:59] Host: I have a little bit of a follow-up, because I've dealt with this before too, and I'm curious if you have any advice on how you build trust to go without requirements in these discovery phases.

[00:20:12] Sofia: That's a good one. I don't know: be transparent, show up, and just bring people into the process with you. I think when people understand what you're doing and they can see you doing the work, they know that you will sort it out. They know that they don't have to provide all the answers. We've had so many discussions with our PM team as well, because it's always like, "Oh, we feel that the PM is really hoarding the discussion." But when we started talking, from the PM side they were like, "We're stressed because we feel like we need to have all the answers, and so you need to give us time."

[00:20:53] Sofia: And so it was like, "No, we can do it all together. I can help you."

[00:20:59] Host: Exactly.

[00:20:59] Sofia: And we can come to the same conclusion, but 10 times faster. So I think that's why it's so powerful to really collaborate really closely, really intensely at times, and visualize, because each person in the team has different ideas of what they should be doing. And so just being able to be like, "Oh, no, I'm sorry you're feeling that way, we can do this so much faster" — it's just so powerful.

[00:21:31] Host: I love that, that's great. I think we're at time for Sofia, so let's move forward to Robert. Thank you again so much, this was great.