Working as a frontend engineer, the best experiences I had were when the design/UX people were part of my team, sitting by my side (literally or virtually), and I could easily talk to them while developing the feature. It allowed for quick discussion and feedback that enabled us to create good features. In contrast, the worst experience I had was when I received the UI as a defined, completed product that I should simply implement, created by someone on another team that I never had a chance to talk to, delivered to me by someone else - an analyst. When I got to see the feature, it was already too late and too much friction involved to provide feedback, which meant that a lot of things were delivered with UI/UX problems that could be easily prevented otherwise.

I worked on a team that closely resembled your first example. The lead would furnish incomplete mock-ups with incomplete views and no state transitions to other aspects of the UI.... When I asked for clarification on what features or transitions he was expecting, He would respond with long rambling diatribes about what he thought the ui should look like (more look and feel than true UX specifications)... In the end, I made it work and I gave him what he SAID he wanted but he complained that the final product wasnt right. This was WITH me providing updates to help him solidify his design choices. Sigh... Anyways, thanks for describing this antipattern and helping me reconcile some of the difficulties this antipattern entails. Another well thought out video!

This makes so much sense and it also explains why Startups seemingly get so much more done then comparable teams in bigger organizations. The tighter the design and development are the easier it is to publish meaningful features.

This video reminds me all the people that asked me "how much it costs an application like this?" while are showing me screens of another app

6:45 Seems like that's the goal of most software development methodologies, to turn the "software engineers" into natural language compilers. All while they ask you to be "innovative."

A UI mockup passed on to a development team does not mean that the requirements are now written in stone and cannot be debated. It’s up to the developers as stakeholders to also push back and open up for a discussion of the spec, if this doesn’t work out. This is how a good team works. All feedback is valuable.

The separation between Frontend and Backend has become more common in projects were they believe this specialization make work more efficient. But I think it divorces the backend developers from seeing the bigger picture of the product that they are working on. My experience is that frontend developers might have to wait for the backend developers to be finished with theirs before they can proceed. It seriously affect the quality of the product for people being silo:ed like this.

My team was in that situation last year. We were only given screenshots. I convinced the team to switch to just specifying the problem and suddenly the entire team was just flowing. It's way more important to make everybody understand the problem over throwing UI mockups over the fence.

All I can say about this video is, "HELL YES!!" I haven't had this discussion with a group since this morning.

favorite quote: "The best solutions are achieved when we can iterate towards them as we learn more."

This doesn't work when product development and UX feel that they dictate the exact look and function of the product and that development is only there to bring forth their creations.

Thanks for the content, this was really informative and will help me to highlight pitfalls that I and my team are currently falling into. Subscribed :)

Also I have crossed path with many so called Tech directors that wants to "protect" devs from UI or art people. Who does not still seem to understand the way of prototyping, mocking up and funnily many of these are self proclaimed Agile specialist

Bang on. Cannot count the amount of times this separation has caused atleast serious problems in delivery and delivery quality

It also makes aspects like plausibility checks being spread through all layers of a system. Been there and experienced the aftermaths of it. The UIs I have seen in my professional career lacked consistent and correct multithreading and the issues arising thereof.

really good point about design vs. requirements. it's very recognizable, when the client is trying to be the designer. i've found that it's better to start the design from the database model, rather than what the screens should look like. although nothing is of course absolute, and there can sometimes be some useful design ideas in just picture of screens that need to be taken into account, when evaluated carefully

At my former workplace, I too received static UI images to implement. After much frustration I could grab the designer who made it and conflicted him over the edge cases; "Oh, I see! Oh!" were most of his replies then we worked together. And we had an excellent time and ironed out problems in half an hour! It's silly looking back, how it couldn't have been commonplace as it saved so much time. Probably it was the mistake to save money on designers and waste it on development time?

The aspect not mentioned that I see is test design being driven by UI choices. In my experience this often leads to a test suite that is fragile and on failure raises errors that are difficult to diagnose and fix.

Right now I'm working as a front end designer / developer. I work with a bunch of back end developers and database experts. I am upgrading our old coldfusion website into NextJS. Our current workflow is I design the website for mobile and desktop. When approved I code out the html and css. I hand it to my nextjs developer and he migrates my html/css layout into NextJS and tax. The site is coming out great so far. It looks exactly the designs I made to the pixel. I'm very proud about that. What I want to do next is for my coworker and I to share the NextJS project and I will continue to do the front end and he will take care of the rest.

Great video! This is default for many organisations I've been involved in. Separation between UI/UX designers using tools like figma, Front end developers using tech like react, Back end developers API and Db. I've even seen all these roles in one SCRUM team! Great content as always 😁

Sounds like a more specific form of one of my common mantras: "Describe me your problem, not your solution"

With the startups I've worked at, we were small enough that our development folks had to do the UI design. Fortunately I'm not just a systems engineer, I'm also an artist who also had a deep interest in usability. So I studied usability with Alan Cooper and also Usage-Centered Design under Larry Constantine. Without an integrated usability+design+development team the outcomes are much poorer! And bad design and poor usability implementation are so costly! They definitely affect not just product acceptance in the market and make the sales process so much harder, but they bring higher error rates, longer and more complex training, and poor content retention.

Of course with proper UX desing, you not only create views, but also the entire flow, including error conditions and recovery. There also is the discipline of UX engineering to guarantee feasability of any design. The problems you mention do not come from the workflow organisation, but from the capabilities or lack thereof of that design team and/or the product manager. You would also test the user interface before handing it off to devs to ensure it works and meets the customers needs. Creating and testing interactive high-fidelity mockups is way more cost-effective than to have the developers code A/B versions and do many iterations on design.

Dave, I love all your videos, your content was a great influence for me. I especially enjoy details about working with TDD, especially TDD with examples. There' just one thing I'm struggling with. I'm pretty confident, I know how to write a module with TDD in mind, from scratch. I never use global variables or static context, and I know how to recognize a library trying a little too hard to couple with my code, and I know how to fix that. But there's one thing I'm missing. Imagine I'm writing a text editor, which supports formatting. Let's say I need to add a function to make text bold. No problem, I know I should start with the simplest case, where a whole document is one word, I make that bold. Test passes. Then I make two word editor, I make only one word bold with selection, test passes. Then I don't want bolds to stack, so I write a test, that a bold word shouldn't be bold again. I write all the necessary test cases. After around 100 test cases I'm happy that I have a properly working bold feature with all edge cases handled. Now here's the part I'm struggling. If I want to add another feature, like maybe a table or a list, and I know that it will be similar to the bold feature, but not very much; should I start it from scratch? For example, imagine I have 100 tests for bold command and it works great. I try to write the first test for list, so I create a document with one word in it, and i try to make it a list, and at first it fails as I should. I'm in the red phase. TDD says "write the simplest code that will make the test pass", I can do that. Then I add another test for list, and then another. And I'm finding myself in a place where I have written the same logic that I did write for bold, so I have duplication, and TDD says I should remove the duplication, so I do that. After 50 tests written for list, my whole list implementation is simply reusing logic of the bold (so production code doesn't have duplication), but the tests are still duplicated. For example, I don't want the user to never be able to bold and image or make a list of an image. Should I write that test for both bold and list? What if I add more commands, like italics, quotes and underlines. Should all of them have duplicated tests? i.e. "don't bold in code, don't italics in code, don't underline in code", and also "don't bold in table, don't italics in table, don't underline in table"? I mean, I know it doesn't make sense to copy all of those tests, because I know that the logic is probably reused between those commands under the hood, and only details are being abstracted away; but my tests are still duplicated. I know that's not right, but I don't see what TDD law would make me skip those tests? Let's imagine other alternative, where I have 100 test cases for bold command, and I want to create my list command. I write the first test for a document with one word to change it to a list. Maybe I should reuse the logic from the bold command right away? But that doesn't sound right, since the second law of TDD says that I am not supposed to write more code that it is sufficient to make the current test passing. And clearly writing one line of repeated implementation is adding less features than reusing code from bold, right? I mean, if I reuse code from bold right away, that makes the list command more things that there are tests for, right? So ultimately that part of list command which are brough in from the bold logic isn't tested, correct? Or am I missing something? I'm a big fan of TDD, and I really enjoy using it, but I just can't get a good grasp of this idea.

This is an excellent example of working with enabling teams, thanks

We split by domain. So we do FE/BE (with a UX designer assigned to the team) if that is part of our domain. The UX designer may be full-time with a team, or a few teams, depending on the workload. I find this is far more productive than teams split by 'technology' or w/e.

integration of capabilities (UI, UX, backend) is essential to get more optimal integration in the outcome because the tasks required are now considered within the whole context

There's also the separation of UI and UX - which seem to be at odds with each other more often than not.

Frontend and backend applications are operationally distinct applications. Frontend runs on end user devices, backend runs on physical or virtual "servers". Team wise, it's essential that the organization's communication patterns help to understand this operational distinction, and build a contract-based, versioned interface between them to support reliability. The "wall" image indicates a problem with organizational communication patterns, not a problem with technical distinctions of software. You might be thinking "frontend has to get hosted too". Yes, it does. But the non-technical business user doesn't directly interface with the backend server (whatever it's hosting/doing), they interface with the user interface presented on their end-user devices (eg. a frontend application running in a browser or a native app which they downloaded/installed/executed).

Great video, digital agencies love doing it this way (the UI enforced design), I think because they can charge clients in stages. It causes no end of issues due to misunderstandings from both FE (where FE was split from BE) and UI/X workers about the what the data they are attempting to display actually means or is for. Another problem I have come across is a lack of education of researched science in UI design courses. I have come across multiple graduates who didn't know what a mega menu was or why it was a good idea or even why menus are always along a edge border with the most important/largest change buttons in the corners.

This explains why I struggle so much with modern software. I often can't develop a mental model that is consistent with the software's behaviour. I spend so much time trying to understand how the developers (or UI team) intended for the thing to work, and often can't find an answer. Eventually I work out a process that gets the desired result, even though I don't really understand the underlying logic. Yuck.

@ContinuousDelivery I'm curious to see the guides referenced at the end of the video, however, I don't see a link in the description to How to Write Better User Stories.

Funny how apart some app or web or well software development seem to be from say game development. Where even back in the 80s it was natural to have the core team together. As they was so small. Of course now in AAA projects of 500 people you have specialisation still the core group is one often of UX/UI/Art/Animation/FX/Sound/Gamemechanicas/Level design/UI devs/Engine Devs/Backend devs/Gamplay devs are together. I think are more fitting title would be "the biggest problem with role specific silos"

The problem is more related to the rise of web applications using html running in the browser as the basis for most UIs built today. Using HTML as a UI language created the distinction between older "functional" UI models used in MFC for Windows, XWindows for Unix UIs and other form based frameworks of previous eras. Resulting in web design as a separate body of expertise involving more creative elements such as graphics design, color theory, pixel measurements and so forth. Then on top of that there are other elements that came into play such as ever more complex frameworks for generating HTML using css and javascript with ever more frameworks. As a result requirements for web development got split between Web/UX design and back end design elements and along with that came a split in responsibility and skills between the two. And a big reason for this is that companies care a lot about their branding/marketing and designing/redesigning the UI takes on a big priority among many companies, separate from the overall software development process and back end logic. Often they will even have different companies doing the work between front end and back end since often times back end software is built as a service.

Would I be retreading old ground if I suggested a system should have a catalogue of well-defined Actions/Events to record and update data, and a catalogue of read-only Views - the system design is to capture what actions the user needs to perform (& what data goes with which action, what's validation, what gets retained and what gets discarded on invalidation), and the UI can then be built as a second step to operate the Actions and receive and present Views? (context: in my last job I made a strictly unofficial Python console frontend for Flashy Enterprise CRM, built against its internal API, much as I described. It was I believe a fairly conventional three-tier system.)

So the vid started talking about the split between FE and BE devs. Then it focused really on the split between FE and UI/UX. Bew interested in your view on the FE/BE split as well.

This makes some sense, but it's also using dated ideas of what UI/UX design looks in recent times. Visual tools of today are producing prototypes that are not static, include interactions of high fidelity, and the are organized in a way that is way closer to way code will be doing it in the actual implementation. So while on a macro level this video makes sense, the continous communication of design / dev team is in fact valuable, the details are kinda wrong.

As S. Jobs said: Design is not just what it looks like and feels like. Design is how it works.

I work as a C++/Qt developer right now (and have at other places). In most of my instances, the devs (me) have never been asked "please help design how this UI/UX workflow should be", it turns just into "implement this predefined thing by someone you've never met". It always turns into a disaster. Other than implementing widgets, I try to think about the UX of a product because I know no one else usually is. Where I've been told to "put on the blinders and do as your told" has always turned into a disaster. Some places have let me catch potential issues, other have not (which later became real ones). I'm glad I'm currently working at a company that also let me design the UI/UX of the product from the group up. So far it's gotten rave reviews from customers, management, third parties and the like. I'll admit a lot of programmers don't make good interfaces, but fully offloading this crucial work somewhere else causes long term problems.

i kid you not: we started a webshop implementation and when asking any requirement question they refered to the redesign project that went before us. "just make it work like in the mockup renderings". smh. i jokingly refered to this approcach as "specification by pixels". needless to say the renderings not even covered the "sunny path" well enough to draw any conclusions. what a joke

Our team has been working the exact opposite way we build the science/engineering models and make them work, then define a programming interface for them with dataclasses, then start designing some of the visualizations and then we work with the UI team to create a UI for it. Having the UI team work first just wouldn't work because they would have no idea what features the UI would need to control the model and until we build the model we don't know what it will need either.

I'd say the exact same applies for "backend" vs "frontend". That in such separated set-ups, "frontend" is either just an extension of "UI" or that there now are three teams and stages: UI, Frontend, Backend. Which is even worse than 2. I see this distinction even more than UI/Backend these days. How can this be solved? Must it be solved?

Great session 🙏 Thank you.

Mixed on this one. Agree with some not others. I have found UX mockups a much better way of communication than words (a picture is better than a 1000 words...). Also the end user can interact and provide feedback much faster to a mockup than waiting for a build. What I think the problem is your (and my) experiences of being given a picture as specification, rather than as another input for solution design. I also think you over estimate the ability of the majority of engineers to create effective and attractive user interfaces. Remember most engineers are not like you with decades of experience to draw on. A designers who has no experience of solutions being built but expects a like for like translation from a picture to HTML is the anti-pattern in my view.

As a professional graphic designer who turned to software engineering for more than 10 years ago I can now say that elegance sensitivity is a rare skill. Elegance is all that’s best about both worlds. Elegance in code is simplicity and intuitive api design. Elegance in user interface design is simplicity and intuitive graphic user interface and user experience design. So few people understand both and let alone can gather the skills to bridge both worlds in a harmonious way. That’s why it’s so valued and that’s why apple is the most valued company in the tech world. Not even with design systems and high end component libraries can most software engineers put together something enjoyable to use.

Lots of excellent points as usual. And thanks for speaking of UI when you mean UI, rather than UX as so many do these days, maybe because they think it sounds cooler. But the difference between UX and UI is another blind spot that I hope you may want to address some day. There was actually some real thought behind it when the UX movement began, and they needed a new term precisely because they wanted us to think much more holistically about the user experience - across all interfaces, including those that exist off of screens (say, receiving the package you ordered in the mail, or being in touch with customer service by phone). Many companies outsource sales, for example, and do very little at all to think about, never mind attempt to *design*, the actual experience of becoming a customer, starting to use product A, then adding in B and C, then discontinuing A. User interfaces are of course an important part of the user experience, but depending on the service and the user, it may include a whole lot more. Interface is just literally inter (between) + face. Internet means "between nets", international "between nations", interface "between faces". If you need any help remembering that a user interface isn't simply the look of software on a screen, allow me to mention a quip from a friend back in my university days: "I don't like horses, they have a terrible user interface!"

Where did you get that tshirt? That is awesome!

I guess it boils down to a certain lazyness of the involved people (especially management and product owner) who should focus on WHAT (feature) to achieve (which generates business value) rather than going the (mental) easy way of getting just some nice pictures where much of the complexity is just not covered. So starting from a requirements and user-story perspective and THEN handing this to the UI/UX/Dev people would allow all of them to use their full potential for creating a great software. So 100% agreed.

That's the main reason why I decided against CI/CD for my company. The risk is enormous (and still underestimated) and the benefits are in comparison to small.

Even worse when you have a legacy domain model that you can't change without breaking other things, and you have to do ridiculous gymnastics to paper over the difference with the domain model the UI team wishes you had. And then you have to keep the old crappy version of the UI around indefinitely because there are states in the old model that are not representable in the new one and vice versa.

Thankfully, not an issue here (I am PO at Deutsche Telekom). My scrum team has FE, BE and a designer in one team. We refine together, we align, and we amend initial UI designs were necessary. This video kind of gives me a good feeling about how we are set up currently.

I have a hard time picturing this in practice. It requires both the ui designers and developers to want to learn skills beyond what they initially want. At the same time I feel the immense struggle it is when ui and Po just sit down and get this amaizing ui put out but then forget small key things that then break the entire ui and they have to start from scratch or force it upon the devs. You have given me something to think about with my own team. First initiative is to bring in a dev on the ui faster to brainstorm UI and maybe cut corners that will speed up the development.

Do you have any recomendations about coordination of frontend and backend development? Assuming we have to implement new feature which involves implementing new webapp component/page and new backend api, and both front and backend developers work in the same team (which is good practice I guess). Do you prefer frontend, backend or api schema first development? Or maybe when we work in small batches it doesn’t metter? Would you start development writing acceptance test which goes through ui oraz api first? Starting from outside (ui) or implementing domain in backend? Do you thing consumer driven contract testing is usefull between frontend and backend? In one of your talks you showed that in your project you had acceptance tests which could go threw different interfaces, like webb app, internal api, public api, etc. Do you prefere to test all scenarios through all interfaces, or only small subsent should go through ui, and most of it through backend api?

Programmers being experienced as users from a UX perspective is so true. Be it the Jetbrains tools, (neo)vim, VSCode &c., there's so much complexity in all the tools we use. A bad plugin in either of these IDEs with horrible UX is extremely noticeable once you use them in practice, and there are so many examples, that it's impossible not to learn a good deal about the good, the bad, and the mediocre of UX design. Plus, of course, the ugly 😎

6:17 I very much agree with this. I have a sense that product owners are generally not trained in software engineering, which leads to a few extra problems. They don’t have the needed skills to make good software architectural decisions, and ultimately force the development team down paths they wouldn’t ordinarily go down, and designers are easier for the product owner to communicate with because there is less of a skills gap, so it’s much easier for the product owner to direct a project that way. I think product owners should generally be skilled in software engineering, and the less technical skilled people currently in product owner roles should become key stakeholders of requirements. I also think separated backend and frontend teams have created some odd choices in the frontend frameworks, which is why we are currently seeing Server Components pop up and marketed as a new concept as if SSR never existed. I honestly don’t know how you can efficiently create front end UIs without also having the ability to create and modify the backend. It’s always seemed odd to me. Probably why solutions like GraphQL exist too.

The first set of solutions are what is taught in universities. That's where the separation of UI designers / coders comes from. 1 teacher teaching 1 specific set of skills, in the UI pathway. The second set comes from actual work experience.

The way I see it, it should all start with the UI design by the designer, which then gets passed on to the frontend and backend programmers, who should be refering to the design to know what should be developed. That way the backend programmer knows what API endpoints are needed, and therefore what features, and the frontend programmer knows what the frontend should look like and do. And there should be meetings to clarify things so that all are aligned and have a clear understanding of the same features.

Couldn't agree more! Great video as always!

Imagine software was buildings. You've got a lot of people who think they're architects when they're barely interior designers. They don't understand how a door works (or how big it should be & where it should be) but they know what colour[1] they want it painted and they don't want handles because they spoil the flat look. [1] always a slightly blueish grey, with signage (if any) in slightly greyish blue.

Thanks for the video =)

Delivering MVP is working pretty well here, as well as it is tackling the often tedious estimate work. Meaning you may get a full feature assigned, but you aggree on deliver chunks of it for revision. UX people also make " bugs"

Front end is "OwO", back end is "Oh no!"

I know exactly what you are talking about. Unfortunately. But the UI dictate workflow is still one of the fastest ways towards a POC and/or an MVP. Unfortunately many systems remain in that phase decades in production. Also, the form validation issue we solved by either by clarifying the criteria or have it as dynamic data. That way, very little data is getting from the UI to the back which is not valid... Unfortunately "already exists" can only be tested on a couple of pages on the clients computer :D UI can be looked at as a service with inconsistent storage and synchronous communication. Technically the worst microservice you can think of.

First off, I just watched the first minute, and it seems a feature of a system should always be concerned with the solution it's trying to solve. The UI and the backend expression of this fundamental purpose should be how we do things. In some cases, there are obvious limitations of the technology that prevent us from solving the problem exactly how we would want to. I agree to the basic premise that the UI shouldn't drive features.

This isn't even a UI development problem, but a wider one across the entire project and even industry.

Worst design feature I can think of is allowing anything to be displayed on the screen only to be moved .0001 seconds before the user tries to click on it. Don't put it on the screen until you know *exactly* where it is going to be and then display it.

I honestly think that this very interesting video fails in clarifying that a UX designer is not just a UI expert.If we are just talking about UI interface I can mostly agree, but when it is about UX design it is a very different story because good UX is mostly about building and preserving that mental model. Therefore mental model consistency is definitely cross-features within a single experienced product; and expecting that streamline autonomous teams contributing to that mental model without cross-colaboration, without agreed user journeys and some sort of UX governance (I am not talking about UI design guidelines or design systems, for God sake) is among other things a good way of getting a fragmented (maybe even broken) mental model (and therefore UX). I fully agree though that UX is impacted by the whole system behavior and its touch points. It is a responsibility of the UX designers on bringing awareness about it to everyone involved, so decisions and trade-offs are made consciously. It is pretty much what you say about educating. I cannot agree more on that... but it does not mean, necessarily, that a developer will have the personal skills to design the most user-friendly way, despite he/she will definitely influence it for the better.

So.. this workflow is like "UI team" do photoshop, and then replace the backend team with full stack one, which is just not so good with photoshop.. Right..

What is the percentage increase in cost with enacting this integration of labor?

The UI/UX team have to either have knowledge of how its implemented or there needs to be input from at least one person that does when creating/changing the design. And that person has to be strong technically. Without this, UI/UX just gives you pictures and the people looking at the pictures just see it as boxes on a screen and moving them around or adding/subtracting to what's on the screen is "easy" because to them its not a big change. But without knowing how the UI is actually implemented, the amount of work involved can not be judged. When they then huff and puff when team gives them what they think is the size of the work involved, they get questioned and pressured to squeeze it into less time. This causes rushed implementations and bunch of things get missed or broken or the software design gets fragile. For good system design, the UI needs to be intuitive and/or instructive and there needs to be a layer that makes the UI and backend efficient if the backend was not designed based on the UI needs. When the UI model of the system doesn't align with the backend model of the system, trying to make any feature change is destined to be harder than it should be. Too many compromises end up getting made in that situation.

We end up with a ui / backend seperation because the ui technology was perceived to require specialists. Is that because the JavaScript ecosystem is a hellscape? You bet it is.

This has been my experience, when there are UI/UX designers who pass off detailed designs the UX is always worse than what developers can come up with.

As a UX/UI designer I'll never start a project without developers at the start of the process. It is imposible to build a journey map without a valuable opinion of developer team, they allways add such breacking appart opinions that complement my job.

That shirt is so nerd!!! LOVE IT!

For me, the starting point for both UI UX and application layer software design is a business process model (see BPML) that not only expresses the golden path but error and fault paths. The UI and UX will be verified against the BP model as a gate (go/no-go) review. This is not a panacea. Design Review across disciplines needs to be oart of the design lifecycle.

Never had any issues with front-end/back-end dev.

It seems like the lack of communication and broader cross-domain experience/knowledge is the problem. Less so the division of labor and system stratification.

The entire UX philosophy is built on the defect idea that programmers are idiots, and need to be kept apart from the *_"real expertize."_* Programmers sometimes might be idiots, but not regarding program design nor programming, we're rather idiots when believing that people want to know about technical problems ASAP. Bad user interfaces are usually rather the result of a bad organization.

You get somethings right like it should be a collaboration between designers and developers not just a transaction of deliverables. But where I disagree is when you suggest developers should be prepped to design(define) UI cause they have much knowledge about hpw UIs work. Here lies the fundamental conflict: "You are not the user." You here refers to the developers, the designers, the business executives and everyone else. Your knowledge of UI doesn't translate to better user interfaces (unless you are designing for othrr developers, even then there is a gap) because of the difference between the users and your mental models (developers make a living thinking about implementation models while users want nothing more than the simples mental model to understand how to use the thing), abilities and motivations. Designers are specifically trained to how to bridge this gap with research and translate the research findings to user interactions. Also Ux design is not just visual design but interaction design, information architecture, design patterns, behavior patterns, user psychology and persuasive design, resonsive design, ux strategy. Can the developers do all these? May be the rare 0.01 percent but vast majority of developers don't even do a really good job at development how would they take on these additional responsibilities. The tragedy is most designers don't carry on their responsibilities either. Most designers even at the senipr level are still amateurs. The solutions I think is more accurate and comprehensive tools for product specifications. Mock ups are just 5 percent of the specs at most. Also designers have to be exhaustive about their designs and immersive collaboration between developers and designers.

Thank god I never worked on a team where the UI/UX design folks are not part of the overall solution, or totally separated out. Often, the UI/UX folks are even a bit more involved in the requirement gathering than the front and/or back-end developers. UI/UX should indeed be part of the *entire* SDLC, iterating over what does and what doesn't work, working closely with front-end devs, keeping an eye out on what problems' the software should solve for the user. For alignment, a well designed design-system and 'pairing' and coaching by UX/UI folks when needed, works best in our teams. The devs, that the UI/UX folks interact with most, have deep experiences in front-end development (web, native Android/iOS, x-platform framework). And front-end devs can teach UI/UX folks a lot about the (in)capabilities of the front-end tech (web, native Android/iOS, x-platform framework) . In short, UX/UI folks need to work closely together with at least the front-end devs.

This is the reason I’m a “Staff Fullstack QA Designer”.

UI design is unique amongst the design fields. A print designer needs to understand the print process. An architect needs to understand how the building they are designing will be put together. Automotive designers and product/hardware designers need the same level of understanding of how their designs will be implemented. UI designers often know very little about how the things they design will be built. The age of the non-developing Ui designer should come to and end. That said, the absolute worst UI designers are back-enders. And UI Frameworks are making everything worse as it reduces UI/UX to "design only", which it isn't. That's why so many projects built with Material UI rely so heavily on modal views and forms.

I'm a technical UI designer for a living and I think I'm the solution to this problem :) I bridge the gap between the coders and the artists. In my experience you can't let either team dominate production because they both have their pros and cons and, without an intermediary, you can never obtain the best of both.

the last comment on user interface expert is absolutely right..

In my experience as a UX Designer for more than 10 years the assumption that developers use a lot Interfaces and can therefore bring a lot of input to the UI Design part is basically that: an assumption. I have never seen it work, and in the situation where developers could actually make design choices, they ended up designing UI „from developers for developers“. Please leave the actual work of defining user needs and visual design to your trained professional colleagues in the Design Team, or next time we want to have a word in system architecture because we designers also work a lot with unresponsive software full of flawed business logic, and therefore should have an idea what good system architecture should look like 😂

As a UI/UX designer with 25 years of frontend development experience, I do not agree with several things in this video. What I do agree with is that having barriers between development teams and UI/UX designs is stupid, just like having any barriers in the build process. Collaboration and communication is always the glue that make things come together. The first thing I object to is that UX and UI is the same. It is not. The example with the form is a UI design without UX for example because no UX designer would ever sign off on something as horrible as a form that clears when what has been filled out does not validate. It should be noticed though that many times this is NOT something that the UX designer have designed, but rather that the development team does not build what the UX designer designed. This is VERY common when you have a detachment of work and handover processes instead of collaboration. This is not because the developers are evil, but because they feel no relation to the design, and they don't understand the reasoning behind it. This is the same problem as having business need handed over without context or involvement in general. The second thing is that designs ARE visual requirements, and they start as business needs that are refined and tested until they become a proper requirement. As with any requirement, they are not static, and they change as we work with the solution to adapt to unforeseen realities during development. Also, as with all requirements, they should always been created together with development and test to ensure what is being designed is feasible within the limitations of the system. Handover is to the frontend developer and they in turn will work with the backend developers to ensure the technical solution to present things in the frontend is both feasible, but also placed correctly. Some things can be done in the frontend, but should be done in the backend for performance and security, for example. As you describe, UI and UX design are enabling, just like requirement analysts are enabling by helping to clarify and visualize the business need so it can be realized. Teams should NOT own design of any sort. That is an antipattern that is detrimental to create a unified design language. Design should be set on the enterprise level, so all teams can create code that is modular and easy to use to quickly create new components without having to invent the wheel every time, or worse...to break the branding and create discourse for the users as they navigate the catalog of services across the organization. This is why we have design systems that are connected to code on organization level and never on team level. So the main problem that you describe is detachment of work and the lack of collaboration and communication. This has nothing to do with UI or UX, but everything to do with the way you work. Failing in the requirement part is the number one source of frustration and failure in building software, and I think most cases fail due to communication and poor work processes with separation of work without proper collaboration. This is something that we should break out from, since not having collaboration or communication with everyone in the build process is very bad. Unfortunately, there are many teams that are the direct cause of this happening from self-isolation due to misguided interpretations of Scrum or even the Agile manifesto. I have made a video for that type of behavior here: ukposts.info/have/v-deo/a3agfKynq5WLpps.html

i was always the guy that tried to make the designers happy. even so, when i worked for a design first agency it was all my fault for not having realized the design perfectly, including all the missing and senseless parts. the design was rubbish. nobody knew what they wanted to achieve or how to achieve it. they couldn't even do the svgs right. when everything was done, backend came along with a bulldozer and replaced all the tricky parts with simple stuff that works and i had to fix everything for the third or fourth time.

So, entirely unrelated to the video, but my partner really wants to know where you get those tee-shirts. Edit: Never mind; found the link in the description

While some good points are made, this really is from the backend out. What seems to be difficult to discuss is that Servers and Humans are each Complex Contexts which need to be bridged. It is not enough for the UI to reflect the structure of the Code. While that is one Truth, Humans process data and operate within parameters which also need to be taken into account. And humans come in a wide variety of models. Some have visual acuity, others operate through sound and so forth. If you think that the only complexity occurs (not suggesting you do Dave, more the general Dev population), within the hardware, software, network and data center, you are missing a large part of the Machine To Human interactive flow.

Why oh why this common sense approach is not common at all??? As a UX UI Designer of some 20+ years I see myself as a navigator on a sailing ship. The captain, PO, sets the course and objectives. I chart the course using my knowledge of the weather and the sea. I work with the mastmen who tell me the capabilities and status of the ship. And so on, in a nutshell. Without my dev team feedback, I would not dream of working on user journeys or process flows. When the mechanism is well put together, the UI designs itself around it effortlessly.

My view is this will get worse, more and more we see teams where there is a back end team, and API tram and multiple front team, and often the later done even talk to each over

It's all about the complexity of the backend data. If the UI designers don't understand the backend data they are not going to create good user interfaces. Not a problem for a Banking or purchase order app but when it is something a bit less bespoke it can end in disaster.

"how can we bridge UI and backend?" UX designers: "Am I a joke to you?"

Main solution proposed in the video is unrealistic, best compromise based on reality is comment right here just next below my comment!

🌟 🌟 🌟 🌟 🌟 🤩

I would not direclty agree that windows have facilitated more innovation compared to apple. If you look at Apple and Windows UI components often its the same feature set (Apple even more so in frontline) key difference was as told in the video. better guidelines. you dont need to follow them but they are there to support you.

1000. like was mine!

The mistake is that in most cases project managers and app architects are inexistant or incompetent.

To be honest, it feels like the whole point of UX design has been ignored here. The goal of a UX team (not the UI) IS to figure out these deeper concerns - how each element should be represented to give the best experience for user. I believe it shouldn't be developers concern to always think about best user practices, but focus on delivering to spec. The UX team should be the one who prototypes and tests design iterations to discover all possible flaws and fixes them. Output might be wireframes, specifications and recommendations. Then, and only then UI team should "make it pretty", but also usable (colour contrasts, clear states, clear visual sigifiers, etc). Figuring the best user experience takes way more effort than is optimal to put on developers shoulders.

Making UI - especially web UI - is so complex now that specialists are required. That said, specialists need plenty of crossover knowledge and teams need to trust each other to make the right translations into their domain of focus. Everyone gets a say, and vitriolic criticism needs to be nil. It's ideal when specialists have such open communication and trust that they effectively operate as a single dev.