Dean Schuster: How to Build UX Into Your Dev Process

This talk covers the integration of user experience (UX) into software development processes, highlighting the essential collaboration between UX professionals and development teams. Dean Schuster, an expert from a UX firm, emphasizes the importance of involving UX early in the product lifecycle rather than treating it as an afterthought. He explains the difficulties teams face when trying to blend technical and user-centered approaches, using the metaphor of Sisyphus to illustrate the repetitive challenges of product development. The session also discusses best practices for embedding UX in agile methodologies, the necessity of user research, and how to frame requirements that truly address user needs. By illustrating the different roles within a UX team and their significance, the speaker advocates for ongoing communication and collaboration throughout the product development cycle.

[Music] and we are back oh only 5 minutes after the last session uh welcome again for those who are Runing the session or the data track for the first time I'm Francisco Pini from open neula systems um this is the last session of the day for the data track uh but the schedule continues uh tomorrow we have another full day of online talks and on um th

Wednesday and Thursday there's a two days of event in Lithuania in vus okay so uh keep watching us and and the in the session uh we are going to welcome Dean Schuster Dean it's on a mission to help development teams Embrace and take advantage of ux that's super cool because you know when you watch the first version of Android you say yes this was made by programmers

not by designers uh and he will be talking about that as well and um in this session um just to remember uh rate the sessions at the end of the session there will be a popup in your screen asking you to rate the session feel free to make questions on the Q&A on the chat session so that's all my message right now I'm gonna welcome Dean to

Stage welcome Dean hi thank you good morning for you good afternoon good afternoon for the people in Europe uh so like yeah morning you will already to took your coffee uh yes I'm ready to go okay perfect I'm going to grab mine after this session I'm gonna share the screen with your slides and I leave it to you so the floor is all yours okay great uh

thank you everyone uh for joining I'm gonna expand my screen a little bit here and there we go uh it's an honor to speak with you today here from America uh I've been to vilus uh several times and I love it very much uh so uh if you're uh from Lithuania and hearing me speak um you're definitely hearing someone who who loves your country uh I'm going

to start now and uh tell you that yes my job as a ux professional is to help Dev teams Embrace ux uh and use it to its fullest um you can find me online if you have a question later and you didn't get a chance to ask it here in the conference uh you can go ahead and find me I'm easy to find and would love to

talk with you I am the owner and partner in a ux firm called called true matter we specialize in complex applications which means we're working with developers all day every day uh and it's a great joy to do that okay now I want to start a little bit with this myth uh from ancient times uh it's the myth of Copus and you might have heard of it

there was this character uh and his name was Copus and he for reasons that we don't need to get into today he runs a fowl of the Gods he runs a foul of Zeus Zeus gets very angry at him and uh condemns him uh into Hades uh with a horrible um NeverEnding Mission and his mission is to Simply roll the boulder to the top of a hill

and if he can get it to the top of the hill and it stays there he's done but this Boulder is Enchanted and every time it just gets to the top of the hill it always rolls back down so Copus is condemned for an eternity of rolling a boulder up a hill only to have it roll back down he has to keep doing it again and again

and again and again and this reminds me a little bit about development all right uh essentially we uh development teams are like Copus right we've got a lot of stuff we have to do to get a digital product right uh so many things to think about it's its requirements its quality it's functionality it's testing it's it's the users it's all this stuff it's the stakeholders that we've

got to get right in order to get it to the top of the hill and have it stay there but this Boulder for some reason is Enchanted and it always rolls back down and it's so hard for us to develop great products when we constantly are having to do the same things over and over again and can never quite get it to finish and at the top

of the hill we're imagine that that this is beautiful wonderfully functional development it's a great digital product it works and it's also easy to use that's really what we're after now development teams have always had trouble rolling this boulder up the hill so they decide that what they need to do to get the boulder up the hill is to do it a different way they change their

tactic uh they try to roll it up differently they they they try a different process or they try a different method but no matter what they do when it gets to the top it rolls back down no matter how they tried to roll it up there uh they might think you know if we want to make something usable we should just make the boulder prettier maybe if

we just paint the boulder it'll be usable and at least we've got that but that doesn't happen either all that happens is they roll the ball up to the top of the hill it rolls back and now it's a painted Boulder back at the bottom of the hill we're right back where we started so we have this burden of doing all this work and it seems always

too hard to do and this idea of joining ux and development is something like a a sopian task that's something we call something that is super super difficult to do and is completely fudal it will never work that's what we call this and a lot of people think this is true of making digital products that are great and usable right laborious and feudal and I know a

lot of us feel this way I know I felt this way quite often now there's a reason why it's difficult to fit ux into a development process right it's really a difficult mix for us users I'm sorry um ux people and developers you we're really different from one another so developers have certain things in common okay we're super technical we're not necessarily people focused we care about

functioning data we're trained in computer science ux people are a little bit different right they may not even know how things actually work they're always focused on people always always always their first concern is not necessarily the system itself and that's an important thing to remember and maybe they don't have as much Computer Science Background although some do and of course these two groups groups don't always

communicate well right we when we're trying to talk to the um uh developers as ux people uh we have difficulty with language right and we have uh difficulty uh with how we want to speak to each other and back and forth it's really tough now I'm not saying that you will have a situation like this where you have a a ux pro and a developer having a

full-on fight uh and I'm not saying this has ever happened in my office um although sometimes it can be stressful uh working together when we have such a different view of the world and of course this doesn't you know really happen we're just having fun our team actually works really really super well together and this doesn't typify what we're like the problem of course is that we

don't even agree on to what terms are okay so when we think about a digital product right let's look at this idea of the iceberg where a little bits on top of the water and a and a whole lot is below well when it comes to uh a developer we thinking system right the system sits below the water it's everything it's the function and on top of

that is sort of that uiux stuff that that people see right but the system's the thing well ux professionals think completely differently they believe that the experience is the thing that's underneath the water and above it is just of course what you see of the experience that's a two different ways of thinking about a digital product right and so Dev center team basically lack this perspective they

lack this ability uh to look at things from a people centered perspective from a user centered perspective uh and from uh an experience level and that's why digital uh product teams that are development uh Leed or development dominated have difficulty making things with great user experience it comes as no surprise so the question is how do we do it how do we bring ux into a development

process it's a very difficult thing to do so I'm going to talk to you a little bit today about how we're going to do that some best practices for doing that to sort of spark your imagination uh for how you might be able to start in your organization we're going to answer several really important questions over the next 30 minutes right when does ux start how do

we learn about what users need what about requirements how does ux fit into agile what kind of people do I even need to work with and when is ux done right these are the biggest questions we get all right so let's tackle the first one right when does ux start now we're used to thinking about a timeline right for digital products it's a beginning it has a

middle and it has an end all right there's this big part at the start and we think of you tend to think of ux as as something that happens in the beginning but some people also think of ux as something that happens at the end they think that all this development stuff stuff happens all the functionality is built and then we we add this ux to it

at the end right now that's certainly the wrong way to think about ux uh when we think about user experience there's a great deal of planning that must occur very early a lot of this includes things like research and and and so forth um and we tend to think that development happens after that and I know that a lot of developers care about this because they're frustrated

that they're not part of early discussions about requirements about needs about technology about platform so I know developers and development teams don't like being excluded from the beginning right so we need to think together about what's best for a life cycle of a product and so let's talk about ux and Dev being together and starting as early as possible at the beginning and continuing together throughout right

this is the premise is the way we need to think ux and Dev work together beginning middle and end and you can imagine uh on dev you're doing lots of planning and it's technology and its architecture these are very important things to think about at the beginning same thing is true with ux it's a different kind of planning it's about research it's about users it's about goals

and how they turn into functionality and how they support a system and how they work together with a system so ux at the beginning does those sorts of things right I talked about goals and objectives these are the things that ux people tend to do because they're trying to figure out what makes a digital product what it must be like what it must how it must behave

interact with it and so we tend to create things like goals and objectives where we have a big goal and several objectives we have uh for meeting it and we we predict well what should happen if we if we achieve these goals and how do we measure it we might do ux research uh surrounding what we learn from users and and what issues arise from what we

learn from observation or testing and it leads us to plan what a product must be like or how we must improve that product we might even think about features and functions user experienced people just think about this differently we think about it in terms of how features and functions support what users already need to do and why uh and so we tend to create things uh and

put it into a ux road map that we can reference and all this stuff happens at the beginning okay now there are some guidelines to think about here when we think about beginning activities this is not just something that ux people should do in a vacuum and then sort of hand it off uh to a development team and developers just take it and I guess I got

to do something with this no um developers should participate in all ux activities even if they're just observing if we're doing user research developers need to be there there needs to be a representative from the development team so you can understand uh how users are thinking and how we're planning for them it will help later by the same token ux people need to be listening to early

development conversations about platform about technology about performance about what is feasible and what is not and if both uh groups are listening to each other early and are participating with each other early later things will go well all right now let's think about uh users a little bit how they respond uh to what we make how do we learn what users want okay how do we learn

what they need well ux requirements come from people okay and here are just a set of people that might be our users for our product now when we ask users uh what they want or if we ask customers what they wish for we're doing things wrong okay okay now if we uh there's a wrong way to think about users right if we think about our internal preferences

what we already want to build what we already know we are going to build what we already know uh features that are going to go out and we think about it that way uh we're thinking from our perspective out we're not thinking about um how users actually work or what they actually need uh often we focus on what a stakeholder or a subject matter expert expert says

we should do or what they want us to do but what a stakeholder or anme says is not necessarily the same thing as what a user says in fact it's rarely the same thing that a user says and we should never ask people what they want because they don't know how to tell us that they are users they know certain things they know what they want to

do they know what their task is they know what frustrates them they know what gets in their way but they don't know how to tell us what features to make they don't know and if they just simply say I want this sort of feature and we make it it may be that they hate it and it's not exactly what they wanted because they don't know so customer

wish lists are are usually a problem to begin with we shouldn't do them now the right methods we should always observe users doing things very simple okay spending time with users watching them work like a scientist would watch something how do they operate what do they do what are workarounds um uh you you can watch them and say hey I notice uh you you have an extra

spreadsheet that's not part of this system what is that why do you have that why are you putting these sticky notes on your board why are you calling this person about something uh tell me why you're doing that because it may reveal problems with a system or it may teach you about the process so you learn how to produce a system this is this is the one

of the biggest secrets and and Powerful methods you've got and then of course we want users to describe themselves we want users to tell us what they're doing why they're doing it and what gets in the way right so that you know they're the best people to tell us this right so these are common templates we have uh in order to uh understand a user and it's

all about their tasks what they're doing why they're doing it what frustrates them what gets in the way and we have an actual user fill this out we don't fill this out we don't do it all right it leads us to understand a real user better and we create personas or user archetypes around this and this is an example of an actual one uh and it's about

90 to 95% completely written by the user which means we didn't put our opinion into it it's all them and that's extremely important going all the way to the user and letting them tell us what to do right very important okay now topic how does ux affect requirements right this is a very tough thing to uh to generally to understand I mean 90% of great ux is

about great requirements just about the same way we think about development same way we think about functionality okay there are several types of requirements just go over the basics right there's business requirements describe what an organization is trying to do their goals their objectives functional requirements we understand this right uh this is what your app must do what it does right but then there's also ux requirements

now ux requirements describe how people interact with your product it's all about Behavior it's all about what happens when things break down it's all about edge cases uh how do you handle mistakes how you handle tasks how people be how people interact how the system behaves back right so imagine you're wanting to give someone a wonderful product you made you know it's got all the bells and

whistles and ribbons right maybe it had amazing business requirements and functional requirements but then you give it to the user and they're like what is this I don't want this I don't like this I don't need this I can't use this this happens all the time because we're not focused on user requirements ux requirements which are hugely important so they think about who writes requirements right business

requirements are written by these types of people hopefully hopefully a business analysts but not all always sometimes it's just developers or a development lead functional requirements could be any one of a number of people but it's an engineer okay it's an engineer writing functional requirements ux requirements are written by a a ux uh designer right a lead product designer ux Specialist or maybe a ux strategist right

so let's look at high level ux requirements right they happen very early very early in the process we're learning about interaction of the system based on Research they're kind of a m mix of business and function right and they're always behavior-based and they're visualized with wireframes that's the big difference they're always part of something that's super visual so here it is an example of wireframes and they

uh and they may have notes associated with them and these notes may be off to the side but they're they're describing how the interface is acting and depending on the software that you use you can create these with actual notes uh sitting inside the wireframe and we use a tool called aure there's a number of wonderful tools uh that do this and they allow us to write

notes about Behavior directly into the interface we're working on and this allows developers development teams to constantly understand what a ux professional desires out of uh an interface because it's really difficult to write that all down without reference to something visual all right it's very important and you can create this along the way as you go okay user stories right this is something that we typically think

is something we we build based on especially in an agile process but they tend to be written with uh user specific language but they're not really about users they're about what we say the system should do and how we say users should walk through it that's very different from understanding how users actually think and what they actually want to do it's very very different user stories tend

to have an internal perspective we're pushing our ideas out to the users and and hoping that they could use it well just hoping and you and I both know that most complex project products made by development teams aren't easy to use so we are missing something with these user stories all right so what we need is to bring ux into user stories if you're using them right

now that means uh there are ux tasks associated with a story there are things that users must do there are things that ux people must do to support that and we need to uh gauge the effort of a ux team to support that thing so there's this idea of um how uh we actually do the work and also how a user interacts right so that means a

ux pro ideally right should write every story that has to do with something that's some important behavor behavior in the interface that will help you immediately at the very least a ux professional should be reviewing all stories very very very important very important and they should be giving at least input into those stories that will be a major change in how you develop products okay now the

big topic right is agile right um most of us are using an agile process of some kind right uh some nonlinear process right so let's uh talk a little bit about the rules for that and how ux can fit into that all right now you remember our myth of Copus we're trying to roll that boulder up a hill and it this beautiful functionality uh combined with great

usability but we can never quite do it now development teams to try to fix that they say I'm just gonna I'll bring the boulder up there differently right of course that never works like we said uh changing process C doesn't change the fundamental fact if you change how you get somewhere uh but you never incorporate user experience you never incorporate users into your process it doesn't matter

how you got there you just get there a different way okay so agile in and of itself is incomplete okay agile solves development problems it does not solve ux problems it was written uh uh to uh help us deliver software development better all right how to get to a product how to ship a product how to evolve a product how to continuously make it better that's agile

it has nothing to do with ux you have to force fit ux into agile very often especially if the people running agile teams don't know anything about ux right so you need this uh this notion of leaders in your team who say we are going to fit ux into this process you need product leaders product owners who desire to have ux built into the process so that

you can without that you you won't be able to do it right you absolutely need that so there's a lot of challenges beyond that in ux and agile okay the first problem of course with agile when it comes to ux it comes to design is this notion of the whole how see uh the whole of a system and how it how people are going to interact with

it before you make the pieces parts of it when it comes to design when it comes to ux seeing the whole is very very important we need a broad definition or a broad picture of a digital product's behavior and look and feel right and that may mean a design sort of like Global context of the design an overarching sense of what the design will be like and

how it will work before we get into the bits of functionality that we begin adding to it so we also need to plan Sprints accordingly because if you're not planning things like Sprints without ux input you are just going to do it the way developers have already done it uh you'll miss the hole and it'll be very difficult to incorporate ux that way uh once ux gets

going right let's say we have some uh maybe uh those uh that early Global context becomes like definition and ux related early Sprints right that Developers should be should be giving feedback to the whole way right before we go right but once we get to actually sprinting through bits of functionality you're going to need your ux team to be ahead of your development team at least one

or two sprints because there's so much stuff to get done there might be wireframes that have to be made there might be user testing to do there might be um there might be microcopy to write there might be frontend uh code author uh designs to finish before we get to development start plugging everything in so the ux pros have to be development and this means that uh

dealing with front end is super important um front end is a is a skill in and of itself uh the best front-end development people I know are specialists in front-end uh just because you're a backend developer and can do frontend uh doesn't mean you're great at it it doesn't mean uh you are perfectly suited to do that so front-end Specialists are a necessity uh and they they

Bridge a gap uh usually between ux design content uh and backend development and so you can imagine all of these different interfaces that we make uh that have complex front end associated with them this is really hard to do for backend developers this is a specialty I can't overstate that enough and these are some uh very complex highly uh um you know beautifully designed interfaces that uh

that we've done that uh require that role okay now once ux has done its work and we're sprinting on and development is occurring ux professionals have to be walking side by side with developers offering them guidance because you cannot figure out everything beforehand that's the essence of agile right we're going to learn things during development we're going to have to shift we're going to have to move

uh we're going to have to level set everything and you must have a ux person with you because something will always come up that no one planned for and you need ux guidance uh to work on things like interface behavior and interaction and how users would would deal with things so the ux RO doesn't end with handing things off you walk alongside the whole way because we're

a team right we're not just siloed individuals throwing things at each other we have to work together now there's a there's an ideal approach to this okay now if you're if you're really strong at this you can try this right and the ideal approach is that you wait to get into development Sprints don't go too early don't write stories or plan Sprints until you know what you're

building until you have a sense of that Global context in all these behaviors and you know how you do that is you just start together you sketch uh you early sketches of an interface and then maybe you get further and you get into wireframes and if you're really smart you iterate those with users ux people devs together with users iterate those until you got a good sense

of what you want to do for an MVP then then you plan your user stories and then you uh plan your development right this is iteration this is essentially agile it's just a big chunk of agile before we're doing the development Sprints right that is an ideal process that's how you should be thinking I mean sketches sketches are so easy this is an early sketch right and

this actually is really close to what we ended up designing right then you have those wireframes we're talking about they're annotated they're easy to do they're quick they're fast you change them really easily uh even better if you're having users interact with them to help you change them right this are not too hard to do sometimes we even make prototypes that we have you know real click-through

and real data in them uh those are also faster uh to do and that's kind of the spirit of agile right can we go quickly can we iterate so we can get to something that we can believe in and that we can ship okay when you have all those things uh uh in terms of a wireframe you're ready you're ready to write those Sprints that's the idea

that's a great way to do it um it's very difficult for Dev teams to do that because they're not used to it uh but it is true to the essence of agile okay okay uh you also need that rolling sense of Devon ux that I mentioned right uh we talked about uh those flexible Sprints right if you think of a a Sprint like development being inherently flexible

then why not have Sprints that are really focused on those early activities research sketching wireframes why not we want the developers involved in those anyway so it's not like we're we're waiting for development we bring everyone in right away uh and we're going to be able to produ prod a product that's better quicker right ux doesn't necessarily um uh throw a ton of time onto a process

it does increase process time yes but quality goes way up right so you're still able to deliver quickly within a agile framework but quality is much higher and that's really what we want we want to get to an MVP product that's really strong should be as strong as we can make it and remember we said ux is sprinting ahead and doing these activities developers by the way

should be reviewing everything ux people do remember it goes both ways a developer needs to look at this stuff because you need to think about feasibility and you need to think about performance and all the millions of things that developers have to care about when we're planning something you can't just let ux people just go off on their own and make something that maybe would never work

or it take too long or kill performance Developers need to be there right ux reviews development that's what we've been saying you compare what's happening against ux requirements you care about faithfulness to the design to the goals to the user right we're thinking about interaction we're making little adjustments because we can never plan for everything we just can't do it uh so we've got to think about

making adjustments along the way we got to think about digital accessibility you know making things okay for people with low vision no vision motor control problem all this sort of stuff and of course you're building a design system as you go right and you need everyone involved in the design system certainly not just one group not just backend developers or not just uh the whole development team

along with frontend people you need everyone for that it's no wonder that we make products that are difficult to use when we just Silo out of course that happens right um you you must have ux into your process by ux now I'm thinking about you know the designers the ux pros right maybe it's the strategist maybe that's the micro copywriters all those different people and you might

not have access to all of them but at least one right you need uh their job will be very will be very difficult for sure um but you need that presence okay ux should also be testing helping test uh how you're doing um QA testing or whatever you're process is ux people look for different types of things they're comparing the system the final system against ux requirements

uh they're thinking about user Behavior Uh they will find things that other people won't and that's the point of testing to find things okay now in terms of Ceremonies right with you uh with um with agile everyone calls their meetings something different okay but let's just be basic about it right if there's Sprint planning okay the ux lead the lead ux person needs to be there that's

easy right now whatever you call that person we call that person basically that the lead product designer they need to be involved in Sprint planning easy okay uh stand-ups standups have to include everyone who's working on a thing that we're talking about that's easy right so that may include uh the lead product designer it may include uh a visual designer or a frontend person or maybe that

mic copywriter if they're working on a Sprint they should be in the stand up if we're talking about what went wrong and what went right well you need the ux lead again but then you need those sector leads right who is in charge of design or who was in charge of front end or who was in charge of uh content strategy what did we do right what

did we do wrong right they need to be there if they're not you'll never out okay now the question here becomes what ux Pros do you need and you see my my previous uh slide as a unicorn here uh a lot of times we look for a ux pro and expect them to do everything uh that's very tough one is better than none but you do need

more than one person so let's talk about the types of people you need right this is like a sample full project team it's very very loose okay uh It generally has these types of people okay but the people I'm crossing out are the people we hardly ever have on a team front end interface designer ux Pro content strategist they're hardly ever on a digital product that's why

these products are poorly designed and hard to use those people aren't there um now there are various types of ux roles when you just think about that ux Pro all right we talked about that ux strategist this might be the person who is doing a lot of the research and goals and objectives and linking user based design to corporate or organizational strategy that's a specific type of

person um and the ux researcher they they could be the same person that's possible the product designer this is the person doing the wireframes who's really turning that all into in an interface and can really uh talk back and forth of the whole team about that structure then there may be a ux designer developer this is typically now what we think about when we think about someone

who's doing visual design or front end or both okay these are the core types of people that are on a ux pro team to this you might add visual design to this you might add a Content strategist or uh micro copywriter things like that okay but the foundational role you cannot do without is that product designer that person who is making that interface happen who who probably

in your or has to do all the research and has to do all the strategy and has to do the product designing it's it's too much but this person is a person you can't do without and often they end up doing more okay and of course the question now is when is ux done and and by now you should know how I feel about that okay we

have to redefine this notion of done uh because ux isn't done when they throw something over the fence all right to a development team because there's guidance to happen during development there's user focused QA testing there's even thinking about what does it mean to roll out an MVP to people and have them understand even the the experience of the roll out okay there's much to be done

uh and this means ux isn't actually done all right some of the most important things a ux team could do are happening in the later stages when they've done all their initial work and also a big part of what we have to do is user testing uh if you're not doing this you need to do more of it uh this literally means having users just try to

do what they need to do with your system it's not the same thing as QA testing or unit testing or whatever this is actually watching real users try to do stuff like a scientist you watch them and you can test you can test with prototypes you can test wireframes right even before it's done you can test it but we're talking about something in production uh that you

should test and see if you really did it or not because there's always something you never get everything right okay and in this case if you're doing user testing having people try your product once again same theme everyone has to be there your lead development resource must be at user test must be at least observing what happens uh there's nothing like watching users deal with the stuff

you make because when they fail and if you see them fail all the time it's just true there's a problem with your design there's a problem with what you did and no matter how much you loved it no matter how much you think it was right if it's wrong it's wrong and if you see it firsthand in a test no one's going to argue about it you

all just saw it right and then you work on it now we typically uh if we do tests we might do a lot of documentation documentation is for stakeholders and leaders and smmes who need to be proven to right they need to be convinced uh that testing yielded something but most of the time if we just had uh if one a developer and a ux pro you

and me we got together and did a test we would see in a day all the things that we have to fix and a discussion would tell us what we had to do um when we create documentation like this is because we're trying to prove to leadership where they need to go and they and we need them to agree with users right so we put forth documentation

oh look uh this did well and oh look this didn't do well I guess the I guess the evidence is there we better do it that's what that's for okay now some things to keep in mind as we wrap up and I appreciate all your time today remember that ux Iceberg right this uh this sense of what happens up top the UI and and developers kind of

think below is the system and ux people tend to think below is the ux right well they're kind of both right because below the water surface the greatest part of the iceberg is all of the thinking and planning that goes into making something right and there's a lot of that there's a lot of that in the development side there's a lot of that on the ux side

when all a said and done the little itty bitty part thats with that's the UI we're doing this together right ux and development are not separate things and you shouldn't think about them as separate things you should think about it as product development as digital product development is one thing it's thing uh processes in development they're all very different we are as a consultant company right we

we work with a lot of development teams and and no process is the same but principles behind it the stuff that I'm talking about today they they never change they cross all sorts of processes and I should mention that you can learn this I just I love that you're here in this session you're curious about it you want to do it better this is a start you

can learn about this stuff all you have to do is be curious about it attend conferences like this and move on so I have a little bit of recommended reading for you to get started here's a few good books right if you're interested in how ux fits into product development how we make usable products but think about a development context this is a great way to go

these books are excellent I'll leave it up there just for a second subject to change Sprint the ux book fantastic stuff you could always read our blog I mean we're not selling anything but we're talking about why development centered approaches fail we talk about the myth of Copus we talk about ux and agile right we talk about a lot of things that you might care about associated

with how ux should all these principles that we're talking about okay well thank you so much uh that was building ux uh into development process my name is Dean uh I'll I'll entertain a few questions right now uh but if you don't get a question answered and just want to chat you can find me in LinkedIn uh I'm very happy uh to go ahead and to uh

to help you out in that way and have a conversation with you this is this is tough stuff uh but I promise you can do it so thank you very much for listening and I believe now uh uh if there are any questions uh franccesco I'm I'm ready for you yeah yeah thanks thanks a lot Dean for for the presentation very useful very usually on these type

of things it's a lot of uh in theory should work like this and it's like yes it's common sense you know it's like it's a logic company should work operate in that way it's hard to do I'm cheing if we have yeah it's hard it's super hard okay I have one question from Martin uh he asked any hints on how to deal with leadership that doesn't value

ux enough to provide the necessary resources yeah uh very good question uh and uh unfortunately Martin and I get this question a lot um uh there's two things you could do okay uh first if if leadership is not going to invest in ux then it's going to be nearly impossible for you to make the type of uh uh wonderfully usable highly functional products that you want to

make okay that's just we just need to accept the fact that that's true however uh there uh let's say you're committed to your organization and you really want to help there's lots of things you can do um any anyone seriously interested in ux uh can can learn more and slowly start to push uh one of the best ways that almost any anyone can start to push on

ux is to do user observation and user testing anyone can do that stuff uh user observation watch users attempt to do something and record what they do be a scientist user testing literally have users use the thing you make or have already made uh have them go through tasks like a scientist you watch record what happens anyone can do that and that starts producing knowledge uh that

maybe maybe your organization will begin to accept Okay th that's those are two things you can do but I'm not I won't tell you that that's going to be easy right you have to you have to understand that if you want great usable products the the path to that is very long and very tough if interested um I hope that answers your question the uh the other

uh question I get an awful lot is uh what if what if we don't have access to users it's a similar kind of question either ux isn't valued or I can't get to the end users um same answer uh if you can't get to end users first of all you should be constantly constantly trying and asking and pushing for it that's one two if you can't do

it then get as close to them as you can uh if if all you can get to are our subject matter experts do all of these um uh tactics observation testing with them okay do the best you can starting and doing a little bit is always better than nothing cool I hope that helps cool yeah yeah it's it resonates a lot of things like um when you

say about Des sign in ux I'm thinking on community if the company doesn't invest in community it's a little bit complicated to make them convin in this case it's the same if company doesn't want to invest in design and and and user experience it's a little bit complicated to get that done yeah that is right that's right yeah anyways uh we are finishing we are a little

bit out of time uh I I like to keep the schedule nice tight and tidy uh that's because I'm I'm usually runs from time to time online events and I know how uh organization struggles with schedle and and timings uh appreciate a lot the the talk de I I think that the the the description and the presentation was super interesting um we'll keep in touch in any

case um and and thanks again for the Pres for the for being here at the devs pro uh next time we need to drink a beer in vus or something but uh at this point I'm G take a coffee I'm gonna take a coffee after this session uh for the are the for attendees are still here with us uh this is the last session we are finishing

for today um we continue tomorrow on online mode and on Wednesday and Thursday in person at Lithuania in vus so stay tuned and don't miss uh any update that we have for this event thanks a lot again see you bye-bye