This is the full transcript of the fourth episode of Inherited Composition. You can read it below, or listen to the episode
Gonto: Welcome to the fourth episode of Inherited Composition. In this episode we will be talking about how to work with UX and design, from good or bad to great. We first start with Guido and me telling the stories of how design and UX has evolved, both at Wolox as well as at Auth0. During that story, we will mention some of the programs that we've had in the interactions with design and UX, and then we'll go over each of those problems, those seven problems that we will mention, and then mention some solutions for all of them. So let's start. Guido, what was your experience since Wolox was started with UX and design, and how did that story evolve?
Guido: Cool, I think it's important to give a little bit of the backstory about how design department evolved inside Wolox. So going a little bit back in time, seven years ago when the company was originally founded by seven software engineers, so that gives you an idea of how design was involved in the early stages of the company. We had no designers. So the first products that we worked on, well, we have the luxury of, you know, implementing the nice UI's. So you can imagine how gorgeous those products were at that time.
Obviously and quickly we realized that we needed to incorporate some designers, and then we realized that the UX and UI was a key essential part of the product creation process. So the design team grew, and over the years it became the first point of contact right after sales. So the team was resource-constrained, and had the responsibility of understanding the customer needs, understanding the problem the customer was trying to solve, and also help the client diverge and converge in order to elaborate the hypothesis that needed to be tested throughout research, prototyping, and defining the scope of the first MVP. But also they have to work on the UX, the application flow, and how the UI was going to look like.
They also needed some business skills, because they needed to be able to understand the domain that the customer was involved in. Remember that we are a service company, so we work with different industries. So the designer has to be flexible enough to be able to understand the customer's business. But also they have to deal with internal requirements, like for example, make presentations for the CEO, or work on the internal trainings or work on the company website, and the brand and merchandising. So as you can figure out, there was a lot of responsibilities for this small team.
Gonto: Cool. So for Auth0, the story's a little bit different, I think mostly because it's a product company instead of a software consulting. And first at Auth0, we were a really small company, and our CTO, Matias Woloski, is very, very, very design-focused. So design was included from the beginning on everything that we were doing, but at that point everything that we were doing wasn't that much. It was like the dashboard and starting with it as well as some landing pages, but that was it. As you were saying, you know, we eventually had more things like, I don't know, slides for the CEO or slides for somebody, etc.
Having said that, the company started to grow, and then something that started to happen from there is that we didn't only have, like, product needs for design, but we also had marketing needs for design for landing pages, white papers, and other things. And because there was only one design team, we were working with Product and we were having conflicting priorities. So one month, all Design was working on marketing, one month product, one month marketing, one month product, and this is where one of our first problems came, which is what is the focus of design?
From there, we actually created what we called the Marketing Engineering Team, which was a team inside marketing that was dedicated for engineering and design. However, it had a weird setup, because designers still reported to engineering even though we had, at that point, one designer that was fulltime focused on marketing. So here we had the second problem, where designers had two bosses, the head of Marketing Engineering as well as the head of Design. So if they were given like one task by each, which one did they follow and why?
And also something that we started to see here is that we only had one designer, and partly because of these conflicting things and because of other reasons, we were also starting to have some tasks that were taking a lot of time from Design. For example, building a new landing page for a feature or a new product that we were shipping was sometimes taking five to six weeks, and we needed it to be shorter, based on how often we were shipping.
So from there, we started to have a more focused Design team only working on marketing tasks. But one problem that we had in there, and we'll talk more about it, is that Design were feeling that they were order-takers. They were sort of included late in the process and they were given a spec and they needed to work on that spec.
Then again, we kept on moving around time. We then started to have a visual design lead in marketing, and then one of the problems that, as we kept on growing even more and more, was around should design be all together or split into teams? Should we have one big design org that then serves all of the functions, or should we have like one design org in Marketing, one in Product, one in Docs, etc.? And then at the same time from the product side, something that at first we didn't have product managers. So UX, like you were saying, were mostly doing everything. But then we started to have more product managers, and then as well as the growth team and my team started to talk more to customers, do user testing, do interviews, surveys, and then at this point something that started to happen is that UX were complaining that they were both included too late in the process, and they were also complaining that they were receiving a mockup, and that removed their freedom.
So based on both of these stories, our plan now is to start talking about each of these problems that we've both shared, and actually most of the problems I would say have been shared by the two of us, and then going one by one, understanding what was the definition that we did and what was the solution that we have? So the first problem that we chatted about was the focus of design. How do you guys solve that at Wolox?
Guido: Well, I guess we waited until the boiling point, you may say. Yeah, we suffer some of the same issues that you said. There was a lot of tension between the marketing team and internal tasks that needed to be done by the design team, and also working on clients' products. We were tackling these issues with the same team, and one of the symptoms was that, when their professional career started evolving and we needed to provide further, I don't know, teaching courses or lessons or spend more time doing research, they realized that working on brand and product design was a completely different career path. And again, we started having a lot of issues with the operations teams when we needed to allocate a design resource to work on a particular task. So what was more important? Like working on the company's brand or working on a client's project?
So the decision we made there was to split the design team and hire more people to work on the marketing side of the design and keep most of the team working on clients' products and, like, focus on their skills on building products and having more skills on the UX/UI side. And then eventually we came to the conclusion that inside the product team we needed to split the team even further, but we can discuss that later. Now I want to understand what you guys did.
Gonto: So for us it was really similar as well. We ended up also, we had the same problem. It was one month product, one month marketing, and we ended up deciding we need two teams, or we need two people who are specialized, one more in marketing and the other more in product. However, something that happened in Auth0 is that design, as I was saying, is something I think very important for the CEO and for the company in general. So we still, even though we have specialized team, one for marketing and one for product, the marketing team still reports to engineering and still reports to design even though they focus on marketing problems. So in this case, at least for us, it's something that's still weird, and this brings us to the second problem, which is that designers now have two bosses. So what's happening with that? Do you have the same problem where they have, like, two bosses? Or have you completely separated it and they have different heads?
Guido: Well, in our case the design team that is working with marketing reports directly to the marketing director. Obviously they share, like they know what the other teams are working on, regarding high level things. In design they share knowledge. But yeah, they report to completely different people. And I think that's a good thing to do if they want to keep their priorities in the right place. But you have to find a way of sharing knowledge, because at the end of the day, the Wolox brand is impregnated both in our branding material and also in the products that we built. So there needs to be an alignment there.
Gonto: How do you guys do that alignment? How is that working for you now?
Guido: Well, it's pretty early, actually, to tell you, because this plate that we made was pretty recent. And now that we are growing and opening offices in different countries, so we also are assembling design teams in those countries. So we are still in the process of figuring out what's the best strategy, but the design product team, they have monthly or biweekly meetings where they discuss a particular blogpost or maybe a book that somebody is reading. So they share for a couple of hours to share knowledge, and they were also experimenting on recording these meetings, because it was hard for them to get all in the same place at the same time. So they're experimenting with making an internal podcast regarding design. So we'll see how that goes. Maybe in the future we can make it public.
Gonto: Nice, I like that. So for us, as I was saying, design, even though now we have a marketing team, they still report to engineering. And something that we needed to do in there is, like, a lot of working with each of the managers. So as I was saying, something that was happening is, we had one designer that was working specifically on marketing, but she was getting tasks from the head of design that were unrelated to marketing. So there we had to work on two things. First we needed to work with a manager on, like, this can't happen, and we're happy to help, but those requests need to go through the head of Marketing Engineering, because he needs to know everything that's going on with design, and he will be the one who can tell you whether we can do that or not.
The other thing that we needed to do is, we are a remote company, but everybody's always happy to help and collaborate, but once you are more than 300, it doesn't scale. So something that we needed to do is train people on saying no. I remember talking to Varbu, [SP] who was our first marketing designer and talking to her about, every time you get asked something, sometimes you think it's going to be 10 minutes. It's never 10 minutes. It's always like a couple of hours. So by default say no, and just let them know they need to talk to your manager, because he's the one who's checking the priorities and where can we help and when we can help. So that was something that we were working on right now.
And then something ended up happening, as you were saying, is that the marketing team is more focused on visual design and brand and basically less on UX. But that's also a change we did. In our case, it was a little bit more ago, like, I don't know, two years ago or something like that. But something that I don't know what will happen in the future is, like, should we separate those teams in designs. So you were saying that Design in Wolox reports to Marketing. That's not the case for us, but I do think that we should do that in the future, but at the same time, as you were mentioning, we should have a way so that these teams can, like, interact and know what's going on with each other. So definitely happy to understand how that works for you in the future as well.
Guido: Yeah. To make things clear, the design team that works on the Wolox brands reports to Marketing, but the other team reports to the Operations team, which is the same team where Engineering reports to. And last week we made another decision to split the Design team that was working on the brand, on the Wolox brand, and make part of the team report to the internal communications team, and the other part of the team report to marketing. And we realized that we needed to do that because something that you just said.
For example, when we do the internal all-hands meeting at Wolox, we suddenly needed to prepare all the slides for that presentation and all the material that we were going to share across the office, the banners, the flyers, and then I don't know, like invitations for the after office. And particularly working on the slides required a lot of hours, because we needed to work on the speech that the CEO was going to say, align that with the vision of the company, align that with all the expectations that the employees had, and work that with the design team to show and apply the Wolox brand to that. And that took a lot of hours from the marketing team. They were not happy at all, and they needed to do a lot of work for sales. So we decided to do that, to split the internal design team in two teams, and this is something that we decided last week. So maybe in a couple months I can tell you a little bit more about that.
Gonto: Cool. That makes sense. Another problem that we both discussed together about this is that, at least for us, as I mentioned before, some of the design tasks that we had were taking a lot of time, like a landing page for a product was taking like five weeks. And for us, that was a long time, and we're still working on this problem, but I know that at Wolox you had a solution for this. So I'm curious to learn more about it.
Guido: Yeah, this is a little bit weird. It happened a couple years ago when we first realized that the design team needed to be a team as a whole. Like, the engineering team had a head of design and apply more processes to it, but at that time we didn't have a head of design. So what we decided to do was to grab one of our engineers that was working more often with the design team, and put her on top of the design team. So all the designers report to her.
So obviously she didn't have a lot of technical knowledge about design. She had a good eye on design, experience building frontend, but the good thing about having an engineer in that early stage was that she was able to apply the same methodologies that we were using to build software for the design process. So that gave designers more constraints, gave them a methodology to accommodate to, and a way to be able to trace the work they were doing, you know, have their estimates and their metrics. And constraints, I think those are the key, and it happens the same with engineering. You have to give them constraints, because if not, they tend to diverge a lot and try to perfect the design. And at the end of the day, you need to meet a deadline.
Gonto: Can you give a few examples of what was the process that you guys set up, what were the constraints, and what were the metrics?
Guido: It's the basics, like things that we were doing in engineering just like, in our case, having Trello, planning the sprint, allocate or split all the design tasks in different Trello carts, as atomic as possible, estimate them, negotiate with the project manager the amount of tasks that were going to be accomplished in that particular week, and set the right deliverables that we were going to show to the client. And that was really important, like having constant feedback from the client, but in a structured way so we can pinpoint to the right direction, because you know, clients like to give their opinion a lot about design. And sometimes it's hard to figure out what is the right design if your arguments are based on opinions.
So accommodating that with the product process where we actually tried to test our design with users, that also helped a lot. But yeah, I have to say that basically metrics too and the sprint planning was the key thing at that early stage.
Gonto: When you say metrics or sprint planning, what does it mean? Like, was the task estimated and finished on time? Or like, those were the kind of metrics?
Guido: Yeah, I think, like, seeing the errors in estimation that we were having, the amount of hours we were spending on a particular task, and how much [inaudible 00:19:02] in general.
Gonto: That's cool. I think we're starting to have some of those things. So for us, as a visual design UX, they are different. Some of the things we did for this is that, from the marketing side and visual design, something that helped speed up some of the projects a little bit is actually having more than one designer. Like, when you start having more than one and they can work together, interact, the result is better, and a lot of times it finishes sooner. But other than that, something that we're doing, like the growth team is set around doing experiments, and right now we're focusing on retention activation. So we're going to be doing experiments on the onboarding, on the dashboard, etc.
And I remember reading a software engineering book where something that it said in there is, every project has to be constrained in some way, and that can be some constraints either by time, by quality, or by number of features. So you need to pick, but everything you can't have. So something that we're starting to work on now from the growth team and UX is actually having time constrained experiments. So now we say, we're going to do an experiment in the dashboard. It's going to be on the onboarding, you have two weeks, and that's it. Because something that we fight in there is that, our design team is pixel-perfect. And I love the phrase, "Perfection is the biggest enemy of good," because you never ship anything if everything is perfect. And even more for experiments, where the idea is to keep on iterating. It doesn't have to be perfect. So that's something that we're working hard on, which is having this mentality of, it doesn't have to be pixel-perfect to be good. You can ship something much better than what you have, and then eventually iterate.
And at the same time something that I get told a lot, I have to be honest, is that the fact that design takes a lot of time is just a feeling of mine. Maybe it's true. I don't know. I don't have this magic ball, but we're definitely working on different angles to try to solve that.
Guido: Yeah, and I like one of the things that you said about, like, making designers work together. That actually also works really well with engineers, and I think in general. But I've heard designers say that a lot. They work sometimes two designers on the same client's project. So for example, instead of having one designer work on a project and another designer work on a different project, they pair and they both work on those two projects. We have seen a lot of good results after that. I'm doing even informal checks with the engineering team as soon as possible.
For example, I used to work in the floor where the design team was working. I was the only engineer on that floor, and I always kept them discussing and hearing their conversation about a particular project that they were working on, and I gave them my feedback, my opinion on how I would implement that particular features, and some constraints that they were taking into account about a particular STK or API or how a particular platform worked, because obviously I'm a nerd and a I had a lot of technical knowledge that I can share with them. And then they told me that that helped them a lot, like having those 15-20 minutes informal talk, showing me some designs and hearing my feedback was something that ended up helping a lot to the end result of the product.
So we are now incorporating those practices and seeing what's the best way of having engineers and designers get involved in the product design phase as early as possible. And also another thing is having the design sprints, like maybe at the end of each particular sprint where maybe the design allocates a couple hours to review how the engineers implementing all the screens and gave feedback, because obviously you know, you may have a good spec, but there are always cases that we're not taking into account. So sometimes what we try to do there is define a design system which is flexible enough for developers to take small decisions here and there and avoid having to talk to a designer. But sometimes they need to because a new company needs to be designed. So having these weekly checks with the design team I think is a good idea.
Gonto: That makes sense. Another different problem that we had with design is that, from the marketing side at least, they were complaining that they were mostly order-takers. Like, we were giving them a spec on, "This is what needs to be done," already with a lot of constraints, etc., and asking them to do something. So they were sort of, to them at least, included late in this process where we already have all of the order and everything defined, and we just give it to them. I know that this wasn't a full problem for you in Wolox, but something that was interesting for us is, it was mostly because design again reported to engineering.
So even though design reports to engineering, what we did is, the visual design lead is now part of my marketing leadership team. So they will come to all of our weekly meetings, our monthly meetings, our quarterly offsite, etc., and she was saying maybe she doesn't have all the answers, but she has the right questions. And also another thing that's interesting for us is that they know what's going on. They know where the new things are happening with, I don't know, demand generation, content marketing, all of the team. So they already have the context, and by having that context it's easier. Another thing that we did is we are a remote company. I remember that for events and ads, we had like, big problems, because we have the Auth0 brand, and for places where there's a lot of content that's saturated, like an event, you have a schedule of booth or ads, you see so many ads. If you follow the brand, for example, nobody will click on it, nobody will see it, etc.
So something that happened, two things, first of all, is we flew the design team, part of it, from Argentina to the U.S. so that they could meet together. And they started talking about what were their fears, what were their concerns, what things did they think weren't working and why. And by talking about those, what they realized is that they both actually wanted to do the same thing, but they were coming from different perspectives. So the person who was leading the enterprise imagination team, for example, was talking about strategies to increase the people that we get leads or increase the people [inaudible 00:25:40] or things that are needed, etc. And they were talking about being bold, bigger font size, etc., and they were thinking that design didn't want to do that, and it was the opposite. It was just lack of communication. So that's something that by flying them out there and meeting in person and discussing not just about the project, but also about the feelings, as I was saying, what are the fears, what were the things that they liked, what were the things that they were scared about, etc., that increased the team collaboration a lot.
And then the other thing that we did is prove things with data. So we did an A/B test of ads. I can actually put it on the site. I will put the slides on the site, but we have a very ugly ad, which is like a stock photo with text in white that you can't read almost, but it is flashy, it gets your attention, versus an ad that is designed using our brands, and it's statistically significant difference where it's 60% better. Sixty percent better is fucking insane. It's a lot better. So by showing this data we were showing to design, like, the ads that you're making us don't work. We're not using them.
And at the same time I remember I was talking to Ceci [SP] about it and she was feeling bad and guilty because she once asked to use the stuff. So by actually talking with this data and showing how things sometimes work or not and starting both better communication from the feelings as well as better communication from the data, we can now start to plan together. So now we're working on a new branding plan that we're going to be focusing on Q2 and Q3, and then we're going to think about how does branding plan changes for saturated channels, like evens and ads for example. So this is something that definitely started at least our conversation on these kinds of things. But at least adding them to the marketing leadership team was by far one of the best decisions even if they still report to engineering.
Guido: Yeah. In our case it was a little bit different, because early on or at least in the last couple of years, right after the sale process when we closed deal, the next team that got involved was the design team. And the problem there was a combination of, you know, communication problems and having too many responsibilities for the design team. So they were in charge of understanding what the clients said to the sales department, and then focusing on understanding the client needs, figuring out what was the best solution for the problem, try to understand how the business works, make some hypotheses, and try to validate them as soon as possible, and as cheap as possible, avoid having to build a completely MVP to, you know, test some hypothesis.
So that was taking, and obviously, you know the UX and UI. So that took a lot of time. So they were complaining a lot that, you know, products were not specified as [inaudible 00:28:45] or there were too many things that needed to be done in a small period of time. So that made us realize that we needed to split the team again. So now we are building a new business unit called a product unit. So we have product managers and product people that are only going to be focusing on product discovery, idea discovery, diverging and converging, and applying, for example, design thinking, and then the deliverable will be a much specified idea and product for the UX team to start working on the actual application flow, and obviously incorporate designers and engineers in this process. So yeah, that's something that we are working on in this Q and we are eager to scale that team, too, because we think we are adding a lot of value to our clients now. And now I think over the last years Wolox shifted from an engineering focused company, and now I see ourselves as product-focused, as a product studio, and engineering's one part of the process. But it's as important as design, as important as product. So there's no department which is more relevant or important than the others.
Gonto: This is actually, I think, a good segue to our next problem, which was the fact that UX, at least from the product side, we were talking about visual design and brand UI before, but the UX side was also complaining that they were included too late in the process and also that when they were included, they were already given a mockup which was already restricting their freedom or the things that you could do. So I think this goes with what you're talking about, like the product, engineering, and design working together, but when do you think it's a good time to include the UX in this process, and why?
Guido: I think as soon as possible. We are seeing that even having UX people talking with sales to understand how sales are pitching the company to the possible clients and how we are telling them how our process works and where skills, is really important because, you know, designers and UX-ers and also engineers have different perspectives, and that gives salespeople a lot of tools to talk with the clients, and also allying the expectations after the deal is closed. And also, in the product phase, in this phase that we were talking about, you know, design thinking and idea discovery, once we start converging, it's important to have a designer that can place some constraints and start maybe doing some mockups, like low level mockups to give something more concrete to discuss with the client. And also it's important to get engineers in that process, because they can tell you if one of your ideas is feasible or not or can be implemented in a period of three to six months.
Gonto: And what about from the product side? You're, a lot of time, doing interviews or reading, I don't know, analytics to understand what is the next feature or what are the next things you're building based on the problems that you have. Do you think that UX should be included, for example, in these calls and talking to the customers, understanding the problem? Should they be included in the next step, and why?
Guido: That's a hard question. I don't know. I don't think there is a recipe. I think it borrows a lot on the skills that the product manager has. I think it's not necessary to include the UX-ers and designers in every meeting with the client. We have that structure in different modules. So in some particular modules, UX-ers get more involved. In other modules, engineers get more involved, and sometimes businesspeople get more involved. But it's important, I think, to have a weekly check with all the people that are going to be involved in the creation process to, again, align expectations and to have feedback about what you are discussing with the client.
But again, I worked with the design team in the same floor for, I don't know, a couple months, and I think that helped us both a lot. It gave me a different perspective to understand how they were thinking about the product and how they were thinking about the software development process, and I give them also a different perspective, my knowledge, my technical knowledge, and give them more tools to understand how things are going to be implemented when they hand off their work to the engineering team.
So at the end of the day, I would say that it's all of building cross-functional teams, and maybe you have different phases where a particular team gets more involved, but at the end of the day the entire team and the entire profiles should be incorporated during the product creation process.
Gonto: And what happens when you have, like, it happens every time, like limited resources? You were saying that UX needs to be included in that process early. And okay, let's say that that's true. But now you have five projects, you have three UX designers. How do you choose when to include them? Is it, like, do you still include them early? Do you stop the project? How does that work?
Guido: We never stop the project. Now, yeah, that's tough. You always try to do the best you can, and you're right, sometimes you're resource-constrained, you don't have the amount of people that you need for the project that you are working on. I would say that at least allocate some time to have these weekly checks, at least one hour per week. So for example the product people can show what they are working on, get feedback. Getting feedback doesn't take too much time. You can do that even while you are having lunch or maybe you can invite your UX-er friend to have a beer with you and, you know, show them the things you're working on this week, and at least having that informal check is necessary. So I think it's a combination of having a structured process and building the network inside a company so the people know who to talk with.
Gonto: That makes sense. I'll stop with my harassing questions and I'll share some of my thoughts. To me it is a very interesting problem, and I don't know the full answer to it, but I do think that sometimes it gets too territorial. Like UX is talking about, we need to include it from the first step of the process because we are going to be the ones who are going to solve the problem. Product managers are, we need to talk to the customers, get the insights, create the business case, because we are going to be the ones who think about what is the problem. And then the UX team will work on the user experience.
So I sometimes think that it gets too territorial on, like, we are the ones who do this or we are the ones who do this, and I think it's something on the middle point. So to share some of my experiences, now with the growth for example, we're doing a lot of interviews, surveys, user insights, user testing to understand how to improve the dashboard or the product. And then we didn't include, for example, the UX team on the calls because they are working fulltime on other things. But they wanted to be included, but if we include them before, what happens? How will they work on another project, etc.?
And at the same time, if everybody has an opinion, you have a team of like 50 people that have an opinion, shit never gets done. So if you want to get shit done, I think it's about having a racing model where you can consult people for an opinion, but you have a well-defined person of who is responsible. That way it doesn't get that territorial.
And then another thing that happened is, again, I think a lot of people are biased. So to me, mockups are a very good way to explain a thought process. So for example, I got a lot of insights. Based on the insights, I have a thought, and that thought is hard to explain in words. So I just do a mockup to explain that. I send that to UX, UX tells me, "You don't send us mockups. We do the mockups." And I don't think that's right. To me, mockups are ways to describe how you think of the problem and how you think one of the possible solutions would be, but I don't think it restricts freedom. I think the freedom restriction is in the mind of the person who is doing the UX or design, because they feel that they are anchored to that mockup, and that's not true. It's just about sharing something.
So I think that, to me at least, solutions can come from both sides. So solutions can come from, for example, the growth team. By talking to the insights, having ideas, and then doing a mockup, some other ideas can come from the UX and design team. They do another mockup, and then from the two of them, create, like, a mix-up with the best ideas of each, or the person who, based on their racing model is set as the responsible or accountable, he or she is the one who makes the decision of what we are going to be doing. But I think that, to me, is the most important part about that.
And then when is the right moment? I don't know, because we're so resource-constrained, and that happens, I think, in absolutely every company. So would we want to invite them to all of the interviews that we do? Yes, but the more people that you add to an interview, the more hassle it is to schedule it, and maybe we take three weeks to schedule one instead of one week, and I don't want that to happen. I want that to happen quicker, but at the same time, something that I do make sure is that, even when we send a mockup, and that's like a possible solution, we also send what is the problem, what are the insights that we've got, so that it's not only a solution, but it's both a problem and a possible solution so that then UX with the problem can have their own solution.
I think the part that's wrong about sending mockups is when you only send that, and that's the only solution. And I feel that UX in general has been burned so much with that that they are scared of mockups or scared of those things, because they think that their opinion will not be valued because UX is something very new. But I definitely think that UX adds value, but again as I said on, I don't know what episode, but to me what adds the best value is diversity of opinions, diversity from the UX side, from the product side, from marketing, from growth, and then again, the responsible or accountable person will make the decision.
Guido: Yeah, I agree with that. So for me the answer to that question is, as soon as possible. Try to incorporate people as soon as possible. I like making mockups, I think because...
Gonto: I love it.
Guido: I love the designing process. I'm very shitty at making things nice and sexy, but I like, you know, building the mockups, give the designer my high level view of how the application should look like, and I always tell them, "Destroy this. Just challenge it and tell me what you think. This is just my way of showing what I'm thinking." Mockups are a tool and it's a visual representation of how the application should work in my head, but it's a starting point.
And I remember working when I was working on Sumo, part of my responsibility was, I was wearing too many hats, but I was also wearing the product hat. So when I had to give a product specification to the designer, I built most of the mockups and how all the screens should connect with each other. And I remember that that helped a lot, working with the designer, because he was remote, like several hours apart from me. And he received a mockup, he asked a lot of questions, I answered them, and then the first iteration that I got from him was pretty close to the final one. So that helped us a lot to accelerate the iteration cycle. So I will tell you that, yeah, use mockups, and everybody should use mockups. It doesn't matter what's your role. It doesn't matter if you are the official UX-er or the engineer or the product guy or some sales person. It doesn't matter. It's just another way of communicating.
Gonto: That makes sense. I think that with this we've already talked a lot. How much time are we?
Guido: Like 40 minutes, more or less.
Gonto: Yeah, I think we're done. Forty minutes is already too much time for the podcast. So thanks for listening to us, and we'll see you in the next episode.
Guido: Thanks for listening to this episode. If you want to know more about us, you can check our website, inheritedcomposition.com. In there, you'll have some of our episodes as well as transcripts of everything we said, and links to everything we mentioned. You can also follow us on Twitter, @TheICCast.
Gonto: We love feedback. We're trying to improve this every day. So if you have feedback, please send it to us at firstname.lastname@example.org. Finally, if you love the show, please leave us a review in your favorite podcast app. If you hated it, just send it to your worst enemies so that we have more listeners. Thank you.