Hi everyone, my name is Patrick and if you're interested in
design and development collaboration, this episode is
for you. We share what is expected of
design nowadays, how to grow the fastest you can, as well as some
experiences when it comes to collaboration and how to do that
more effectively. Joining me today is Jonathan
Zia, gamer Dad and product Design director, and I love
learning from his experiences. Enjoy.
I'm really curious as to what your experience is working in a
product team, because most of the product teams I've worked
with only have one designer, whereas then with a bigger
development team. I feel like the design is kind
of the funnel for the work that needs to be done as well from a
visual perspective as well as kind of design and market
research perspective, right. You mentioned AB testing as kind
of testing your outcome and testing your assumptions, but
still we want to do enough research to make sure we're
actually building kind of the right thing before we then test
and optimize that, which is a whole lot of work, I feel like.
Have you worked with product teams where you were the only
designer, or have you worked with a designer team as well?
So I I worked in all set ups. So I I also when you talk about
you know agile and the waterfall and all this stuff and fake
agile, that's also a thing. Waterfall the agile.
But yeah I think there's there's a few different set ups There's
like the really tight tight team.
Yeah. And that's usually like one or
two designers working with a front end, back end security,
dev OPS, you know depends on the on the project or the if you
work for a client, depends on the client and then you're
really tight. So I think you you also talked
to Michael Dewey, my also previous colleague and so we
were together in in this kind of product team and we were really,
really super tight. We had really short time frames,
it was innovation project. So there was no exist, there was
nothing. You have to build everything
from scratch. And this is where you have to
really collaborate closely. And we did things like their
design pairing when we sit next to each other and instead of me
designing something fancy on my figma and saying, you know, hey,
fancy frontender, make it happen, we just said, OK, this
is the general concept, let's sit together and figure it out.
And then, yeah, I can do this, I cannot do this.
So how do we compromise this? And this wasn't really nice
exercise of finding the balance between feasibility and and
experience. So this is a really tight team
for like tight product team example that I I also you know
sit down with the back end there and understand what what is the
information he's getting what kind of AP is that he have and
and trying to see OK how do I use it in the design.
So it's actually the other way around.
This is the information we have. We had this kind of financially
heavy solution and I needed to understand what are all the
figures we can actually show and how do we arrange them and what
makes sense for the user. So that means I need to really
know what we can and cannot, you know get so I can make again my
fancy design, come back and say make it.
But this was more like a tight collaboration.
So this is of course what I prefer, right?
This is the I see it as an ideal situation but sometimes the
again going back to the scale, the big solutions you find
yourself in corporate set up. So there's a bit more
separation. So there's a design team and
there's a development team and this is this is of again, you
have the same conversations but there is a lot more of siloing
of the designers kind of work with the brand guides and with
the vision and making something they think from experience and
visual perspective is ideal. And then you say, OK, let's
start a conversation, let's bring in the development team
and discuss and see OK is this even possible?
What is the effort? And then we are starting this
negotiation of OK, if we make this, it will take us 3 sprints,
is it worth it? And this is again the, the sad
part of being a designer that you have to compromise a lot for
visibility. But yeah, so that's that's
another set up when basically you have two separate teams.
I'm trying to think if there's another one.
There is also kind of an overlapping 1, so you have
product teams. So again big, big solution.
For example, in e-commerce site you have different product teams
that they own different parts of the journey of the user journey.
Some of them own the checkout, some the you know PDP, some the
whatever. The more exploration part in the
beginning and what you have is that you get a bit of both.
So the the product team operates quite tightly.
So you collaborate a lot like I mentioned before.
But there's also like this overlapping circles between the
different teams because everybody owns a part of the
journey. You cannot work in a silo, you
have to understand what happened to the user before he came to
your part of the journey. And when you're designing
something that impacts the rest of the journey, you also need to
talk to the other teams. So in that way you get like this
overlap. So the designers are really
talking to each other, but you also in your own product team
really tight with the with your own, you know, team members and
working nitty gritty into the details.
So yeah, but still there's there's a lot of magic when you
have early stage Thai team trying to figure out things,
almost like a start up vibe to it.
Yeah, if I look back at my own kind of experiences, I've only
had the, let's say, the the product team, the one that
you're most fond of that. That's been my most experience.
I've only had ones where there was actually design agency and
since I worked at a consultancy there was also a different
company as a whole which was then feeding our team with fancy
designs in a way that we had to have those discussions of
feasibility and then duration as well when it comes to time and
investment which was very hard to work with.
So then I always got the preference of OK, having people
in the team to then work together with and have those
discussions. And I think compromise from both
ends because engineers also love some engineers over engineering
a solution and making it perfect from an engineering perspective.
And I think compromising and and having some middle ground on
both ends as well as coming from kind of a business value
creation standpoint is the best solution even though it's it's
hard to do that and to to make that happen in that way.
And and when you work with the agency, basically at what phase
were you involved? Is it just they finalized the
designs and just threw it over the fence and said what do you
think? Or was it there like a process
where they're like stage gates? We, we knew what was coming
functionally, but then they were very much involved in how to do
that visually. And we were then involved more
so at the end when they already imagined and mostly created
almost all the designs. And that was the hard part
because then we had to be like, OK, you get something and from a
development point of view you're like, OK, either you see holes
and then you have to shoot and be like, how does this work?
Then they're like, OK, we haven't thought of that.
So that back and forth would take the longest or you would be
like, well, I had something way simpler in my mind.
And then you have that discussion of, OK, what, where
are you going to go here? Are you going to go towards the
end solution or something in the middle and the product will have
to jump in between as well and make a decision at the end?
Yeah. And I think something people
forget is that we are all also users, right?
We are also, we are also consumers of our own product and
something that I liked when it happened in in in their own
clients or in a product team is that you come much earlier with
your concept and you get everybody in the team regardless
of their, you know, their role to poke at it.
And it can be from your own perspective if you're a front
end there, you would say, yeah, this is going to be difficult to
make. If you're like if you're saying
OK, this is going to be hard to cash in, like there's a lot of
information in this table. This is practical things, but
also I love it when like the security engineer says like,
yeah, I don't get this, it's not clear.
Maybe consider doing it differently cause 'cause that's
super valuable. And if I if I just say yo no it
doesn't know anything about design, I would lose a lot of
insight. So again, I'm I'm not a big fan
of the agency, working in the dark, coming in, throwing in
designs. I really like the product team
like you mentioned, but there's also ways of introducing it into
your process that you're getting the whole team on board with
your designs because sometimes maybe there's logic to to all
the designs that they made, but you were not there.
You don't. You didn't get the whole process
of how did they come up with this, so you're just judging the
final outcome. Absolutely.
And yeah, of course, of course maybe there's smart people that
made great choices, but you're kind of like, I don't get it.
That's the that's the worst part.
Are the worst situation to be in.
And you're not really empowered in that sense.
You you just like how you call it, like you're just on the
delivery side, just make it and that's that's not fun to
anybody. No, that's I agree with that.
There's a thing you mentioned about feedback, which I think is
interesting because I have the same challenge from a product
perspective. Whenever we deliver a feature,
whenever we deliver value, we get feedback from the users,
sometimes very direct, sometimes indirect depending on the the
size of the organization. But there is always feedback and
especially if you're building an internal tool for an
organization and those users are right next to you, everyone
expects their feedback to also be picked up.
And I feel like from a design perspective, it's kind of the
same, right? You you create something, you
get feedback. But I feel like it's very hard
to balance accommodating for the feedback as well as kind of
believing in your own vision and being like, no, this is For
these reasons, therefore the feedback we're not going to
incorporate in that way. Yeah.
And and this is again when you compromise, right, because well
if we had data about everything that.
Would be easy. Like I I just did a like a
redesign for for for a journey and it was amazing because we
had so much data about behaviour and so much insight about you
know where user coming from and we had both direct feedback from
users like what we call qualitative data data and we
also had quantitative. So we also saw what converts
better, where do we funnel and and etcetera.
And what it made is that basically when you design at the
end almost all your decisions are based or backed up by
something. And this is really and this is
really a unique snowflake kind of situation because many times
there's a lot of holes. Yeah, also in this case they
were holes. But on on the bigger topics,
there were quite a lot of things to support you in your
decisions. So when somebody comes to you
and say you know somebody from the from your own team saying
like, yeah, I don't like this or yeah, I think we should do this,
then you can have the conversation and say, OK, but we
have data supporting this kind of approach.
Even doing benchmark, you know, looking at 10 other journeys
that are exactly the same, you can always say they are all
wrong, right. But it does give you a sense of
saying, yeah, if we do this, this is really different from
what users are used to. There's there's more risk there.
So this, this is where where I like it.
I never say no to any feedback and always try to understand
the, the, the underlining issue that the person has, right.
So maybe you you finish something and you're quite
confident in it and somebody comes with like a feedback out
of nowhere and but it's yeah, it's always good to just try to
understand, ask why, why, why why and realize OK, they
actually have an issue with something else or they didn't
understand or they don't have the full picture.
So, yeah, but it is, it is quite rare like always we, we have a
lot of assumptions in what we do and even when we validate, even
when we go in and do you know, interviews or even try to
collect, you know, track user behavior, there's always
interpretation, yeah, and bias and et cetera.
So it's never perfect, but that's why we still have a job.
It's never perfect. So you know we need to I prove
it. I really like that you say the
the data wins right at the end of the day whether that's market
research before and then based on that you foundationalise your
assumptions or UAB test and you figure out OK, this decision
actually even though everyone think thought it wasn't going to
work, it actually made the most sense out of the data.
You have to make those decisions and at the end of the day it is
easier the more data you have I feel like.
Yeah, but. But there's still human decision
at the end. Yeah.
So even if the data said, OK, we should really go for whatever
make the font huge, right? We all love that.
Can you make it bigger? So yeah, data showed that this
makes all the users notice this. Yeah.
But then you're really isolated on one thing because once you
made all your, all your users or customers users is a tricky
word. We can discuss it later.
All your humans they noticed just that big title they forget
about other stuff so they've been they varied from other
journeys or other things they're trying to do.
So even with data you can say it's it's always, always wins,
but it's also how do you, in what context you put it in.
And this is the interesting part and this is where as a a user
experience designer you can really bring that overview of
kind of challenging and saying yes, we have the data, yes we
have your opinion, yes, we kind of know what the user is trying
to do. But let's let's look at the
bigger picture, let's analyse it a bit deeper and yeah, and at
the end you always have a stakeholder that comes in and
say like, yeah, I don't care, I just want it this way and that's
also legit. Like I feel like that is the
art. Because you from a decision
making standpoint, whether that's UX, product, even
development, you want as much feedback as you can right from
people as well as data. Yet you still want that decision
power with yourself. And at the end of the day, you
want to make a decision but still don't break any
relationships because otherwise you lose that feedback, you
might lose that stakeholder. And the more people that are in
your corner, the better it is, I think for the product and what
you're creating basically with your business.
So it's very hard to accommodate for feedback, have people feel
acknowledged even though you're saying no.
In a way I love that you're saying.
I never say directly no. I try and understand where the
feedback is coming from, because in that way you might still give
that sense of fulfilment to someone while still disagreeing
with their feedback or doing something else based on other
facts basically. Yeah, I sometimes I wonder if we
spend more time convincing each other than actually doing the
job. But I yeah, I guess that's part
of the process and what makes good product and what makes the
team work well. So yeah, sometimes you kind of
like it's really obvious and when I say obvious, it's like
based on experience it's obvious this is what we should do.
But then you have to convince a lot of people and you spend a
lot of time not figuring out the solution but just getting the
buy in on that solution and that that can be a bit again, going
back to the frustration part of yeah, why, why do we have to go
through all these loops to get it happen.
But, but buying is super important because when something
goes, goes in the funnel like when it's when you decided this
is the direction, this is solution, there's a lot of
impact. So people are going to start
working on it. It's going to be, you know,
published, it's going to be live, Users are going to see it,
interact with it. It's going to have business
impact. So so yeah you sometimes you
forget like maybe I'm just moving here to pixels but
there's so much like a snowball effect and and something nice we
had in the past is that we said OK as a designer is our job is
to make sure that when our solution comes in the hands of
developers we did all we can to ensure this is the the the
lowest risk effort you you can do.
So basically we did all we can to validate that this is a a
good idea. So when somebody is now going in
and looking at the design and trying to implement them and
trying to build that solution, yeah, they are confident that
they're not just wasting their time and that's going to be
thrown out of the window in two seconds.
And and I I like to put that in the back of my head when I, when
I go into a design process that I have responsibility to make
sure that you know, people working on this, they have the
confidence that they're not wasting their lives.
For some, Some like a whim. You know, some designer's whim
of yeah, we should do this, yeah.
Yeah, that's an interesting one. I I agree with that.
But also to play devil's advocate, there's kind of a
right time, right place for that.
When you're at an early stage and all the features matter
basically because time is at the utmost importance, then I think
that holds true. But when we're looking at kind
of a further stage in a product where you're working more
towards multiple scenarios and you're you really want to test
in production what works best. I love doing something and then
being like OK, is this actually going to matter or not from a
development standpoint? And then I have no problem
throwing it away if it doesn't work.
We had this kind of optimization in a check out and we had the
assumption together with design that OK, from a check out form
perspective we can make it easier for people to see what
data they need to fill in. So we added colours and I was
like, OK, as a guy, like there's a male percentage. 10% of males
have like an issue with colours. It's like a colour deficiency,
basically. They call it.
So yeah, I'm partially colour blind.
So it's like this is not going to work for me.
How about we also do shapes, give me a check or give me an X
or whatever. So we incorporated that as well.
And then we all of a sudden had three variants, the existing,
the new colours and the one with the icons.
And all of a sudden the ones with the icons made the most
sense out of the data. And I was like, OK, I have no
problem removing all the colour stuff even though we built it.
I built it as fast as possible to see if it would work
basically with that in mind and then the work that you create,
even if you do just a regular AB test and your new feature
doesn't actually make any difference, then I do think we
should throw that away because the simpler we have our
application, also from a tech perspective, and more code, code
is like a weight. The less code we have, the
lighter we are, the faster we can go.
Well what you're talking about is kind of like fail, fail fast,
right? And and what I'm trying to say
is that it's easier sometimes for for designers to fail fast
than for developers because there's more loops you need to
go through to make things you know live.
And for me to make a prototype, I can do it in 30 minutes and
make a really extensive prototype and just go and see if
it works or not. So there is also that in in the
mix and if if designers tell you like, yeah we don't, we don't
want to waste time on it but that's that's our job like to
do. So yeah, this is a small
example, the icon, but when you go in like a bigger feature or
bigger change, then that's going to be a lot of effort for you to
make it, to make it live right. Very true.
Yeah. And and for me will be quite
fast. So it's like unfair how fast?
Yeah, yeah, yeah. Well, but it's not, it's not the
real thing, right. There's there's a lot of tools
now to make it to fake it as much as possible but it's
different. But I, I, I of course everybody
in their own lane should try to experiment and and and basically
evolve their products as much as they can.
Sometimes you are getting caught in all this process and all this
you know everything needs to be evaluated.
You know, we need to refine it before we actually go forward
and you kind of feel like OK, I just.
Yeah. I don't have the opportunity to
just experiment and try things and just throw it into the wild
and see what happens. Yeah.
But yeah, that's again depends on the culture that you're
working in. Absolutely.
And how much you empower people in the in the team to do these
kind of things? Yeah, for sure.
I was thinking of kind of the the skill set nowadays of first
of all developers which are quite broad.
Yeah, front and back end data engineering more so.
AI especially nowadays which is kind of more booming, but from a
design perspective it's it's super broad as well I've
realised and I don't think many people realise how broad it
could be yet we might sometimes expect the world out of in a
product team. It could be one designer from a
research perspective, from prototyping to actually visual
design, and then market research and user feedback at the end.
Like all of those could be separate job in and of its own
exactly. Sometimes it's only in one
person and they first of all have a preference, they second
of all have experience. So what they're good at, And
then third of all probably want to learn a lot of what they
might not be good at or be really go deep in what they're
already good at and make that even better.
Do you feel like it's it's too much right now, 'cause I've and
it's funny, I heard that recently.
I've heard the term full stack design.
What is that? Terminology in the design world
is a topic. If I start talking about it, it
would never stop. And also I only have my opinion
and it's really funny. But yeah, I call myself a
product designer, right. If I go now to a company like
Philips, a product designer is somebody making physical
product. So it's already I'm off.
I now work for an automotive company and when I say product,
they only mean one product, the car.
So. So that's just one example that
it's also broader than just the design industry.
There's a lot of yeah trends and yeah you you have the full stack
designer, the Unicorn designer, the I can do it all and if we're
being honest there's always for every designers there is a
strong side and and areas that they need to either get support
or they are looking into doing more and this is the nice.
I think the nice thing about it is that when it's not that
harshly defined there's more chance for you to kind of
explore these other avenues. So if if I call, if I call
myself a UX designer, right, user experience, then it means
that either I do really early stage discovery and research or
like before we go into a visual design, wire framing and flow,
you know, flow, charting and all this kind of stuff.
But that kind of gives me a limitation.
But you see, even in in a UX designer there's like a broad
sense you're. Really scientific about it.
And there's like, yeah, there's people that are really, really
research, Harvey. And there are people that are
still kind of close, more closer to UI designers to user
interface designers in the sense of they want to make stuff, they
want to, they want to try it out, they want to play with it.
They can't even do a product from zero to to 100.
So I I have so many opinions about titles and I think it's
always about the person and how they frame their own expertise
in a product team. I I would say like the my
current set up is basically I'm a I'm a UX designer, but I also
do UI work and I have a whole research team support me because
it's a lot to also run the research yourself and do the
interviews, write the scripts, all of that stuff.
So I I feel like depends on the scale of the solution and the
scale of the product. You got to have support and yeah
maybe you really want to learn about running interviews.
So if you have a a researcher with you which is another type
of I don't know designer you can join them and you know take
notes and learn and and etcetera.
But you you got to have, you cannot have everything on your
back for for for bigger project. But yeah, I don't know how you
experienced it with your designers.
And many times when a designer tries to do a bit of everything,
yeah, something falls. So we cannot be good at
everything even a full stack developer cannot be good at.
Yeah, I know. I know that.
Exactly. So, yeah, but it is, it is.
It's an interesting topic in the industry and it went to a lot
you had in the past. Gooey designers and web
designers and mobile designers. And I'm like, why is it just
limited to one platform? Yeah.
So yeah, I I like to call myself product designer because it's
kind of fluffy enough to give me a chance to do a bit of
everything. Yeah, I think so too.
Yeah. I mean, from a product team, I
kind of know what a product designer would do or can do.
Yeah. I mean, especially now from a
product manager perspective, I like asking people what, what
they want to do because I feel like want is a big thing.
If you want to do something you have, I mean first of all,
passion a certain drive for it and I can enable you to do that.
From a product management perspective, I can see
opportunities and put people in the right places to do so.
Then also try and learn kind of what their experience is.
So what they, what they've already done in the past, what
they might be good at in that way.
And I try and accommodate and leverage that to whatever we
need to do and if I see there's holes in there and then it
becomes those are kind of the challenges we need to overcome.
So also for design, right now we have a very large, I would say
development team which needs to be needs to be fed with
basically work. And the organization is more and
more I feel like more organizations I work with which
are software heavy, really rely on market research and design
and are very design driven. First of all, I think that's a
really good thing, right. We we cannot just exactly as you
said, the time investment to create software if it's the
wrong thing is a big investment. So we try and do enough research
to make sure we're building the right thing and then still we
can experiment and see how to tweak it.
But at least we know everything is feasible, right We do our
best to do so. Then it becomes a bottleneck if
you have only one person kind of feeding the development team in
that. And then there's still a
preference of let's say I have a person that loves to do most of
the research perspective and their balance in what is
feasible is different or their appetite for what is feasible is
different than from either the business or the development
team. And then we have to manage that.
I feel like that is that might be the current situation I'm in,
whereas the bigger team you have, the more work kind of
needs to be there because more work can be created.
So then the funnel basically, which is the design team that
gets smaller and smaller and more narrowing that way.
Yeah, this is actually a rare occasion that the designer is
behind development. Like usually the designer is
like quite fast to create a lot of concept or a lot of ideas and
then that's being fed quite, you know, quite a lot.
So you're in a luxury. Or that designer, maybe you
feels the pressure, but he or she feels the pressure.
But yeah, it at least there's the, the the firepower to make
it happen. Yeah, but I do recognize what
you're saying and you always have to decide where your focus
are. We early stage, we need to learn
more about what we're building. Are we kind of like in the
middle? Is it about like what is the
critical features that we need to add?
Or is it again the more later stage of really small
informations of of refinements and each one of them has their
own challenge and and kind of different slices of the pie of
the time you need to invest. But yeah, it's always, it's
always better to work with more of your kind around you, you
know? That's how we are.
We're stronger as a as a as a triad, absolutely.
And and the same for designers. Like it's it's, I find it really
hard to be a solo designer and just work in isolation.
But how many? How often has that happened?
Because I feel like that happens more often than it should.
Wow. It's it depends.
But yeah, in IT, it happened in in in my career, yeah.
But I always found ways to to bring other designers closer and
collect feedback and etcetera. So even you know we work as part
of a company. So if if you're an agency or if
you're a consultancy, yes, maybe you find yourself in a product
team alone. But then there's other product
teams in different clients or different areas of the
organization. So you do need to find your,
your, yeah counterparts. Kind of like, who can I ask
feedback from? I I cannot design more than two
hours without getting somebody else to look at it.
I I feel weird. It's kind of feels like what
what am I doing here? I'm just, you know like a cow
eating their own. That doesn't make any sense.
So yes, I always call in somebody.
I even talking to somebody, like not giving them.
They don't really need to give you like the most crazy in
feedback or insights, but you just need that collaboration.
So when you when you're finding yourself isolated, there is ways
to reach out to others. Now what you refer to is
actually doing the work. And yeah, if you're alone doing
the work, then it's also a lot of prioritizing.
And what worked for me is that I know there are things that are
low risk, so like core features or things that you know by doing
quick benchmark just looking at the competition, I know all of
them have that feature. So I'm like OK, I'm going to
reduce. I'm not going to invest time in
researching that. There's low risk.
I don't need to validate. I will just make that.
Then that goes to the development team they have, they
have enough to run with and then I can really take the risky
areas of the product and explore them or the more innovative
things and and that's also a way to mitigate that time
management. But you always start by OK, this
is low hanging fruit, Let's just get this done and then I don't
have the pressure of. Time.
Figuring out what to do. Yeah, 'cause research takes so
much time. I know how how how many people
know. But just getting So first of
all, you need to write the, yeah, kind of definition of who
you want to interview, right? I'm just talking about the
qualitative in this case. So you need to explain exactly
who you want to interview, right?
Define your your persona or define your target audience.
Then you need to somehow find those people, right?
And then you need to book their time.
People are busy. They don't have like, so it's if
you're if you're if you want to get like eight people to talk
to, it's going to take you two weeks to go to schedule them.
Yeah. And then you need to write the
script of what are you actually when I ask them, you know and
you need that to be refined a few times because when you write
it first time, it's super biased.
You just ask do you like this feature?
Yeah. I really like this feature.
Do you like. So you also need to have some
time to process your own questions, yeah?
And then if it's also there is like a visual materials, there's
a prototype, or you're using your current website, or you're
using the current existing app, you need to prepare that as
well. So that needs to be in place.
And then the really annoying thing is that when you're done
with the whole interview, you have all these great insights.
They are all stuck in a table somewhere.
You need to actually distill them.
You know, you need to actually summarize them and make them
visible to others. Like if you did a research and
everything is stuck in your head, that's useless.
Next time somebody else comes in, they don't have the record.
And that also takes time. So yeah, that was just my way of
saying, yeah, research takes time and sometimes you you,
you're kind of finding yourself at the end.
OK, A classic thing is that a stakeholder says, like, yeah, we
should do this. And you're like, OK, we need to
validate. It's like, no, this is obvious.
We should just do this. You're like, OK, but let's,
let's run a test. It's like, OK, fine.
And then you done the whole test, the whole thing I just
talked about, right? It's two weeks of waiting.
There's two weeks of processing. And after a month you come back
and you said, yeah, you're right.
And then I told you so. So why did we do the test?
You know, why did we interview all these people?
Yeah, yeah. It's it's risk versus reward.
I feel like and I'm I'm really curious in this kind of suite of
let's say creating a product from a design perspective as
well as from a software perspective, when do you
involved in software engineers because you said you already
like that kind of dev development, pairing session for
example. But I feel like I'm also biased.
I feel like if I were to be at the research side, I would also
gain valuable insights in understanding whatever we're
doing here. Yeah.
I'm I'm I'm on your side on this again in in more tight teams I
had the whole team members they can join the interviews and
basically as a note taker. So they're in the background.
They're not visible to the to the interviewee and they can
also ask questions like hey, he just said this weird thing can
you ask him And I'm I'm getting a text message of like saying OK
this is an interesting question from my front tender, let me ask
that. And it really gets them in the
mindset of what we're trying to do.
So even when they are now we're discussing a new feature they
say, Oh yeah, I remember when we interviewed David, you know he
said that so this is really critical, but I actually think
he meant that he wants this feature.
So can we tweak it. So you're getting all that cycle
and this is perfect, but it's it's again, it's about of time
investment and return on that so your your team members can write
code or they can sit and listen to somebody.
Bravo about a feature. So it depends how stressed you
are. Yeah.
Talking to you as a product
manager, yeah. Yeah, no, I was thinking like I
I don't want to choose four people.
Yeah, it's it's really hard. If I don't choose four people
and everyone all of a sudden decides we're going to do 4
hours of interviews, then yeah, we don't have much time in the
in the day left, basically. There's also recordings, right?
So you can also look at recordings afterwards or that
you make sure the designer and kind of present the results and
collect questions or even even from the script phase.
So before you go into the interviews, you kind of present
to your team. This is the questions I'm going
to ask. Is there anything else you guys
want to, you know, ask about? That can also be a way to kind
of get people involved. I like that a lot.
Yeah. In general, the closer you are,
the better it is. It's like a yeah, there's no way
around it. I I mean, I fully agree.
It's just, yeah, from that product side, it's really hard
because I feel like everything is like risk versus reward and
trust. Because if I if I do enable
people, I trust them to do their best and stuff like that and
everyone has trust by default. So then it's just a risk versus
reward. How much do we get based on
this, based on X amount of people joining extra.
And right now we're very much OK.
The team is completely new. It's also a bigger team.
Everyone's getting used to everything.
So I feel like we need time basically we can, we can, we
need as much time as we can get also to understand what we're
doing. Because this investment right
now, especially when a team has just formed way of working,
creating value is going to return in the future as long as
the team remains stable, that's the big asterisk there.
So then I'm trying to give everyone as much time as they
can also when the domain is most complex to figure that out.
And then, yeah, I feel like I'm just postponing those risk
versus reward decisions for later on.
At some point I feel like OK, we, we do, we will need to
deliver. But right now we're still in a
very fresh domain. I really like it and and I think
a lot of product managers or team leads are underestimating
the the bonding or kind of like the investment in the culture of
a of a team. And before they go and they
start like crunch time because if you know if the team does not
trust the the designer that they're doing like the best job
they can or that they appreciate their effort.
So they they think about what they follow through, you're
going to get a lot of friction. And the same when the the
designer thinks like OK just the frontiers are just they're lazy,
they don't want to do it. It's a lot of effort.
I want these fancy micro animations.
Why are they like shooting those down.
Then you are getting like this conflict and then people will
try less and it will be less productive.
So yeah, getting that tight team feeling is, is super important,
yeah. But it's also a bit of luck, so.
It's like magic. Yeah, yeah.
You just need to get the right people in the right mindset and
yeah. Yeah, I don't know how to do it.
I I did have one kind of final train of thought because I
thought this was interesting from a product perspective.
I recently had a guest on or kind of recently bond on and he
said from a product perspective he's always been in this payment
domain because it's just interesting and he's gone from
country to country. So he's seen various stages of
payments being available to people.
And I think about myself from a development perspective right
now, most experience I have has been in e-commerce, but I do not
want to do more e-commerce like I'm I'm kind of fed up with it.
I want to do other stuff and I feel like from a design
perspective you you have these tracks where you can go really
deep into the same domain and still go from either country to
country, company to company and see various stages of that.
Take all the domain knowledge with you and leverage that in
whatever you're doing. Or like kind of my developer
experience be like, OK, I've seen that I want to go to the
automotive industry and figure that out or I want to do
e-commerce or I want to do whatever.
And which track are you? Before I say which track am I, I
will contradict you and say I think designers are exactly the
same. They don't want to stay in
there, you know, in the domain for a long time.
We we'd like to specialize. But then it's also really nice
to change industry or change like a whole different, you
know, if you if you're working on apps for five years, it's not
that you want to just keep on doing that.
Or I love it when job description says e-commerce
experience or banking experience.
Or like, yeah, if somebody worked in banking for eight
years, they don't want to do. Banking anymore?
Like that's the whole point. They're really.
Good at it. Of course they're really good at
it, but they had enough of it and that's that's the same.
So I I think in general you like to take your superpowers and use
them on different planets. I don't know if that's a good
metaphor, but but basically you want to be challenged and become
a a subject matter expert in a different field.
It's like, yeah, I did. I did banking for four years,
right? I said like, OK, no more.
I became really good at all this stuff like, you know,
understanding all the different tools that you use and already
have, OK, what do you need? You need the payment.
Fine. I know exactly the journey.
I've seen it. I did benchmark for 100 times,
but you don't want to do it anymore.
And I think the same with like e-commerce.
E-commerce is a bit more fluffy because you can find yourself
doing e-commerce for different products and you know, selling,
selling cars is really different than selling things like that
cost $1.00 on Alibaba, whatever. So there is a different
challenge. But yeah, I think we're all
trying to kind of be challenged constantly and make it
interesting. So I don't think there's, I
would like to specialize in a in a field.
There's maybe things that you find more interesting, but I
will give you a really quick example.
I had a project about a process of auditing products.
So it's it was a really weird thing.
It's basically the whole process of when something is
manufactured, let's say you you wear AT shirt that T-shirt is
says a Nike T-shirt, no sponsorship and basically that
is being made in a factory. Then that's been packed, it's
been shipped, it's been whatever, distributed to shops.
And then a client buys it. There's a company that checks
the quality of the product in every step of the way.
Oh wow. OK.
And basically I came into that having no knowledge about this
whole process, right. And I've been asked to map this
entire journey like this entire service and and basically find
the areas we can optimize. And again, I don't know
anything. And the first day I'm getting
like all these abbreviations and terminology and I don't know
anything. But that's exciting because
you're getting to learn something.
And this is like a whole different weird thing.
I didn't know, like somebody actually from a company goes
into H&M and buy a shirt and takes it to a lab and tests that
this is the same shirt that they tested in the in the factory.
That's the phrase. Yeah.
So this might sound like the most boring project ever, but
actually doing it was kind of cool, You know, it was kind of
like, whoa, this is a whole different industry I never knew
existed. So this is what's I think really
nice about our field is that we are kind of agnostic and we can
find ourselves in different clients, products, platforms,
everything. And that's really cool.
So I think I kind of answered your.
Yeah, yeah, I think so too. Lengthy way?
No. It's.
I I mean, I'm biased, right? I I agree with that, that the
domain for me is most interesting.
I do however see that like this ambiguity, you have to kind of
be comfortable in it, right? You have to have that curiosity.
Dr. You, any other person could have been like, what the Hell's
going on with these abbreviations?
Like, I I don't want to do this basically.
And they run away and they go to something they're more
comfortable at or something they've done before and they do
the whole process, for example, at Nike, Adidas or any other
clothing store, and it's the same process basically.
They'll be like, oh, how does it work here?
And oh, it's still kind of the same, maybe some slight
differences. So yeah.
Full respect, like if if this is your thing, then it's it's
whatever floats your blood exactly.
And I don't think there's a right or wrong.
I just really don't see the other side yet from a product
perspective. I do get it.
And actually from every perspective because you're so
valuable for, for an organization and with your
e-commerce example, from a development perspective, I'm
like OK, Alibaba or like selling one product or millions of
products might be kind of slightly different or get more
complex, but it's still kind of the same.
If you have a basket you check out, from design perspective it
might still be kind of the same and and different, but yeah,
from a park perspective you do know what to focus on then I
guess it's it's. So different.
Like I I worked for a glasses company, eyewear and I work for
an automotive company, right. They both have a Configurator,
you can configure your product configuring your your glasses,
right? Like you would get to you went
wild €200 you know configuring your car.
You know that's that's a different aspect and you use the
Configurator in such a different way and the functionality is so
different and the kind of reinsurances or not reinsurance
insurances that you need to have when you go into that process,
they are so different and and and even your goal is so
different. So it might be like they're both
e-commerce, right. You're just configurating your
your product, but the the the journey that gets the user into
that configuration is so different and the the amount of
times they go into that configuration, You know when you
when you're buying a car you will go probably five times and
try different things and and you know your journey is so much
bigger. When you're getting like your
iPhone cover you, you will basically go to two or three
times. Yeah, just, you know, I'll just
get the cheapest or the one that looks the best.
Yeah. So it even within like things
that might be using the same functionality, yeah, there's
there's the this challenge of of having that bigger journey in
mind. So I I find this really
interesting. Yeah, yeah, I agree with that.
I agree with that as well. That's kind of a like final,
final thought. Then from from your experience
kind of looking back, there's various avenues, right?
You have consultancies, agencies either internal at an
organization and then different domains as well.
Would you say there's like a specific place or a specific
track where designers can grow the fastest or or really get to
experience the most in kind of their learning journey in that
way? Yeah, it's an easy, easy answer
in all of them. Like, you should really jump and
try all of it. Like, yeah, I let's, let's put
it this way, let me be a bit more serious about the answer.
Yeah, I I feel like I I really try to encourage also my team
members to explore and try different things and it's also
team set up. It's also you know that you work
for a product house, you know for like a big tech company for
a small start up famous agency, unknown agency, like it's all so
different. Sometimes you just take take you
know take your chances and if you go for an unknown brand and
that brand really grows and you you win.
You know you you kind of grow really fast and you get to
experience that and sometimes you actually learn more being
like a one of of 300 designers because there's like this huge
community behind you. So yeah, I think you should just
try all of them and find what fits you.
And we all again we have it's it's it's a long life.
You know we have many years of being in our profession.
So you have the time to try it all?
Yeah, I think that's that's my only smart thing I have to say
about it. I like that a lot.
Take take all the experience with you and then maybe you'll
end up opening a restaurant in Yeah.
In the end, and that's it. Forget about your, yeah.
Thank you so much for coming on you.
This has been a real blast. Thank you for having me and it
was awesome. Cool.
Then I'm going to round it off here.
I'm going to put all your on socials below the like buttons.
Check that out. And with that being said, thank
you for listening. We'll see you in the next one.