Yo voy a comenzar con la parte difícil, dos años atrás, como Bernatis ha dicho,
yo estaba lleno de la empresa en la que estaba trabajando, y me sentí como un falso.
Me sentí como que no era un diseñador bueno, que estaba trabajando en UX, en la interfaz de
usuario, así que me sentí como que no era bueno.
Seguro con esto, lo que está pasando conmigo. Y dos años después de eso, estoy trabajando en
Asana, que es una de las principales empresas en el software de colaboración, estoy trabajando
con personas que son los mejores en su filla, estoy trabajando con Justin Rothstein, con Dustin
Moskovitz, y el equipo de diseño de Asana y los proyectos de proyectos, son todos
geniales, vienen de empresas como Microsoft, Facebook, Google, Twitter, y cuando trabajas
en el mismo lugar con estas personas, te sientes como, ¿qué estoy haciendo aquí?
¿Estoy tan pequeño para esto? Y luego te realizing la cultura que tienen, te
traes en la mente, y te sientes como que eres más de poder y que eres mejor que
te nunca pensabas que podías ser.
Entonces, lo que ha cambiado en dos años, para mí, es para ir desde el botón rojo,
para que se sienta tan grande como estoy haciendo ahora mismo, y creo que es el proceso que
el equipo de diseño del producto tiene, y la cultura de Asana, y eso efectivamente
está haciendo mis diseños mejor, y haciendo mi proceso, más fácil de ir con, tener
menos fracción, y venir con ideas más rápido, y tener más reiteraciones, entonces, ¿cuál
sabe qué Asana es, o que se usa aquí, ok, tenemos, ok, para los que no saben, Asana
es un tool de colaboración, es básicamente una forma de trabajar con un montón de personas
por el mismo tiempo, sin tener que ir a reuniones cada día, para saber lo que
tus compañeros hacen, y para saber lo que están haciendo.
Y hemos estado trabajando en equipos, desde el principio de la época, y desde que
somos monedas, estamos trabajando juntos, para viajar, y todo eso.
Y cuando Dustin y Justine se encontran en la compañía, venían con esta moto, que
suena a Crandiz, y tú topé, como, ayuda a la humanidad a thriver, y a todos los equipos
a trabajar juntos, esfuerzosamente.
Yo quiero marcar aquí, que el key piece aquí, para mí, es, trabajar juntos en equipos,
porque el equipo es lo que construye algo, es como, estamos todos trabajando en equipos
cada día.
Desde el momento que vas a la escena, con tu compañera, a comprar lo que quieras para
diner hoy, hasta el momento en el que vas a hacer un startup, y vas a intentar, para
venir con una nueva app, para cambiar el mundo.
Así que, esto es Osana, esto es básicamente, una taza básica, una taza básica de mi taza,
una taza que voy a estar trabajando, tengo los datos, y tengo, ¿cuántos de estos
datos están asignados a mí, y si necesito comentar algo, lo voy a poner ahí, si cualquier
taza, supuestamente, va aquí, va en el taza.
Así que es una gran manera de trabajar juntos, pero no estoy aquí para sellar el producto,
es, si quieres usar Osana, vas a ir a la web, es libre de 15 usuarios, deberías totalmente
verlo.
Y, la taza de este tipo, fue creada en Facebook, bueno, Dustin y Justin estaban trabajando juntos,
y se realizaron, se puso mucho tiempo en las reuniones, que no podían hacer su trabajo,
Dustin fue la ciudad de ahí, pero no podía llevar su equipo a trabajar, como querían,
y se sentía como que estaba perdiendo su tiempo.
Entonces crearon un pequeño trabajo, el manejo de Facebook, que a este día, creo que es
casi 7 años después de eso, Facebook todavía está usando, y todavía está trabajando, y no
ha aprobado.
Y, a algún punto, Dustin y Justin estaban juntos, y se realizaron de Facebook, y construyeron
su propia compañía.
Y estoy feliz de decir que estoy trabajando ahí, y es, es genial colaborar con otras personas.
Así que, si estás trabajando en el equipo, o incluso si estás en la frecuencia, intenta
usarlo.
Y si no usas Osana, trae otra colaboración.
Tu trabajo va a ser así mucho más fácil, y lo mejor de eso es que trabajemos en Osana
para construir el mismo software.
We use the software every day, so we are the first users, so whenever there is a issue
with it, we realize it first, we are the first ones, and every pain that our users might
have, we have it first, because we are using it.
And we like to say that we are a collection of peers.
We are like, in a way, a metaphor, we are like Lego pieces.
Each of us is very specialized, we have different shapes, we have different objectives and goals,
but when we came all together, we built something that makes, it's way more meaningful, and it's
way more powerful than the combination of one plus one plus one plus one.
So I like to consider as Lego pieces, also because there is no hierarchy, there is no
a Lego piece that is better than any other here, all of them are as important as the
rest of them.
And they trust each other, they need each other in order to be successful, so you have to
trust your peers.
And the peers, like the collection of peers, becomes a team, and I want to talk to you
about the product design team, that's a team where I'm working on, and the building blocks
of the product design team are the user research, the PMs.
The user research, I like to consider them as the scouts, they go outside, they talk to
the users, they check out all the trends, and they come out to us and tell us, like,
this is what people need, this is what they're demanding, and this is what's not working.
And the project managers get all that information, and then we decide which one of these features
we're going to build.
And, last but not least, the designers, that take those ideas that come from user research,
project managers, and we make them happen, we build the mock-ups, that later on, engineers
are going to make them into reality, into the app.
What I like about this relationship is everyone in this product, in this team, is at the same
level.
There is no leader that tells everyone what to do.
We decide as a collective, which is the feature that we're going to build.
And if a designer has an issue of things, like, this is not how, this is a bad UI design,
this is not going to work, it has as much power to decide as the project manager.
So the project manager is not there to micromanage everyone, to tell us what to do, they're there
to help us do our job.
So together, design and PMs, after user research tells what to do, we go out in missions, and
we end up talking with engineers, joining forces to build that feature, that idea that we have
in mind.
And that collaboration sometimes has a little bit of friction, engineering and design, as
you might know, but I'm not going to talk about that, that's the whole other talk.
So what we do is, we divide, usually, the time in episodes.
An episode for us is four months, at the beginning of the episode, we decide where we're going
to work on, and at the end of the episode, we deliver, and maybe we need two episodes
to build a feature.
So we work on that, for more than four months.
And on those episodes, we divide our forces in little teams, like monetization team or
mobile team, and usually those teams are composed by one PM, one designer, and three engineers,
that's like the base.
But sometimes we have two PMs working in a project team, and we have five engineers,
that depends on the project, no, it changes.
And this is a little bit the timeline of a project.
As I said, first we get an idea.
Sometimes it comes from the user, sometimes it comes from inside of the company.
We have a project inside of Asana, that's called the product opportunities project.
And if anyone of the company, at any given time, out of the 200 employees that we have,
goes in and says, like, I think that we should have a carousel for images, because every time
that I open an image, it opens in a new tab, and that's annoying to me.
So he will go there and create a task in that project.
And we ourselves, the rest of the employees, will vote it up or down.
And then we decide, we decide it's good enough, it has a lot of votes, we probably will build
it, and sometimes those ideas come from outside and end up in the same project.
So we have a mix of ideas that are self-proposed and proposed from the users.
And for example, we have the dashboard, it was a project that the user told us, we want
to be able to see how all my projects are doing at the same time, at a glance, in a
visual way.
And we built it up, I'm going to show it in the next slide.
So first of all, comes the idea.
The PM gets that idea, talks to user research, and come up with a sort of first briefing trying
to pinpoint what are the goals of this project.
After that, we have the kickoff, that happens at the beginning of the episode, and that's
when you gather engineering, design, and PM, we put all of them together, and we talk
about these are our goals, this is what we're going to build.
And engineers there tell them, I think I need two months to build this.
Design says, I think I need two weeks to design this in order for it to be awesome.
And the PM tries to manage that calendar, make it work.
And of course then, we design it, and we build it, this includes engineering too, comes right
here.
So this is a way of seeing it, but probably this is easier to understand.
I come from the idea that it's outside of the episode, that's when our four months period
starts, that's the end.
And it doesn't have to be this structure, it's not always cascade.
It doesn't go from A to B to C.
Sometimes it's just like this, you have the idea, and you have the kickoff.
And then engineering starts building the backend, and design starts designing, which is the
part that I'm going to talk more about, like how someone that thought that wasn't good
enough ended up at a company, and the process made me feel that I was way better than I
could be at the beginning.
So this, I love this way of working, working proudly with engineering, because it helps
you deliver faster, it helps you detect when something is not working right, before you
are at the end of the episode, and it's too late to change anything.
And let's see the example of the dashboard.
Oh, this is what I was talking about.
Users came to us, high level users, like managers, I wanted to see, how is my project doing?
How are my five projects of marketing all this coin on a sauna?
I don't want to go project by project, checking every task, and seeing if we are getting there
or not.
So user research tell us, what are their favorite graphics that people use?
What do they want to see there?
So we come up with this idea, we have the name of the project, who is responsible for
that project, the latest status update, and how are the tasks, how the number of tasks
are created in the project, and the number of tasks that are completed.
This way, the way that we build it is, first two weeks, I think I was designing this actually,
first two weeks they build a really fast, easy mock-up of this, the finias and the details
of the design was not complete, but it was good enough for engineering to start working
on it, so they got it, and then they went, okay, so we need the project title, we need
to bring the project title, the user, that it's the owner of this project, the update,
and the number of completed tasks, and pending tasks.
And they started building.
And at the same time, I went through the design iteration, after design iteration, working
with the PM to make it as good as possible.
And at some point, we even had to pivot, because we turned this into a premium feature, and
it went smoothly.
For some reason, this was one of the biggest success in the organization that we ever had
at Asana.
And what I want to center is, how did we make that design successful?
How did we work as a team to bring the best design that I could deliver, in this case?
So what we have at Asana, when you join, is the design crit.
It's scary at the beginning, because it's a way that I never worked before.
Usually in the past, what I will do is, I will go to the PM, when they give me a briefing,
and I will, this is my idea, this is what I did, and that PM will tell me, this is good,
or this is not good, you got to change this and that, and I want you to do this.
And that was a very up-down conversation, it was like, I did something, I showed you what
I did, and you tell me if it's good or not.
So I was not in a position of power, I had to defend my designs and discuss, like, no,
but this is going to work, because I know this is going to work, this, because I'm the designer.
And it wasn't like a constant battle.
At Asana, what you have in design crit is, you get into a room with all the product team,
you have some engineers in times, you have the project managers, you use the research,
and all the design, all the designers there.
So you're showing it, at the beginning it was like 10 people, now the team has doubled,
we're at more than 20 in a room, and you're showing your design, to show whatever you
have, whatever, in any given point through the project.
It can be very soon, or it can be almost finished.
So what you do is you show it, and you tell them, I need feedback on this and that.
I'm not sure about the colors, I'm not sure about the font, I want you to tell me if
this is easy enough to understand.
And then people around the room will raise their hands, and they will tell you, I think
that this is confusing, or this color is strange to me, are we using this in our style guide?
And a key point in here, while you're listening, is you realize that people are not using absolutes
at all.
This is not right or wrong.
Whenever I'm giving feedback to someone, I will tell them, I don't understand this.
This is not what I was expecting when I clicked that button, or this color makes me feel it's
dangerous, but it's not actually.
So you are there with your design on the screen, and people talking to you, your natural reaction
from the point that I was coming from, from previous experiences, is now I have to tell
them, no, this is going to work, because I know it, I'm a designer, I've been working
on this for a long time, and I know this is going to be successful.
But what you have to do in reality is you shut up, you just don't say anything, you let them
like, say whatever thing they want to say, because it's their opinion, they know what
they're talking about, but it's not an absolute, it's just someone's opinion.
The best thing, it becomes, at the same time, it's a democracy.
So say for example, somebody says, I wasn't expecting that, that button will get me to
a different page.
So around the room, if anyone agrees, we'll say plus one, which is a funny way of explaining
it.
You've got to be in the room to realize how that feels, like you hear someone saying,
I don't understand that button, and you'll say, you're here like, five people say plus
one, and at that moment you realize, oh, probably this button is not right, because 25% of people
in the room tell me this.
So meanwhile, all of this is happening, your PM is typing, all that information in a task
that will give back to you.
So you're getting a lot of information, you're just listening, you don't have to defend your
designs, because you did it, you're the designer, you're the responsible for them, and we hire
you because we know you're good enough to do those designs.
So you shut up.
And what happens afterwards, you'll get with your PM, and you'll talk like, is this working
or this button, do you think that we should follow this feedback?
And usually it's like, oh, five people said that it's confusing, probably we should change
it.
Or seven people said that this is a great background color, so we should definitely keep
that.
And what you do at that moment is, you as a designer, and probably teaming up with your
PM most of the time, you decide if you want an action on that or not.
Maybe that button takes you to a different page, but you actually want to keep it, because
you know something, you have way more background than the rest of the team, and you think,
I'm going to keep this button here, because I know something you don't.
So after all, it's like a democracy where everybody gets to vote, everybody gets to
tell you their opinion on something, but in the end, at the end of the day, you are
responsible for your designs.
If you want to be successful, you want to have a successful design, actually, what you're
going to do is probably follow the recommendation of the big part of the team.
If only one person said that that color wasn't good enough, that's up to you.
Maybe you don't have to listen to them.
Or maybe that person saw something that nobody else did, and you follow that feedback and
end up with a better design at the beginning, or sometimes you will follow it, and it leads
nowhere, and then you start over again, and you discard the feedback.
And after this process, what you do is you can repeat it over again.
You present on one given weight, you have 15 minutes to the presentation, you go really
fast, you get feedback in 10 minutes, you've got feedback about something that you've been
working for two weeks, and then you have to do whatever you do with it.
You can decide, you're free to do whatever you want, and what I want to do today so you
can see how this works, is make, like, improvise a design crate here right now, okay?
So I'm going to show you a design, and you're going to tell me what you think about it.
You can say it in Spanish, don't worry about it.
If you say anything, any opinion that you have about it, just raise your hand and say it.
And if you agree with anyone in the room, say plus one.
It sounds silly, but you'll see how effective it becomes.
So I'm going to show you the design.
The best thing of this is, since you're giving me your opinion, and it's yours and yours only,
it's not hurtful.
If this is confusing, it's not the fault of the designer, it's just confusing to one person.
So you're not targeting the person.
You're saying, I think, I feel, to me.
So I'm going to show you the design.
It's not actually a design.
I want you to create the hat that I'm wearing today, okay?
This is why I'm wearing a hat.
It's not just an accessory of fashion.
I brought it just for this.
So now you go around.
Anyone has an opinion?
Probably the guys at the back have an opinion, because they're my friends.
Yeah, no, don't worry.
Okay, we're not getting feedback about the slides.
That happens every time.
You'll show a design, and somebody will give you feedback about something that you're not
asking for.
It's like, that button is not in the design, but thank you, note it.
We're not going to do anything on it.
So come on, anyone, feedback about the hat, about the color.
Do you think it's comfortable?
Do you think it's useful?
Do you think it's nice?
It looks good on me?
Come on, don't be shy.
This is like...
Anyone?
Is the growing in the style guide of Asana?
It's actually in the style guide of Asana.
We have gradients and purple to orange, I think, and it's kind of...
Anyone else?
We need you to engage.
What's on this side?
This is...
That also happens in design create.
People will ask for clarifications.
That's when you don't shut up anymore and you explain it.
This is the Empire logo, so it's a bad thing.
Negative.
Come on, anyone else?
Fits your presentation.
What?
Fits your presentation.
Fits my presentation.
Thank you.
That's good.
Anyone agrees with that?
Do you think it's needed inside the room?
I'm going to take...
Ok, there's a plus one there, two plus ones, ok, there's three, four people, ok, good.
And there was a lot of laughter, so I get that as like a general plus one.
So I'm going to take that as like a...
The whole room thinks that this is it.
Anyone else?
Any other thing?
No?
Ok, so I just showed...
I just listened to your opinions and some opinions were not about the thing that we were talking
about and I actually talked too much, but I was supposed to like get that feedback.
And now I want to analyze that.
So you say like it's not necessary, maybe it's not necessary inside the room.
I think that everyone agrees on that.
So probably everyone agrees that it's not necessary to wear a cap inside of a room.
And maybe I have a background that you don't have, maybe I'm just growing my hair back
and I'm at a weird state between short hair and long hair, and I'm going to cover it up.
So that's a result.
So now like me, I am the one making the decision, taking like the last steps.
So I know that it's not necessary.
So the wisest thing to do will be like to take it off.
I want to follow the democracy level, I want to take it off.
But you saw how this works.
He actually never said anything about me or about this is not successful.
Like he voice it in a way that it was, isn't necessary, is this necessary?
And everyone agreed.
So me, I take the action, I analyze it, I take the action.
So what ends up happening is when you're there in those crits getting feedback, you become
part of the team, but you're still yourself.
So you're still your own person making your own choices, you're empowered to do that.
You're actually, people want you to make those decisions on your own.
Because if you don't, you're going to be like creating meetings, having more and more meetings
every week, doing more things that you shouldn't be doing, wasting your time in a room with
seven other people to make a decision, while they can give you that feedback in five minutes
and then you make a decision.
Because if we hire you, it's because we trust you, you should be good enough to do so.
And as part of that team, we work together to achieve that goal, and we don't compete
with each other, designers help each other all the time.
Developers are in the room to give you feedback, engineers do the same thing, they work together,
they help each other, no one is competing, even product managers, everyone.
And what I love about it is this democratic mix, mix of democratic and empowering.
It's like you do what you want, and at the same time you hear what the public has to
say about it in a nice way that is not offensive, it's like you did something wrong, no, that's
not the goal, that's not what we're going for.
It's like you did something, it's not working, maybe you should fix it, but it's up to you.
And at the end, we are free to do what we do best.
In my case, one of my best skills is visual design, user interface more than user experience.
So I get all the feedback from user experience, and I usually follow it, while the user interface,
I know that I'm more my own captain there, and I can make my own decisions, I feel confident
in it.
And my team trust me to do so.
And we end up winning as a team, and we learn as a team, because failure at the end, sometimes
like you do designing, it doesn't work.
Failure is not a thing, it's a factor, it's not defeat.
You fail at something, you know something that you didn't know before that, and you improve
on that.
So to wrap it up, this was pretty fast, I think, the conclusions that I got there.
So as you remember, when I started, I was fired two years ago, I thought that I wasn't
good enough, I thought that my designs were not up to the standards that I was supposed
to be given.
And I ended up joining a different company, starting with a different process that at
first felt like painful, like you're there presenting your work, and you don't get to
defend it, you get to just listen to people.
But the good thing is, the liberating thing is, you do whatever you want with that thing,
but you don't have to do anything.
So we're communicating with Clary, we're talking to each other from our perspective, saying
this is what I think, and there's no friction in there, you do whatever you want with it,
and we become more successful, and we end up being able to build bigger and better projects.
So that was it, and if you have any questions, any language, I'll be happy to answer them.
I hope you liked it.