Legacy Design Video Software Modernization

00:53 → 00:57

Welcome to yet another Marik Studios live session.

00:57 → 01:01

Once again, we are digging deep into the topic of software modernization.

01:01 → 01:05

However, today we are going to focus on design.

01:05 → 01:06

My name is Alexandra.

01:06 → 01:08

I'll be your host today,

01:08 → 01:12

and joining me are two very special guests, Yagoda,

01:12 → 01:14

our senior UX designer and team leader.

01:14 → 01:15

Hi. Hi.

01:15 → 01:16

Nicole,

01:17 → 01:20

our senior business analyst and sales representatives.

01:20 → 01:21

Hi, guys.

01:21 → 01:23

Hi. Hello.

01:23 → 01:25

How are you today?

01:25 → 01:26

Good. Good.

01:26 → 01:29

I guess the weather outside gives the Christmas vibes

01:29 → 01:33

already, so I guess the moods are set up for this.

01:34 → 01:38

Perfect. I'm really happy to have you here today.

01:38 → 01:40

Let me do some housekeeping first.

01:40 → 01:43

So today's session is going to be divided into two parts.

01:43 → 01:46

The first will be our discussion and then we'll take

01:46 → 01:49

some questions during the Q and A.

01:49 → 01:53

So don't forget to leave your questions and comments in the chat box.

01:53 → 01:55

We'll answer them after the discussion.

01:56 → 02:00

This livestream is, as the name suggests, live,

02:00 → 02:03

but you will be able to rewatch it afterwards.

02:03 → 02:07

Don't worry if you have any errands to run or maybe a dog to walk.

02:07 → 02:11

We'll be there with the recording later on.

02:11 → 02:13

So as I said at the beginning,

02:13 → 02:17

today we are focusing on design in software modernization.

02:17 → 02:21

We're going to discuss things like favorable conditions for

02:21 → 02:25

design to become outdated, the business impact of legacy

02:25 → 02:28

design and some pro tips for keeping your digital

02:28 → 02:30

product up to date.

02:30 → 02:35

Okay so I think we can move on to the introductions.

02:35 → 02:39

Yegoda, Michal, could you tell us a few words about yourselves,

02:39 → 02:42

what you do at Meric Studio and about your experience?

02:43 → 02:45

Yigoda, could you begin?

02:45 → 02:46

Sure.

02:46 → 02:49

So I'm an UX designer at Merix Studio,

02:49 → 02:53

and I work in the product design department.

02:53 → 02:56

So this is the place when we handle the interface

02:56 → 02:59

and end to end interface and user experience solutions

02:59 → 03:03

for our clients and products and their companies.

03:04 → 03:05

Thank you.

03:06 → 03:08

Hello everyone.

03:08 → 03:09

My name is Michael.

03:09 → 03:12

I work for Meric Studio as a business analyst.

03:12 → 03:15

A Business Analyst task is to navigate the early talks that

03:15 → 03:17

we have with the different companies that reach out to us

03:17 → 03:21

in order to gather and understand their requirements

03:21 → 03:24

and advise on the best steps to take in order to meet them.

03:25 → 03:28

Okay, thank you very much for the introductions.

03:28 → 03:33

So I think we can start with the first question and let me

03:33 → 03:36

make it a bit difficult for you because I want to start with

03:36 → 03:38

something kind of big and kind of philosophical.

03:38 → 03:41

Tell me, is software design ever finished?

03:41 → 03:44

Is there any point at which you can say, Okay,

03:44 → 03:45

my design is finished.

03:45 → 03:48

I don't have to take care of it anymore.

03:48 → 03:51

I would say this is the,

03:51 → 03:53

as you said, like kind of big question.

03:53 → 03:56

And definitely we would love to live in a world where the

03:56 → 04:00

design can just be ended in one day and we should and we should

04:00 → 04:03

not be worried about it ever again.

04:03 → 04:05

When it comes to design itself,

04:05 → 04:08

I think in the perspective of

04:08 → 04:12

modernization, there was there will be like a very, I would say,

04:12 → 04:17

commonly used paraller in this in this life when it comes to the design.

04:17 → 04:21

It is similar to development in that way, I would say.

04:22 → 04:26

In general, in agile and scrum approaches,

04:26 → 04:29

we love to encapsulate things and just,

04:29 → 04:33

let's say, try to close them in some in

04:33 → 04:35

some timelines in, let's say,

04:35 → 04:38

small elements that have a start beginning and the end of

04:38 → 04:39

it so we can measure them.

04:39 → 04:42

And of course, this is the same thing that we do with the design.

04:42 → 04:46

So we differentiate different phases of this design,

04:46 → 04:50

which definitely allows us to somehow say

04:50 → 04:54

about it in in a way that we think we end some phases and we

04:54 → 04:55

can move to another.

04:55 → 04:57

So this give us this, let's say,

04:57 → 05:04

feeling of limitation when it comes to the one phase or another.

05:04 → 05:08

But to be honest, I wouldn't say that design

05:08 → 05:12

should ever be be be ended in the way how

05:12 → 05:16

we understand it, because this is an ongoing process that

05:16 → 05:19

we perform in our projects,

05:19 → 05:22

in the in the in the products of our clients.

05:22 → 05:26

This is ongoing process that should be not only started and

05:26 → 05:28

ended in this visual phase as we understand it,

05:28 → 05:31

but also when it comes to the maintenance validation.

05:31 → 05:35

And generally, I would say adoption this design to to to

05:35 → 05:39

changing environment that it's basically, let's say,

05:39 → 05:41

living within.

05:41 → 05:44

So I wouldn't say we can end the design,

05:44 → 05:49

but I would say that having this idea of phases in

05:49 → 05:53

mind, we need to remember that it does not mean that the

05:53 → 05:56

whole design activity that you will need to, let's say,

05:56 → 05:59

introduce to your company should be a

05:59 → 06:03

full production work, which is, you know, creatively

06:04 → 06:06

creatively bringing to life new things.

06:06 → 06:08

It's not about that.

06:08 → 06:11

So it's not going to be inventing new design each day,

06:11 → 06:14

but it will be a process of ongoing maintenance and

06:14 → 06:18

basically keeping it up to date and keeping it fresh and

06:18 → 06:19

helping your your company.

06:19 → 06:22

So that would be my answer, I guess.

06:22 → 06:26

I don't know, Michael, how from your perspective this can look.

06:26 → 06:28

I would definitely second that.

06:28 → 06:32

I I don't think in I I don't think design can

06:32 → 06:34

be finished, so to speak,

06:34 → 06:39

meaning design is not something that you do once and you just have it.

06:39 → 06:39

Yep.

06:39 → 06:40

If

06:41 → 06:44

well, one one way you could technically end your design is

06:44 → 06:46

if you abort the mission and stop working on your product,

06:46 → 06:50

just just abort the mission, right, altogether.

06:50 → 06:52

However, if your product is live,

06:52 → 06:57

I don't think design is a a finished effort similar to development.

06:57 → 06:58

It works in a very similar way.

06:58 → 07:01

You just have to keep working on it.

07:01 → 07:05

And I think a valid point and one that

07:05 → 07:09

definitely is worth remembering is that design is not

07:09 → 07:12

necessarily constantly trying to dish out new screens,

07:12 → 07:15

new colors, new

07:15 → 07:18

information architecture, whatever it is.

07:18 → 07:22

It comprises of many different forms of activities and things

07:22 → 07:24

you need to do around your design in order to keep it

07:24 → 07:28

fresh, usable and great for your users.

07:28 → 07:30

Your users evolve, users change,

07:30 → 07:32

trends change and so should your design.

07:32 → 07:33

It's never really finished.

07:33 → 07:38

With that said, specific phases of design can be finished in time and outcome.

07:38 → 07:44

And both of you mentioned this concept of evolution.

07:44 → 07:47

But I guess that with evolution also comes aging and for

07:47 → 07:51

example in programming we have this concept of tech debt that

07:51 → 07:54

once you begin to write the code and once you write the

07:54 → 07:57

first line of code it immediately

07:57 → 07:59

begins to

07:59 → 08:03

kind of become outdated and you have to keep taking care of

08:03 → 08:07

it so as not to let it become too legacy.

08:07 → 08:10

Does the similar concept exist in design as well?

08:10 → 08:14

Can we speak of something like design that maybe?

08:15 → 08:18

Yep, I would say definitely.

08:18 → 08:21

In a way, like both software development and

08:21 → 08:22

designing of a software.

08:22 → 08:26

You know, these are the activities that do

08:26 → 08:28

not happen in a vacuum.

08:28 → 08:30

So we have, like, time around us,

08:30 → 08:34

a requirements and environment that is constantly changing.

08:34 → 08:37

We have different business objectives around us,

08:37 → 08:40

different audience expectations from our products.

08:40 → 08:45

So definitely the idea of design becoming

08:45 → 08:48

outdated in a way that it is aging,

08:48 → 08:51

but in a way that it's somehow

08:51 → 08:55

stopping us from progressing is definitely something that may happen.

08:55 → 08:58

And this is something that is happening from the day one.

08:59 → 09:00

In the case of the debt,

09:00 → 09:04

I would say in the design debt and probably take that

09:04 → 09:07

similarly, These are the definitions that,

09:07 → 09:09

let's say, sound very scary.

09:09 → 09:12

And I don't think we have like a good associations when it

09:12 → 09:14

comes to the debt in general.

09:14 → 09:17

But when it's one, I would say,

09:17 → 09:22

important thing in the regards to both of this and the design

09:22 → 09:25

that itself, it is it does not necessarily

09:25 → 09:30

need to Once you spot it in your in your organization,

09:30 → 09:32

it does not need to be an end of it.

09:32 → 09:34

You know, it's not that scary.

09:34 → 09:38

I would say more scarier is the idea of thinking that you do

09:38 → 09:40

not need to handle a bit because that's probably

09:40 → 09:44

something that should be one of the first red flags of how you

09:44 → 09:48

think about your your company and the organization of the

09:48 → 09:50

software creation within it.

09:50 → 09:53

So definitely this is a thing.

09:53 → 09:57

It is similar to the tech debt in some ways and definitely not

09:57 → 10:01

being aware of it is much more scarier and dangerous

10:01 → 10:05

than having being aware and being

10:05 → 10:07

able to spot it.

10:08 → 10:12

And are there any particular conditions that

10:12 → 10:15

make this design dev faster to grow?

10:15 → 10:20

Maybe the complexity of the product or maybe the focus on on features.

10:20 → 10:23

What are your experiences in these regards?

10:23 → 10:26

Well, definitely complexity of the domain does not end and

10:26 → 10:31

interface solutions that we use to create and to, let's say,

10:31 → 10:35

create this experience and just bring features to

10:35 → 10:39

life definitely is one condition that make

10:39 → 10:43

this design that being a bit more is easy to

10:43 → 10:47

happen because each design will become legacy in sometimes,

10:47 → 10:52

but definitely some solutions that might be a bit easier.

10:52 → 10:54

And definitely when we speak about modernization,

10:54 → 10:56

we do not have them in mind.

10:56 → 10:59

Do they might be less less

10:59 → 11:01

dangerous in that space.

11:01 → 11:03

But when it comes to the modernization and when we think

11:03 → 11:07

about the domain solutions that do not that

11:07 → 11:12

on one hand have outside and let's say external users,

11:12 → 11:15

for example clients of your business but might also have

11:15 → 11:19

internal users that being just people who you hire to

11:19 → 11:21

perform daily daily work.

11:21 → 11:23

These are definitely the places when

11:23 → 11:27

the design that is much more happened to occur,

11:27 → 11:29

I would say in this kind of condition.

11:29 → 11:32

So complexity as one of them for sure.

11:32 → 11:36

I would only add to this that if you're on a very if your

11:36 → 11:39

product operates on a very competitive market,

11:41 → 11:45

might be the case that competition will make design

11:45 → 11:50

that ramp up faster because well everyone's just

11:50 → 11:52

trying to to top the others.

11:52 → 11:55

Another thing would be to get to know your you well,

11:55 → 11:57

know about your user base,

11:57 → 11:59

your target user audience.

11:59 → 12:04

If they are if they are early adopters or people that respond

12:04 → 12:08

to trends very well, chances are they will hop on

12:08 → 12:12

to the next great thing which will only which will always

12:12 → 12:14

be that one step ahead.

12:14 → 12:18

But that's the one step behind where you are.

12:18 → 12:18

Right?

12:18 → 12:22

So in that sense you could you could easily you could

12:22 → 12:26

easily distinguish situations which that is ramped up

12:26 → 12:28

faster compared to others.

12:28 → 12:32

I'll also say that if you're in a in a stage in which you're

12:32 → 12:36

scaling your product very fast and you have a robust roadmap

12:36 → 12:40

of implementation laid out for your product and you

12:40 → 12:43

funnel all of your all of your resources and focus into that,

12:43 → 12:46

it's easy to forget that you need to tend to

12:46 → 12:49

and care for the feature set that you developed at the

12:49 → 12:50

beginning that might have been left behind.

12:50 → 12:53

So if you're in a situation which you're developing and

12:53 → 12:55

scaling the product very rapidly,

12:55 → 12:57

that is also a situation.

12:57 → 13:01

Those are the circumstances that I would say

13:01 → 13:05

contribute to your design debt being ramped up And

13:07 → 13:11

how about the business consequences of design debt?

13:11 → 13:14

Because on the one hand you said that you shouldn't be too

13:14 → 13:18

afraid of it because it's not that scary and it's natural and

13:18 → 13:20

it will occur eventually.

13:20 → 13:23

But I guess there are some consequences that can harm your

13:23 → 13:26

business if you don't react at the right time.

13:27 → 13:30

So I would say if I can take this question Jorgen,

13:30 → 13:33

I would say the consequences that I've working with

13:33 → 13:37

companies and clients the consequences that I've

13:37 → 13:40

seen could be of

13:40 → 13:42

competition nature,

13:42 → 13:45

user group nature or even internal.

13:45 → 13:48

So and with that said it's quite difficult to say oh what

13:48 → 13:50

kind of business consequences will you see if your design

13:50 → 13:51

becomes outdated.

13:51 → 13:52

It's very difficult to say.

13:52 → 13:55

Every product is slightly is at least slightly unique in its

13:55 → 13:59

own way and so the consequence your results may vary.

13:59 → 14:02

But in general, if going back to again,

14:02 → 14:03

if you're on a competitive market,

14:03 → 14:06

the consequences you see if you do not care for your design,

14:06 → 14:08

you do not maintain it and work on it constantly,

14:08 → 14:10

you see your competition sort of get ahead of you.

14:10 → 14:14

And you know that while that's not

14:14 → 14:18

like the only differentiating factor

14:20 → 14:22

taken into consideration when people are looking for

14:22 → 14:24

solutions or product digital products to use,

14:24 → 14:27

it's a contributor certainly.

14:27 → 14:31

Your user base well you know design how you know good

14:31 → 14:35

design and how intuitive and usable it is for your

14:35 → 14:38

users have a significant impact on

14:38 → 14:40

how willing they are to use your product.

14:40 → 14:44

Especially going back to the users that may be responsive to

14:44 → 14:47

trends and early adopters if they see a better solution they

14:47 → 14:49

will jump to it absolutely, right.

14:49 → 14:50

And internal,

14:50 → 14:54

I think Yagoda would know much more about that because she she

14:54 → 14:58

is a designer but internal it might be it might be the case

14:58 → 15:02

that if your product is not is your design is

15:02 → 15:04

updated, there's a lot of debt ramped up.

15:04 → 15:07

Chances are a team, a product team,

15:07 → 15:11

designers but other people as well working on it would feel demotivated.

15:11 → 15:15

For example, the motivated or feel discouraged to do their

15:15 → 15:18

best work because every time they do,

15:18 → 15:20

it it just looks like it's been made ten years ago for example.

15:20 → 15:21

Right?

15:21 → 15:24

And it it does it isn't really that sort of satisfaction

15:25 → 15:27

or like that kind of compensation for them when they

15:27 → 15:28

do the best work.

15:28 → 15:31

I know, Yagoda, would you agree with that last one?

15:32 → 15:33

Partially, yes.

15:33 → 15:37

Because definitely when we speak about this visual side of an interface,

15:37 → 15:40

which is of course our first association when I think about

15:40 → 15:43

design, it's all about visuals, then definitely

15:44 → 15:47

it is a different work working on something, you know,

15:47 → 15:50

that is contemporary and something that, you know,

15:50 → 15:53

that has been designed some time ago and might not

15:53 → 15:57

necessarily be the case and no longer to be, let's say,

15:58 → 16:00

how to say it, up to date, of course.

16:00 → 16:05

But the business consequence I see from

16:05 → 16:10

my experience in companies that we

16:11 → 16:15

had, let's say, chance to see or observe

16:15 → 16:17

in that way.

16:17 → 16:21

First, when your design becomes updated and the design

16:21 → 16:23

that for some reasons, I don't know,

16:23 → 16:26

these are different reasons as as we as we spoke already.

16:26 → 16:30

But the thing is that one of the of the symptoms that

16:30 → 16:35

will be visible is that or maybe it's not going to maybe

16:35 → 16:37

it is not going to be that visible.

16:37 → 16:41

But definitely with without up to date design,

16:41 → 16:43

there is a lacking source of true when it comes to creating

16:43 → 16:44

new elements.

16:44 → 16:48

And when we have like lacking source of true when it comes to

16:48 → 16:49

the design, for example,

16:49 → 16:52

I'm not speaking about this visual side itself,

16:52 → 16:55

but more of a wide components on how the user

16:55 → 16:59

interface elements that we are creating while, for example,

16:59 → 17:03

making some style guides or components libraries or,

17:03 → 17:05

for example, design systems.

17:05 → 17:09

So when we have this situation that we lack

17:09 → 17:13

this single source of truth that is cohesive for a whole

17:13 → 17:15

company, for a whole product,

17:15 → 17:19

then it tends to generate a lot of noise

17:19 → 17:23

quote when it comes to the product development itself.

17:24 → 17:27

When we are not able to, let's say,

17:29 → 17:34

fill our dev team with the tasks and with the

17:34 → 17:39

roadmap of work that is easily comparable to the source and is

17:39 → 17:42

basically up to date and allows them to work with their full efficiency.

17:42 → 17:45

If we tend to question too much the things that we

17:45 → 17:50

designed some time ago, this is the one of the

17:50 → 17:53

first signs that something is not right because we spend much

17:53 → 17:57

more time on discussing stuff that should be obvious

17:57 → 18:01

and that should have some already,

18:01 → 18:05

let's say, our argument background in the company.

18:05 → 18:06

Instead of that,

18:06 → 18:10

we are trying to find what is the most contemporary solution

18:10 → 18:13

and why we cannot use the thing that we were first to think

18:13 → 18:16

that would suit best for the solution for the new feature or

18:16 → 18:20

for the feature aggregate that we try to accomplish.

18:20 → 18:24

So this is in my opinion very serious business consequences

18:24 → 18:28

because this is something that you can easily miss in a way of

18:28 → 18:32

the symptoms because you will be tracking your for example

18:32 → 18:33

print velocity and efficiency.

18:33 → 18:36

For some reason it will be dropping and you will be

18:36 → 18:41

looking for the reason of it, obviously in the for example,

18:41 → 18:44

develop tickets that you prepare for the development or

18:44 → 18:47

the process that you are developing your code with.

18:47 → 18:50

But the real problem will be in the Slacking source of truth

18:50 → 18:55

that has the real origin in in the design department.

18:55 → 19:00

So this is the situation when I think companies can easily

19:00 → 19:03

lose some money and team efficiency.

19:03 → 19:08

So that would be something I would say quite important when

19:08 → 19:11

it comes to the business consequences of the legacy

19:11 → 19:13

design that we can have.

19:13 → 19:16

I'm really happy that you mentioned it because we

19:16 → 19:19

actually have the first question and it's about the

19:19 → 19:22

cooperation between designers and developers but we'll leave

19:22 → 19:24

it for the discussion.

19:25 → 19:29

And you mentioned that these business consequences are

19:29 → 19:31

serious and I totally agree.

19:32 → 19:35

So I guess our audience is wondering now

19:35 → 19:39

what's the best time to address these things?

19:39 → 19:43

I mean as soon as possible probably But if you were

19:43 → 19:47

to pinpoint some red flags or maybe the best time

19:47 → 19:51

to start thinking about modernizing your legacy design?

19:51 → 19:55

Well, one of the first, I would say,

19:55 → 19:59

and the most visible symptoms that you can notice in your

19:59 → 20:03

company is the situation when you easily spot that you

20:03 → 20:08

are not able to create or implement new feature

20:08 → 20:13

with your current design system or design solution that you have.

20:13 → 20:16

So when your style guide is obviously lacking some elements,

20:16 → 20:19

when the elements that were used in the previously

20:19 → 20:22

developed or launched features are basically not handling the

20:22 → 20:26

task well, And this is one of the first, I would say,

20:26 → 20:31

flags that you can spot to start wonder

20:31 → 20:35

maybe it's worth it to just get back to it and give it a

20:35 → 20:37

proper review and maintenance,

20:37 → 20:40

because the maintenance is a key in here.

20:40 → 20:42

Of course, we would love to

20:43 → 20:46

solve the problems as they go, as they come to us.

20:46 → 20:50

This is obviously not possible in many cases.

20:51 → 20:54

Time will not stop and wait for us to modernize our tool and

20:54 → 20:59

then just to click the play button again and be happy on the market.

20:59 → 21:00

That's obviously not it.

21:00 → 21:04

So I would say that is the most basing on our

21:04 → 21:09

experience, the most reasonable way would be to go steady

21:09 → 21:12

with each new feature, each new updates,

21:12 → 21:16

trying to do bit more work on

21:16 → 21:20

updating the the designs design solutions that we have

21:20 → 21:24

and being sure that you have a

21:24 → 21:25

proper people to do it,

21:25 → 21:28

that you have team that is devoted just for maintaining

21:28 → 21:30

maintaining it.

21:30 → 21:34

So being able to be up to date with that, not trying to,

21:34 → 21:36

as as we said before,

21:36 → 21:40

not try to encapsulate it in some time and then

21:40 → 21:41

forget about it again.

21:41 → 21:44

So I would say that was that when you are not able to

21:44 → 21:47

address a new feature or or the new thing within your product

21:47 → 21:49

with your current

21:50 → 21:52

interface solutions that you are using for that.

21:52 → 21:55

That's the first I would say symptoms for it.

21:56 → 21:57

I think that's a that's a great point.

21:57 → 22:00

I love the point about, you know,

22:00 → 22:03

style guide not being able to accommodate not allowing you to

22:03 → 22:04

accommodate new features.

22:04 → 22:06

And I I absolutely agree.

22:06 → 22:09

I would say I think this was said sort of

22:09 → 22:13

together with the question as soon as you can.

22:13 → 22:14

I would say so.

22:14 → 22:19

Well you ideally you would work on your design

22:19 → 22:21

as soon as you can or just never stop.

22:21 → 22:25

That doesn't mean you have to work on it full time,

22:25 → 22:28

employ a whole team of designers,

22:28 → 22:30

twenty people to work on it constantly.

22:30 → 22:32

That that doesn't necessarily mean that,

22:32 → 22:33

but generally speaking,

22:33 → 22:38

work on your design as soon as you can and ideally never stop.

22:38 → 22:41

There are there are more red flags I would add to this that,

22:41 → 22:44

you know, when when working with with existing legacy

22:44 → 22:49

products, when we when we first take a look at them and we

22:49 → 22:51

do not understand what's going on, right?

22:51 → 22:53

That's a red flag to me, right?

22:53 → 22:58

If I look if I'm used to looking at digital products obviously

22:59 → 23:03

and I do not I cannot figure out how things work,

23:03 → 23:05

that's typically a big red flag.

23:05 → 23:08

Another would be if for example if your users are finding

23:08 → 23:11

workarounds to using a problem, right?

23:11 → 23:14

So if you if you if you devise a set of features that's

23:14 → 23:16

supposed to be used in a specific way,

23:16 → 23:19

but then your users find a better way to do it.

23:19 → 23:23

And it becomes it becomes like an unspoken rule or a meme

23:23 → 23:27

even, like, that's that's a bad sign.

23:27 → 23:30

And so ideally, you know, when you spot these things,

23:30 → 23:32

it's absolutely time.

23:32 → 23:34

But I I see a lot a lot a lot of times, right?

23:34 → 23:38

You, there are situations when you have to focus on one thing and

23:38 → 23:41

pool your resources together to accomplish that thing because

23:41 → 23:43

that's a major win for example.

23:43 → 23:44

That's understandable.

23:44 → 23:48

But then you know do not ever fall for the trap of constantly

23:48 → 23:50

delaying, oh we can do that later, right?

23:50 → 23:51

We can do that.

23:51 → 23:53

There would always be a better time to do it.

23:53 → 23:56

Don't fall into that trap because you wake up in a point

23:56 → 24:00

that the design debt is so big that would be difficult to

24:00 → 24:01

tackle at that point.

24:02 → 24:06

And speaking of tackling, let me go back for a moment to

24:06 → 24:09

this analogy between design debt and tech debt.

24:10 → 24:12

So there is this concept of refactoring.

24:12 → 24:16

So when you have some legacy code, you start improving it.

24:16 → 24:17

So you refactor it.

24:18 → 24:21

Is the same true for design. Debt?

24:21 → 24:24

I mean, what's the best way to deal with it?

24:24 → 24:26

Is there any best way?

24:26 → 24:28

You got that?

24:28 → 24:31

It's a tricky one.

24:31 → 24:32

That's a difficult one.

24:32 → 24:33

Yeah.

24:33 → 24:34

If there would be great solution,

24:34 → 24:38

we would obviously love to discuss it.

24:38 → 24:41

As the time passes and as the different companies that we

24:41 → 24:45

that I had a chance to observe had the various difference,

24:45 → 24:49

let's say, of dealing with that kind of situation.

24:50 → 24:54

When it comes to the refactoring in the case of the design,

24:54 → 24:57

we would definitely start to think about this distinguish

24:57 → 25:01

between this evolution or revolution approach.

25:01 → 25:04

Different cases would would would demand different

25:04 → 25:05

approaching here.

25:06 → 25:08

I don't necessarily

25:09 → 25:12

it's very hard for me to imagine situation when I can in

25:12 → 25:16

a project that is ongoing and has a group of users that

25:16 → 25:20

are demanding to be basically served with the solutions

25:20 → 25:24

that we we are selling to them.

25:24 → 25:26

It's really hard for me to imagine situation when we need

25:26 → 25:30

when we are able to stop works,

25:30 → 25:33

do the total overhaul of the interface and then get back

25:33 → 25:38

and expect that everything will go fine from this point on.

25:38 → 25:41

So in my personal opinion,

25:41 → 25:45

going with the tackling the design that in that situation

25:45 → 25:48

needs to be rather steady and

25:48 → 25:53

very much focused on the data in that approach.

25:53 → 25:54

By data.

25:54 → 25:57

I mean anything that we can do to monitor our user behaviors

25:57 → 26:01

or our market numbers, anything that is really

26:03 → 26:05

basically centralized on our users,

26:05 → 26:09

no matter if these are external clients or users of our tool

26:09 → 26:11

that are working in our company.

26:11 → 26:13

So in that in that approach,

26:13 → 26:17

anything that can be based on this on this data that we are

26:17 → 26:21

able to gather should be performed step by step in

26:21 → 26:25

the more steady approach rather than going with

26:25 → 26:28

with big changes.

26:29 → 26:32

If there are any changes that need to be that are that seems

26:32 → 26:35

to be kind of bigger one because, for example,

26:35 → 26:38

we had something that was that outdated some solution.

26:38 → 26:40

I know in the case of the navigation or tackling

26:40 → 26:45

different different different stuff when we are facing this

26:45 → 26:49

kind of situation, probably trying to find a way to to test

26:49 → 26:50

it with users, of course,

26:50 → 26:53

as an obvious part of the design process would be a way

26:53 → 26:58

to go and with launching or launching it probably as

26:58 → 26:59

some separate feature.

26:59 → 27:01

If we have this, let's say,

27:01 → 27:05

comfort of having new feature being built and being able to

27:05 → 27:08

introduce this change only there to make sure that we

27:08 → 27:11

somehow kind of try measure the thing that we're planning to do

27:11 → 27:15

in comparison to the oldest solutions that our users are

27:15 → 27:16

used to already.

27:16 → 27:19

That would probably the way to go in my opinion.

27:19 → 27:20

Try to be steady,

27:20 → 27:24

to be data oriented in the way of the user feedback data in

27:24 → 27:25

this approach.

27:25 → 27:29

I don't see right now any better answer that I can come

27:29 → 27:32

up with, to be honest, based on my experience.

27:32 → 27:33

Yeah.

27:33 → 27:36

So it's in this topic of evolution not really a

27:36 → 27:39

revolution and tearing everything apart.

27:39 → 27:39

Yes.

27:39 → 27:41

Definitely being rather

27:42 → 27:44

subtle with your users.

27:45 → 27:49

Not one likes changes and this isn't this necessarily

27:50 → 27:54

no matter what people will will talk they do not like it.

27:54 → 27:58

So it's not gonna be the best way to do it smoothly to tear

27:58 → 28:01

everything apart and bring something totally new to them.

28:02 → 28:03

Michael?

28:03 → 28:04

Yeah.

28:04 → 28:07

I would only say it's it's a very difficult question,

28:07 → 28:10

but I I would I would sway towards what what Jagoda said.

28:10 → 28:13

It's it's typically better to to

28:13 → 28:15

to be very data driven,

28:15 → 28:18

very educated about the fact before making any decisions.

28:18 → 28:21

And typically, nine out of ten times go for an evolution

28:21 → 28:23

rather than revolution,

28:23 → 28:26

especially with a product that has live users

28:26 → 28:29

because well it's different for most user groups but a lot of

28:29 → 28:34

people are resistant to change or they you know a sudden change.

28:35 → 28:38

Making changes one by one is a good way to go.

28:38 → 28:41

However, I would only add to this that

28:41 → 28:43

if you have one, perfect.

28:43 → 28:46

If you don't, get in touch with a good design team.

28:46 → 28:50

Because there is no I wouldn't say there's a golden rule in it

28:50 → 28:52

other than what Jagoda mentioned.

28:52 → 28:54

Be be very careful about this topic.

28:54 → 28:54

But other than that,

28:54 → 28:57

there's no there's no answer that can be given in a

28:57 → 29:00

universal fashion that you should always go for this or

29:00 → 29:01

always go for this.

29:01 → 29:04

Perhaps your product and your user user group would allow for

29:04 → 29:06

a revolution we do not know.

29:06 → 29:09

So get in touch with a good design team speak to them

29:09 → 29:12

and assess how much that has been ramped

29:12 → 29:13

up, what are the consequences,

29:13 → 29:16

what are what does data suggest,

29:16 → 29:20

what are our options as far as time budget, right.

29:20 → 29:22

How much can we change,

29:22 → 29:26

do we have access to those users in an easy way to test

29:26 → 29:28

things and to maybe reach out get some feedback?

29:28 → 29:29

Have you been

29:30 → 29:31

tracking feedback?

29:31 → 29:33

How much information do you have right?

29:33 → 29:36

So once you once you get in touch with them it's possible

29:36 → 29:40

it's possible to assess the situation and then come up with

29:40 → 29:41

a with an answer.

29:41 → 29:43

But as far as a universal answer,

29:43 → 29:44

it's it's difficult to give,

29:44 → 29:49

although the safer way is is to go for an evolution rather than an evolution.

29:49 → 29:54

So as I suspected, the answer would be it depends as is always the case.

29:54 → 29:54

Yeah.

29:54 → 29:58

I feel like we're trying very hard to but

29:58 → 30:01

it does depend on many things a lot of times.

30:01 → 30:01

So Yeah.

30:01 → 30:04

It would be rather naive to think that there are some

30:04 → 30:07

solutions that are out of the box.

30:07 → 30:09

In many cases might be,

30:09 → 30:11

but in most of them it's just as we have said,

30:11 → 30:14

try to reach to the experts that are actually able to

30:14 → 30:18

assess your situation and just consult it.

30:18 → 30:23

You mentioned this reluctance on the part of the

30:23 → 30:25

users because users generally don't like changes.

30:25 → 30:28

And I know from my own experience that whenever I see

30:28 → 30:31

any major change done, for example, to the interface,

30:31 → 30:34

I immediately want to go back to the old version.

30:34 → 30:36

How do you deal with something like that?

30:36 → 30:39

Because you need to evolve sooner or later.

30:40 → 30:42

That's true.

30:42 → 30:43

Well,

30:46 → 30:49

I think the answer be honest.

30:49 → 30:53

It might not be the ideal or the one that we expect to hear

30:53 → 30:56

when it comes to this kind of, let's say,

30:57 → 31:01

consulting in this in this kind of setup.

31:01 → 31:05

So definitely your product is brought up to the market and

31:05 → 31:09

you would like to continue evolving or

31:09 → 31:13

basically developing it in the way of the gathering more

31:13 → 31:16

audience and being able to to to, let's say,

31:16 → 31:19

serve them well when it comes to software.

31:21 → 31:25

I would say that is very,

31:26 → 31:30

very hard or maybe even impossible to tackle the users

31:30 → 31:33

that are very, let's say,

31:35 → 31:37

resistant to change.

31:37 → 31:40

But there is one thing that we need to have in mind that if

31:40 → 31:44

your product brings them value.

31:44 → 31:45

They will adapt.

31:45 → 31:48

There is it maybe not one hundred percent,

31:48 → 31:50

but there is a great chance of them adapting.

31:50 → 31:54

So it might be harsh at different levels of of of the

31:54 → 31:56

of the, let's say, company

31:58 → 31:59

stages.

31:59 → 32:00

But

32:01 → 32:03

when it comes to the value of the product,

32:03 → 32:08

this is the thing you need to have on your horizon all the

32:08 → 32:11

time, right next to your users needs.

32:11 → 32:14

It is very hard to convince them at once,

32:14 → 32:16

but there are ways to do that.

32:16 → 32:20

The more data you have, the more you will know.

32:20 → 32:23

The worst way is to basically just try it without any

32:23 → 32:27

further investigation on how to do it smoothly.

32:27 → 32:29

There are different solutions on the market or different

32:29 → 32:31

strategies to do so.

32:31 → 32:34

Introducing changes one by one might be the thing,

32:34 → 32:39

the proper onboarding or the newsletters with product

32:39 → 32:42

updates that you can provide your user with.

32:42 → 32:46

Probably even a separate department of

32:46 → 32:48

customer service that might get in touch with the user and be

32:48 → 32:52

fully accessible for them all the time when it comes to the

32:52 → 32:56

to some features overhauls or even giving them

32:56 → 33:00

just a possibility to get back to the old interface because

33:00 → 33:03

that might be just the way in some cases.

33:03 → 33:07

Just give them a period of time that they are aware of.

33:07 → 33:09

Let's say, I don't know, a month or two months.

33:09 → 33:13

I don't know how much it will be in the case of certain

33:13 → 33:17

companies and just allow them to mentally just change in

33:17 → 33:19

the way of how to how to use it.

33:19 → 33:23

If that product has this value and it is necessarily a tool

33:23 → 33:27

and your audience is well adapted with that,

33:27 → 33:29

it will be easier.

33:29 → 33:31

I would answer in that way.

33:31 → 33:33

I know, Michael, how do you feel about it?

33:33 → 33:36

But there are no one liners for this one.

33:36 → 33:37

Yeah.

33:38 → 33:41

This is not a topic you just this is not a question you just

33:41 → 33:44

answer with a one liner and be done with it.

33:44 → 33:46

I second everything you said.

33:46 → 33:50

So going with the evolution rather than revolution changes one by one.

33:50 → 33:51

Very important.

33:51 → 33:55

Do not do not just throw everything upside

33:55 → 33:59

down starting Monday when when changing things.

33:59 → 34:02

Go one by one. Monitor the behavior of users.

34:02 → 34:04

How do they react to it?

34:04 → 34:07

In order to do that you need to be in touch with them already, right?

34:07 → 34:11

You cannot it's kind of assuming that you

34:11 → 34:13

are tracking their behavior,

34:13 → 34:16

how they interact with your platform and your product.

34:17 → 34:20

Newsletters informing about changes ahead of time.

34:20 → 34:23

I think Igor that you mentioned it this is something very important.

34:23 → 34:25

If you can have polls

34:26 → 34:28

just ask them do they like the feature?

34:28 → 34:32

Feedback you know that I think Google sometimes

34:32 → 34:34

when they make changes they ask for your feedback.

34:34 → 34:37

They attach a feedback option to you know some some new features.

34:37 → 34:38

That's a cool option.

34:38 → 34:42

Think of ways you can get the response to what you did.

34:42 → 34:46

Do as much as much homework before you implement the change,

34:46 → 34:50

track behavior during making the change or the in the

34:50 → 34:52

immediate time right after,

34:52 → 34:55

and then gather feedback as much as you can and do it one by one.

34:55 → 34:57

It's a lot of work,

34:57 → 34:59

but if you can if you can afford it,

34:59 → 35:00

if you can carry it out that way,

35:00 → 35:03

that will be an optimal way for me.

35:03 → 35:06

And this is also the part when your design team design

35:06 → 35:07

team should support you.

35:07 → 35:12

So this is the way why this is one of the aspects of the

35:12 → 35:14

design never being ended.

35:14 → 35:17

It should be maintenance and the method that Michael

35:17 → 35:21

mentioned, like auditing your tool and gathering feedback

35:21 → 35:24

in the interviews, in some posts or surveys.

35:24 → 35:29

This is the this these are the ways of how you maintenance the

35:29 → 35:32

design in the way of gathering feedback about it.

35:32 → 35:36

So that might be the one of the shades of how you how

35:36 → 35:40

you not ever end your design in a way that it should not

35:40 → 35:46

be put it in the box and just put it in the shelf and being forgotten.

35:46 → 35:49

So users are one thing.

35:49 → 35:52

So keeping listening to them, keeping them satisfied,

35:52 → 35:55

but also giving them enough time to get accustomed to changes.

35:55 → 35:59

But what about the business stakeholders?

35:59 → 36:03

Do you feel that they are generally aware

36:03 → 36:07

of legacy design being a problem or maybe

36:08 → 36:09

not so?

36:09 → 36:13

So maybe the complete opposite and they generally do not,

36:14 → 36:18

you know, agree that it is an issue that should be tackled.

36:18 → 36:20

What's your experience on that?

36:20 → 36:24

I think that we had this conversation some time ago with

36:24 → 36:30

Michael about this iceberg metaphor of perception,

36:30 → 36:33

of the design perception that is sometimes not always,

36:33 → 36:37

but sometimes the case when it comes to the to the products

36:37 → 36:41

that are going through some changes and need some

36:41 → 36:45

attention when it comes to that in general or some legacy setups in here.

36:45 → 36:48

So I don't know, Michael, but you can, I think,

36:48 → 36:51

very clearly brought it up based on your experience with

36:51 → 36:53

the with the business stakeholders?

36:53 → 36:56

So to explain what's going on with the with the tip of the

36:56 → 37:01

iceberg metaphor, it's it's something I I came across

37:01 → 37:03

working with different companies.

37:03 → 37:06

Now I'm not saying I'm not saying that this is universally the case.

37:06 → 37:07

This can be the case.

37:07 → 37:10

So for anyone listening, it may be the case.

37:10 → 37:12

It doesn't necessarily have to be.

37:12 → 37:17

But the so the the thing we're talking about is that

37:17 → 37:20

code and tech and programming effort in all digital products

37:20 → 37:24

if you have a product that's easily recognizable as

37:24 → 37:26

something that's fairly difficult understand.

37:26 → 37:29

So you imagine it is a is a mountain to cross. Right?

37:29 → 37:31

So you you look at code and you think, okay.

37:31 → 37:36

If if you're not a tech person, you look at code and you see, okay.

37:36 → 37:38

Well, this doesn't make much sense to me. Right?

37:38 → 37:40

I do not know how to handle this.

37:40 → 37:43

I do not know you look at code you have no idea of you know

37:43 → 37:46

whether it's a good code, it's a bad code.

37:47 → 37:49

With design it's a mountain to cross.

37:49 → 37:51

It's quite visibly difficult, right?

37:51 → 37:52

With design it's slightly different.

37:52 → 37:53

Design,

37:54 → 37:58

a digital products design gives you the illusion that you,

37:58 → 38:02

you know, it's easily easy to formulate an opinion on it.

38:02 → 38:05

And the one of the one of the most common things I see is

38:05 → 38:08

that it looks good, so it's it must be good.

38:08 → 38:09

Right?

38:09 → 38:11

And this is a popular misconception because good

38:11 → 38:16

looking design has nothing to do with usable design.

38:16 → 38:19

And good looking design and good looking design is a

38:19 → 38:21

subjective term in itself because it may be good looking

38:21 → 38:26

to one group of users and then awful to another because

38:26 → 38:29

the trends change because the taste or what they're used to

38:29 → 38:31

are just different right.

38:31 → 38:35

Which is why if tech and programming is a mountain to

38:35 → 38:39

cross, the design is what you see and what you think

38:39 → 38:40

you see in design.

38:40 → 38:42

If it looks good must be good that's a tip of the iceberg

38:42 → 38:46

because there's much more that goes into design than just

38:46 → 38:47

whether or not it looks good.

38:47 → 38:50

There's logic behind it, there's research behind it,

38:50 → 38:54

there are trends behind it, there's mathematics behind it,

38:54 → 38:57

there's so much that goes into design and I see it because I

38:57 → 39:01

work with designers such as Jagoda every day and I see how

39:01 → 39:05

much effort goes into creating a design like that and it's so

39:05 → 39:09

easily like mistaken

39:09 → 39:12

when trying to formulate opinion on it,

39:12 → 39:14

which is hence the iceberg.

39:14 → 39:16

And if there's one thing that I would really want people to

39:16 → 39:19

sort of remember, that's that.

39:19 → 39:22

It's design is much more difficult to identify

39:22 → 39:24

as good or bad.

39:24 → 39:26

Much more difficult.

39:27 → 39:31

I would agree with that especially when it comes to this

39:33 → 39:36

subjective opinion of whether it's looking good or not.

39:36 → 39:39

It might look great on one or two views.

39:39 → 39:43

It might be totally unusable, not even for users,

39:43 → 39:46

but even for designers when it comes to the architecture of

39:46 → 39:49

the design files and how the components are being made and

39:49 → 39:53

what kind of cooperation was put it in there

39:53 → 39:57

to stay stay consistent with the tech stack that we are

39:57 → 40:00

operating with when it comes to the front end and stuff like that.

40:00 → 40:01

So

40:01 → 40:04

there is when it comes to the business stakeholders,

40:04 → 40:08

sometimes there is the case that we as a people,

40:08 → 40:14

every one of us is a user in the part of their of their lives.

40:14 → 40:18

So we tend to think that we are designers in the same way.

40:18 → 40:19

So we have this kind of knowledge.

40:19 → 40:23

This is great because it really shows how how close

40:23 → 40:27

to people it is and how how it's really a part of their life.

40:27 → 40:29

But on the other hand,

40:29 → 40:32

when it comes to the business decisions about the new

40:32 → 40:36

composition or the efficiency or effortless of the of

40:36 → 40:40

the certain approaches to to to how to handle design

40:40 → 40:42

within certain projects or product,

40:42 → 40:46

then it becomes a bit more how to say it complex

40:46 → 40:50

matter than just visual side of it.

40:51 → 40:53

You're to if you're trying to determine whether or not your

40:53 → 40:56

design or just any design is, you know,

40:56 → 40:59

works for what you're trying to do, works for your user group,

40:59 → 41:03

works for what you're trying to do, is there debt in it,

41:03 → 41:05

will it allow you to scale further,

41:06 → 41:08

speak to your designers if you do not have designers,

41:09 → 41:12

Find them. Find a design team. Speak with them.

41:12 → 41:16

Get them to do a UX audit. Check for things.

41:16 → 41:20

It's it's not possible to assess design just by looking

41:20 → 41:24

at it by someone who has not worked as a digital designer.

41:26 → 41:28

Okay.

41:29 → 41:33

We're heading slowly towards the end of the discussion.

41:33 → 41:37

So my last question would be how do you strike

41:37 → 41:40

balance between being overly focused on business,

41:40 → 41:43

on features, and being focused on users,

41:43 → 41:47

on the usability, on the functionality

41:47 → 41:48

of the design?

41:48 → 41:52

Is there any golden mean? And if so, how can you achieve it?

41:53 → 41:55

I guess it depends.

41:55 → 41:59

But maybe you have some pro tips from your own experience.

42:01 → 42:05

To be honest, the only pro tip in that matters that comes to me in the

42:05 → 42:08

way of the finding this balance and not

42:08 → 42:12

being derived from the from the perspective of the

42:12 → 42:17

users is just incorporating design to your

42:17 → 42:21

daily daily operational process in your company.

42:21 → 42:23

By incorporating design.

42:23 → 42:28

Mean, of course, having the design team on board that is responsible for

42:28 → 42:32

maintaining it and being in intact with customer success

42:32 → 42:36

team with the tech team being just vital

42:36 → 42:39

living living part of the of of

42:39 → 42:42

the project you're working on.

42:42 → 42:46

Because this is the only way to not to not forget about it,

42:46 → 42:47

I would say.

42:47 → 42:49

This is the best perspective to gather it.

42:49 → 42:55

So that would be one of the tips that comes to my mind in that approach.

42:56 → 42:58

Michal, how about you?

42:59 → 43:02

I would say well, first and foremost,

43:02 → 43:03

I I agree.

43:03 → 43:05

I would say if you if you're looking to

43:05 → 43:08

to strike a balance not forget about about that design and

43:08 → 43:10

keep in touch with it.

43:10 → 43:13

Just have a designer keep in mind that this is something

43:13 → 43:17

that you should be tending to and maintaining in the long term.

43:17 → 43:20

You always need to have at least your eyes on it.

43:20 → 43:23

Keep in touch with your design. Monitor things.

43:24 → 43:27

If, you know, if you're looking to there are absolutely times when you need

43:27 → 43:29

to focus on scaling.

43:29 → 43:30

But

43:31 → 43:34

it's difficult to say because it's very specific to the team

43:34 → 43:37

that's working with you on the product, right?

43:37 → 43:41

Somehow there needs to be a way in which at least in the

43:41 → 43:45

in the time of focus on trying to to build new things for your

43:45 → 43:49

product, you need have some time to look back and assess things right.

43:49 → 43:50

Having

43:52 → 43:55

those focus periods when you build new things there needs to

43:55 → 43:58

be a moment when you take a break, look back,

43:58 → 44:01

see okay do we need to factor anything.

44:01 → 44:04

And it can be even in the

44:05 → 44:07

time when you developed a lot of things,

44:07 → 44:10

you're looking to gather feedback during that time you

44:10 → 44:13

can do some of the work sort of looking back.

44:13 → 44:16

Having a designer with an agile team,

44:16 → 44:20

with a product team at all times supporting developers,

44:22 → 44:25

analyzing the the traffic, at heat maps,

44:25 → 44:28

gathering feedback, testing new features, So it's a good thing.

44:28 → 44:30

It doesn't have to be again,

44:30 → 44:34

it doesn't have to be a team of designers working on it full time.

44:35 → 44:38

Yeah, it's not that as we said in the

44:38 → 44:42

beginning it's not the constant act of creation that you do

44:42 → 44:44

when it comes to the design of the company.

44:44 → 44:45

These are

44:46 → 44:50

many more phases to it and definitely each one should

44:50 → 44:55

be treated with the their caution and cure not to be neglected.

44:55 → 44:59

Just one one of the tips just treat the design like

44:59 → 45:04

like like coding in the way of the character in your company.

45:04 → 45:07

Of course, there are no this this that you cannot use the

45:07 → 45:11

same methodology in the case of the, let's say,

45:11 → 45:15

operational operating on this design or trying to to scan

45:15 → 45:20

outside planet right within within

45:20 → 45:24

the kind with with the workload in mind,

45:24 → 45:26

but just treat it on the same level of serial of the

45:26 → 45:29

seriousness when it comes to the impact on on your business.

45:29 → 45:30

Yeah.

45:30 → 45:35

And I would also I would also add that don't look at design as a cost.

45:35 → 45:37

Obviously, there's cost to be incurred,

45:37 → 45:38

but it's an investment.

45:38 → 45:38

Right?

45:38 → 45:42

Design is just as likely to bring you big money

45:42 → 45:44

as development of new features.

45:44 → 45:48

It's it's just as likely. So it's not just a cost to be had.

45:48 → 45:50

It's not just a necessary thing to do.

45:50 → 45:52

It absolutely there's there's big money in it for your

45:52 → 45:57

product and absolutely don't don't don't save on it.

45:58 → 46:00

If you need to find space in your team,

46:00 → 46:04

in your budget for a designer to do their work absolutely do it.

46:05 → 46:09

So to sum up, the legacy design will happen,

46:09 → 46:12

but it's not something to be too afraid of to tackle.

46:12 → 46:17

So you will have to face it for your own good, basically.

46:17 → 46:19

Yeah, pretty much so.

46:19 → 46:22

I think that's one of the few questions that we can actually

46:22 → 46:26

answer truthfully and without doubt,

46:26 → 46:28

without it depends.

46:28 → 46:30

Yes, that's true.

46:30 → 46:33

That's actually really the case that you can, you know,

46:33 → 46:36

in IT that you answer it without saying it depends.

46:36 → 46:39

Happy that it happened.

46:39 → 46:42

Okay, thank you guys for a very insightful discussion.

46:42 → 46:45

I guess now we can proceed to questions.

46:45 → 46:48

So let me just remind our audience that you can still ask

46:48 → 46:51

some questions in the chat box.

46:51 → 46:56

So let me first maybe combine the two because actually you

46:56 → 46:58

have two quite similar questions.

46:58 → 47:01

I can see that this topic of cooperation between the design

47:01 → 47:03

and developer team is pretty interesting.

47:04 → 47:08

So both questions actually concern

47:08 → 47:11

the way in which you should structure this collaboration

47:11 → 47:13

between developers and designers.

47:13 → 47:17

And the first one is about how to

47:17 → 47:21

do it to prevent design debt from happening.

47:21 → 47:25

And the second one is how to not make things worse.

47:25 → 47:28

So maybe we could try to combine these two perspectives.

47:28 → 47:32

So how to cooperate so as not to let it happen and

47:32 → 47:36

not to let it grow out of control.

47:36 → 47:39

So as we kind of, let's say,

47:39 → 47:45

answered in the beginning that this like the design that will happen.

47:45 → 47:48

So you cannot prevent it. So you just need to spot it.

47:48 → 47:50

You need to just be aware of it.

47:50 → 47:54

And the moment you are aware of it, you can start tackling it.

47:54 → 47:56

And when it comes because I've seen that the question is

47:56 → 47:59

related how to tackle that when it comes to the design

47:59 → 48:03

and the development teams on the cooperation side.

48:03 → 48:03

Yeah.

48:03 → 48:07

So based on the experience and the

48:07 → 48:10

best practices that I would use in that case,

48:10 → 48:14

that would be definitely tracking the separate backlog

48:14 → 48:17

of the issues that you are spotting ongoingly with the

48:17 → 48:21

when it comes to the design of the new features or how you

48:21 → 48:25

work with the components of the features that are already developed.

48:25 → 48:29

Because it's it is it's not

48:29 → 48:32

possible to it's not always possible to just keep your

48:32 → 48:35

design always intact and as mirror

48:35 → 48:39

reflection of what you have developed already.

48:39 → 48:41

It's often just a waste of time, to be honest.

48:41 → 48:43

So the thing that you need to do is definitely keeping the

48:43 → 48:46

backlog of the changes that need to be addressed because of

48:46 → 48:50

some crucial because they are crucial on some some ways to that.

48:50 → 48:54

And with that backlog, separate backlog of design

48:54 → 48:57

that issues that you can spot out,

48:57 → 49:00

the best probably idea would be to try to

49:00 → 49:04

incorporate it and the single issues from this

49:04 → 49:09

backlog to just your ongoing development work here.

49:09 → 49:12

Not everything at the same time.

49:12 → 49:16

As each sprint happens, it's really hard for me to

49:16 → 49:20

imagine sprints that I was a part of and has not

49:20 → 49:24

any spare time or any time for just some some small

49:24 → 49:28

some small enhancement or improvements.

49:28 → 49:32

So definitely keeping separate backlog for these design issues

49:32 → 49:34

and then trying ongoingly cooperate them

49:34 → 49:38

incorporate them to the backlog of the of the current sprint

49:38 → 49:43

or in what methodology you are working for for your for your dev team.

49:43 → 49:46

Of course, intact with the designers to be sure that they are there.

49:46 → 49:49

Close operation with the quality assurance team member

49:49 → 49:53

and team members probably is also one of the hint in here

49:53 → 49:57

that should be reflected and should help in that matters,

49:57 → 49:57

I think.

50:00 → 50:03

Michael, do you have anything to add to that?

50:03 → 50:04

Yeah.

50:04 → 50:08

So I agree with what Yagoda said

50:08 → 50:12

and Yagoda referred to when she mentioned

50:12 → 50:14

that she works with the team with Sprint,

50:14 → 50:16

she adds the things to the backlog.

50:16 → 50:19

She keeps her the things that she needs to work on in a

50:19 → 50:21

separate backlog to to always keep an eye on it.

50:21 → 50:25

This this this refers to the way when we set up product

50:25 → 50:29

teams for our clients, our designers work with them and

50:29 → 50:32

with our development teams in a close cooperation throughout

50:32 → 50:34

the project.

50:35 → 50:38

There's a few pieces that we wrote on as to how it works.

50:38 → 50:41

But in general, the idea is that the designer is always present working with

50:41 → 50:43

the team.

50:43 → 50:46

If they are not currently dishing out new designs,

50:46 → 50:50

new screens, new components, the style guide is closed for now.

50:50 → 50:52

They assist the team with implementation,

50:52 → 50:55

mostly front end developers, but also like she said,

50:55 → 50:56

quality assurance,

50:56 → 50:59

back end back end engineers maybe slightly less so,

50:59 → 51:01

but still they help with implementation.

51:01 → 51:05

That way they stay in touch with what's currently going on.

51:05 → 51:09

If you just push the the designers aside

51:10 → 51:13

and they stop working on the project altogether,

51:13 → 51:17

they lose track of what's going on and they will not be able to

51:17 → 51:20

be reengaged in a very efficient manner,

51:20 → 51:22

which is why they stay assist with implementation.

51:23 → 51:25

That's a very good way to do it.

51:25 → 51:27

Another way is to and this is something that I would

51:27 → 51:31

recommend but it's something more difficult to achieve a lot

51:31 → 51:35

of times is ideally you want to work with developers that know

51:35 → 51:39

how to work with designers because to give you an example, right?

51:39 → 51:40

If front end developers,

51:40 → 51:44

they work on let's say front end developers work on an a

51:44 → 51:47

further implementation, scaling of a specific dashboard,

51:47 → 51:48

there's new features to be added.

51:48 → 51:51

If they already see that the features that they need to add

51:51 → 51:52

to specific dashboards,

51:52 → 51:55

the dashboard as a result the dashboard will become

51:55 → 51:58

overcrowded things start looking off, right?

51:58 → 52:00

They will know that you know there's something wrong with it

52:00 → 52:03

ideally we want to have a designer take a look at it, right?

52:03 → 52:06

So they will know who to let them know that this there's

52:06 → 52:08

something that needs to be needs to be adjusted.

52:08 → 52:11

If they don't necessarily work on with designers every day on

52:11 → 52:13

like on a daily basis,

52:13 → 52:17

it might be that they will just you know they won't know how to deal with it.

52:17 → 52:19

Not saying that that's always the case,

52:19 → 52:22

but you know people that are used to working with designers

52:22 → 52:25

know when to call for them when they see a sit,

52:25 → 52:29

when they assemble upon a situation when that calls for it.

52:29 → 52:29

Yes.

52:29 → 52:34

And this awareness should work in let's say,

52:34 → 52:37

both sides of this.

52:37 → 52:39

So experience is not on like,

52:39 → 52:41

user experience is not only a visual side.

52:41 → 52:43

It's the experience side.

52:43 → 52:44

So

52:45 → 52:48

whenever you will came up with the new features of your design

52:48 → 52:53

team and consult it with with the the dev engineering team,

52:53 → 52:55

you just need to be aware that some compromises just sometimes

52:55 → 52:57

needs to be done because, for example,

52:57 → 53:01

for the performance stuff that needs to be in line with that.

53:01 → 53:03

When we have some great solutions that will be just not

53:03 → 53:06

necessarily that efficient in the case of the performance,

53:06 → 53:09

then we should aim to focus on what's what's first,

53:09 → 53:12

the visual side or the functional side in here.

53:12 → 53:16

And in many cases, the functional side is the most important one.

53:16 → 53:20

So the understanding of the when to call a designer when it

53:20 → 53:24

comes to to view to to layout being

53:24 → 53:28

overcrowded or the awareness of the designers where to call the

53:28 → 53:31

front end and back end engineers to basically help

53:31 → 53:35

them with assessing which solution will be less

53:35 → 53:38

impactful when it comes to their cost of work.

53:38 → 53:42

This is also very important to have in mind to have the people

53:42 → 53:45

that are aware of each other's circumstances and when to ask

53:45 → 53:47

for help or support.

53:48 → 53:51

Yeah, because collaboration is actually sometimes easier said than done.

53:51 → 53:55

So it's good to take care of In the area of scrum and agile

53:55 → 53:58

being everywhere in the IT right now,

53:58 → 54:02

it's very easy to forget that sometimes the

54:02 → 54:03

communication is the key,

54:03 → 54:05

especially when you're scaling up your business.

54:05 → 54:09

Right? And the number of people working for you is growing.

54:09 → 54:10

Right.

54:10 → 54:14

Okay, thank you. We still have six minutes.

54:14 → 54:19

So if you still have any questions to our experts,

54:19 → 54:22

please now is the time to ask them.

54:22 → 54:27

But in the meantime, actually I have one question

54:27 → 54:30

that I'm dying to actually ask you.

54:30 → 54:34

So I know NDAs are a thing and you cannot

54:34 → 54:37

talk that openly about all the projects.

54:37 → 54:41

But I'm wondering what's your most interesting

54:42 → 54:46

experience with working with a legacy design project?

54:46 → 54:49

Maybe something particularly challenging,

54:49 → 54:52

exciting or maybe scary happened to you that pops

54:52 → 54:56

immediately into your mind when you hear the term outdated design?

54:58 → 55:02

So in the manner of this idea that we cannot,

55:02 → 55:04

of course, talk about specific cases,

55:04 → 55:09

I will just mention one thing that is very common to each of the

55:10 → 55:12

legacy design cases.

55:12 → 55:16

It's definitely working with the files of different

55:16 → 55:20

designers that we are inheriting or we are trying to

55:20 → 55:25

contribute to us as a as a extension team extension that ways.

55:25 → 55:28

So I would say this is always the most

55:28 → 55:34

intriguing part of of working with the

55:34 → 55:38

design that might be a bit outdated or be somehow

55:38 → 55:43

inherited in a way that has not been taken care of for a while.

55:43 → 55:47

Because for from my perspective, the

55:48 → 55:51

most intriguing part is trying to

55:51 → 55:55

came up to the solution and the answer to the

55:55 → 55:58

question and the process, let's say,

55:58 → 56:01

of investigation that I do within the company,

56:01 → 56:06

within the other design team or or the other stakeholders.

56:06 → 56:08

And the the

56:08 → 56:12

journey of finding out which design is which design

56:12 → 56:15

decision that design solution that I see on the

56:15 → 56:19

files that I inherited or I'm working with with other people,

56:19 → 56:23

which design is which design element is an effect of a

56:23 → 56:28

design decision of a particular designer that has been working

56:28 → 56:31

on that file and which solution is dictated by the

56:31 → 56:35

domain specificness of the of the product that we are working.

56:35 → 56:38

So this is always the most interesting part for me,

56:38 → 56:42

the way of trying to get know the the

56:42 → 56:43

environment better.

56:43 → 56:47

So to be sure this is the lesson that I've learned like

56:47 → 56:51

a couple of time not to quickly assess the other designers work

56:51 → 56:55

when it comes to the design legacy design because we are

56:55 → 56:56

never sure

56:57 → 57:01

what were the let's say or the story of the

57:02 → 57:03

solutions that we are seeing.

57:04 → 57:08

Think this is also the always the most intriguing part for me

57:08 → 57:09

to try to, let's say,

57:09 → 57:14

make up this reverse engineering of the decision

57:14 → 57:17

that has been made on some tools.

57:19 → 57:21

Thank you. Michael, how about you?

57:21 → 57:25

Do you have any you know particularly scary or exciting

57:25 → 57:28

stories from legacy design projects?

57:28 → 57:30

Well

57:31 → 57:34

as you know I probably have a couple but I cannot really I

57:34 → 57:38

can only speak and give particular examples.

57:38 → 57:42

Although I would say there were a couple that I found really

57:42 → 57:46

interesting and they weren't they weren't necessarily scary stories.

57:46 → 57:50

It was just fascinating to me when when we were supposed to

57:50 → 57:55

work on products that were built mid

57:55 → 58:00

2000s and weren't necessarily updated since then.

58:00 → 58:03

And so like the design,

58:03 → 58:07

the way things worked, they just they were they were so basic,

58:07 → 58:11

but the products still were so robust in their functionality.

58:11 → 58:12

Everything was very manual.

58:12 → 58:16

So you you are quite used to seeing very automated products.

58:16 → 58:16

Right?

58:16 → 58:19

Part of the part of the like the magic of the digital

58:19 → 58:21

products today is that they automate things,

58:21 → 58:24

they streamline things for you, they do things for you, right?

58:24 → 58:26

They shorten the distance,

58:26 → 58:29

they shorten the the amount of time you need to do.

58:29 → 58:31

That didn't do necessarily any of that.

58:31 → 58:35

It was just like a digital note part to to an extent and

58:35 → 58:39

that's the it was it was quite fascinating to me because I I

58:39 → 58:43

had this feeling that it's it's it looks like it's you know it

58:43 → 58:44

looks like it's from the two thousands.

58:44 → 58:47

It is from two thousands but quite quite a magical and then

58:47 → 58:52

trying to reimagine it and rebuild it completely,

58:52 → 58:53

it was quite interesting.

58:53 → 58:54

There were a couple of projects like.

58:54 → 58:58

But in general I would say one of the one of the great things,

58:58 → 59:02

of the exciting moments for me is always this can this

59:02 → 59:06

applies to new builds, greenfield builds as much as it

59:06 → 59:08

does to legacy design.

59:08 → 59:12

Re envisioning it at the moment of for example prototyping, right?

59:12 → 59:16

So after a maybe a UX audit or maybe like a product design

59:16 → 59:19

workshop during which team worked up requirements and sort

59:19 → 59:22

of the direction to take with a specific product.

59:22 → 59:25

When designers sit down to create the first prototypes of

59:25 → 59:29

they'd set on the creative direction maybe you know apply

59:29 → 59:32

changes, proposed changes and prototype things.

59:32 → 59:35

That's a moment when all of those requirements that I'm

59:35 → 59:38

used to discussing for weeks on that then take shape in the

59:38 → 59:41

form of a for example a prototype or a couple of designs,

59:41 → 59:43

that's an eye opening moment for me because it's finally

59:43 → 59:46

something tangible, right?

59:46 → 59:47

It's finally something.

59:47 → 59:51

It's a tangible representation of a direction we want to take

59:51 → 59:54

and personally to me it's just very exciting.

59:54 → 59:56

Okay, thank you.

59:57 → 60:00

Our live stream is coming to an end

60:00 → 60:05

slowly but as I said it is being recorded so you will be

60:05 → 60:08

able to rewatch it and if you come up with any questions then

60:08 → 60:10

also leave them in the comments.

60:10 → 60:13

So we'll pass them to Michaow and Yagoda and we'll try to

60:13 → 60:17

answer them as extensively as we can.

60:17 → 60:20

And that being said, Yagoda and Michaow,

60:20 → 60:23

thank you very much for joining me today.

60:23 → 60:27

It was a very informative discussion and I believe our

60:27 → 60:30

audience will learn a lot from it.

60:31 → 60:31

Thank you.

60:31 → 60:35

We certainly hope so. Thank you. Thank you for having us.

60:35 → 60:36

Okay, thank you.

60:37 → 60:42

And see you during our next software modernization live stream.

60:42 → 60:43

Thank you and goodbye.