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.
This 100%. I try to get involved with both BE devs and UI designers as much as possible, as they are the two biggest factors that impact my work on the FE. Expanding knowledge and content beyond the immediate 'corporate borders' is also super valuable, just creating a better understanding of the system you're working in. Though, it really depends on the company how far you can pry (and sometimes even designers are out of reach). I also feel too often UX is confused with UI design or put into a box of 'making pretty screens'. The problem with pretty screens is that you can design anything your user wants, without limitations like 'what the system does/should do'. Request 'export the entire database' and it's easy to design a button 'export all'. Regardless of whether the technology supports such requests, or whether such a request is even usable by the user. UX is an integral part of all parts in the application - 'how does the system work' in the general sense. Every boundary between layers works together to deliver a product that's nice to work with, AND nice to work in. This is also why using the system you develop is so good, because you automatically get a more complete picture of your app rather than the abstract subset that is your specialized part in the system.
I agree. I'm a frontend Dev and have made it one of my unbreakable rules to iron out potential development issues that design or product had not considered prior to coming up with the spec. It's imperative for a technical member of the team -- a developer -- to evaluate the spec and confirm (at least approximately) whether or not the asks are achievable.
I can tell you that for most designer that feeling is mutual. Being asked to design something without having access to someone that can help you understand the limitations of the system is a horrible experience, and it cost a ton of time when you are forced to redesign things because of it. Collaboration is very important, as is communication.
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!
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."
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.
Startups also carry fewer of the operational burdens of mature organisations. Developers being shafted by nasty code written 5 years ago by the intern is not disturbing them from the nasty code of today.
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.
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.
I strongly believe that he's talking about the separation between the design team and the developer team Like throwing a maquette to translate into code instead of taking the developer advise while making the design so they contribute and understand the system
This can be fixed by creating contracts that are created by FE and BE together where FE can use mocks derived from that contract to develop against. This allows FE to work on and even complete features without having to wait for BE to have been finished.
Driven a lot by recruiters or agents who think it's two different things my niece who is a recruiter when I told here I was a software engineer asked, front end or back end, to which I replied a lot of my software doesn't have a front end
@@terrymackenzie6784 True. And those terms are very contextual. Since they are not talking about compiler frontends but the user experience of a web app, most likely haha 🙂
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.
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.
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.
Yes I think that is the exact problem he is brining up. And same it do not work when tech are blocking some UX idea becuase its not possible to do (and often turns out to be indeed possible but was not understood)
@@3_smh_3 exactly. So instead of collaborating in a more free exploratory phase (with not to many people) they stress and blame each other and start working (with too many people ) on each sides.
That is the much better approach though. Developer time is expensive. The initial planning of a feature and system requires much more than a developer actually knows. If you want to design a login flow you gotta consider Consent levels and talk to Marketing and Legal teams. You have to make sure the designs adhere to the Marketing guidelines. You gotta know your actual customers and business model well. The product lead is the one with the vision - he aligns his vision with the Tech Lead who then brings it to fruition with developers
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?
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.
I agree that teams need to provide constructive feedback when necessary, however I do believe that organizations could benefit from promoting a collaboration rather than a transactional enviroment.
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
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.
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
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.
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
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.
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.
I get them from Qwertee and they offer a discount to CDonYT viewers. 🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3 USE THIS DISCOUNT CODE: ContinuousDelivery to get money off the already reasonably priced t-shirts!
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.
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 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 😁
All very good and correct in my experience. I would add.. Sometimes faithful reproduction of certain separately produced UI designs, can present backend developers with challenges that may require a disproportionate amount of re-architecting, or even be impossible or illogical. Conversely, backend knowledge can often inform what is (easily) possible in UI beyond what had been imagined by UI designers.
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.
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.
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.
Have you heard of refactoring? You're allowed to refactor as much as you want while all the tests are green. If you think there's going to be a lot of duplication in a new feature, then you can refactor your existing code to be more generic before you write tests for the new feature. Then you can make the tests pass with the more generic code. If you have more questions, then you might have better luck asking a TDD trainer. There are lots of them. The rules for this comment section say "no advertising" so I won't recommend any specific ones.
1. Why do you think duplication of code in your tests is a bad thing? It’s not bad. 2. Duplication of code is bad most of the time - when you need to do the same update in multiple places. But, if your code is going to be independent and evolves in different directions after copy&paste then it’s much better than unnecessary coupling. 3. I’m not a huge fan, but maybe something like table tests can help in the situation you mention. If it’s truly the same thing, but you need to test all the cases then it will do the trick. 4. „Laws” - there is no TDD police. You can bend and break the rules. Including the advice I’m giving :) TDD laws are there because they work. But, in some cases they may not. It’s ok.
I agree with the other responses here, my all means you should use refactoring to improve the generality of you code. Treat the tests as specifications to drive design choices, rather than as "proof" that your code does something. Specification is the primary job of tests in TDD, IMO. So write enough tests to specify what you want, if you wan't other parts of your system to have all the advantages of "bolding" and you already have the generic code for "bolding" then I see no problem in writing a test that covers one of the more complex scenarios as a sanity check, but not necessarily repeating every incremental test that you needed to write to achieve "bolding" in the first place. Use tests to aid your ability to design more than as a proof of what you did, leave enough tests in place to show that your result is what you expect. This advice is a bit subjective, you'll need to make a judgement call on if you have enough tests, but if it wasn't subjective we could write code that did it for us 😉
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.
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.
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.
I think the key is the so called hand over. For me mockups in different ways are great. Both visual mockups and tehcnical functional mockups / prototypes. And both needs to be tossed away. They are not part of the product, they are part of the discovery that will lead to the product. By doing so many tech issues can be found early on. Performance issues. Or simply the realisation that what looked good on paper do not work in reality. Problem is that this phase takes time. or is seen as taking time. And just mentioning to some that this work as a function will be tossed away (or not used in the end product) but only the learnings or the specification from it will be used. I find it so odd. And yes I agree totally about word sucks. The closer to the reality you can get withhout it being the reality the closer the reality will be. Also it mean that it can be validated functionally as early as possible for all roles and function as a communication material. A bit like the classing "plans are worthless but planning is essential"
He is not advocating against mockups. He pushes towards more collaboration between UX, product and engineering. Something (like a story) should not include all of the mockups and there should not be a ton of upfront work. A user story should be a detailed description of the problem a user has, not the solution. Mockups can still happen, but they get created during development and in collaboration. Not upfront as a specification of the users problem, combined with the solution.
@@florianfanderl6674 yes or ideally not a problem but a description of what the user wants to achieve as that is often more the case than a problem (depending on software of course) That is why agile often fails when trying to distance itself from what is considered waterfall. The exploratory phase and the design / preproduction phase. Those needs to happen before going into the development of what will end up in the product. Of course this should happen iteratively all the time and not something that is done in a big lump. Hence the term “design sprint” appeared which is silly. As it should always be there. Often going in parallel with cleared development (which is not just code but all forms of assets that will form the final output)
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.)
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.
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"
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.
My point was, that if it isn't the real thing.... then it isn't the real thing. There is a translation that means that this is a model, an approximation, the real things is ALWAYS the only true representation, so why not specify more effectively than you ever can with pictures, and then evolve the REAL THING to be what you want.
@@ContinuousDelivery I agree the process should not be separated. First we do design then we do development. Sure. I just reffered to the way you descibed design deliverables. It sounded like 10 years ago. :)
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.
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).
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 :)
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.
As a "backend" developer, I find the client-facing web (HTML, CSS, JavaScript, etc.) world undesirable to work in. Because JavaScript is so ubiquitous, the bar of entry for anyone wanting to "be a programmer" is VERY low. Tutorials are everywhere. An understanding of computation, design, etc is not really of concern/necessity to graduate from a bootcamp, finish a tutorial or even get many of the "entry-level" jobs in software development. The industry is too busy trying to encourage everyone to "get into tech" and many people evangelizing the profession brag about not having formal education in matters programming. It is no wonder, to me at least, that JavaScript frameworks/libraries come and go, are full of vulnerabilities and bugs, etc. and that you find it hard to come across legitimate design training. The industry deems it unnecessary for front-end developers to have much beyond a portfolio of web tutorials they've completed (in many cases the source code is available in a completed/working state) or some small-talk about their favorite JavaScript libraries. We have created this problem and will be dealing with it for many many years to come. For the record I do not believe one MUST complete a formal education is Computer Science or Technology to hold a programming position/role. I do believe the industry undervalues formal education and experience, while simultaneously relying heavily on contrived logic/intelligence tests/questions.
@@koderkev42 I agree, in my compsci degree I learnt ways of thinking and planning that I use on a daily basis that often a lot of web programmers (BE/FE) who have not studied just have never learned, things like GC optimisation in C#, minimising loop logic, for loops vs foreach, using UML/flowcharts to find problems in logic. Unfortunately in a lot of FE positions they just do not think of these things and so JS libraries have to pick up the slack, and often end up using a lot more memory that they need to. Even little things like someone wanting to use a JS MVC FE framework with a C# MVC BE, you already have the MVC structure in your system, adding that framework just duplicates half the work and doubles the points of failure when change occurs.
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!"
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.
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.
That seem to also be a good receipe for failure. I think working together early on is the key. By working as you do, you already lock down or away possibilties. Stil its better than the way around of course
@@litjellyfish These are scientific models and they only need fairly simple internal web interfaces so that others in the company can use them. Trying to get UI involved earlier has not really worked because the models can take years to develop and there is no real way to know ahead of time how long it will take or even what parameters the model will have. You start with a basic math simulator, see if it can explain the data, find out where it is deficient, model more of the physical process, and repeat.
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"
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.
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.
I think that the sort of model that you build via Event Storming is stronger than a traditional BPML, because it is more focused on the use and utility of the system from a user's perspective. It is not that you can't do that with BPML, but that isn't its natural focus, whereas it is the natural focus of Event Storming. en.wikipedia.org/wiki/Event_storming
@@ContinuousDelivery Event Storming was not something I came across in my day. I like that it has a lightweight feel. It might be stronger from a system dev perspective. However I think the set of outputs need to be useful to both business and the Dev team. Easily fixed I'm sure. Business departments (users) need to get a tangible return from these workshop meetings. They could take a few days. If their best person(s) is(are) away for some days at an IT workshop, that business needs something to show for it, something useful ... Useful in their opinion and within a few days. Everything's a deal/trade. I found nicely presented, (sometimes simplified) BPML diagrams create really good visuals. Business departments used them to speak to each other breaking open the silos. Business transformation in action. Often simplifying the UI that would otherwise be needed. E.g. The business process, UI and information requirements for discovering and chasing down a late X and why, isn't simple.
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.
I'm a SWE student but I eventually plan to get my masters in information with a focus on ux. There are bad web and application designers everywhere. Graphic design is not ux design. This is evidenced by the borderline unusable and poorly researched/understood interface design I see literally everywhere. It's either: - Pretty but terrible usability - Ugly but terrible usability Very infrequently do I encounter applications I'd consider well-designed from a UX perspective. I see some that are well-designed aesthetically for sure, but beyond art projects and media promotions etc. the aesthetics should not be the primary driver. This is a twofold problem in my opinion. 1. Designers of applications who do not understand HCI, research, data analysis, etc. 2. Business owners who do not value the benefits of well-designed applications or see any reason to focus on it due to misunderstanding how people use things. They instead want the designer to ignore all the skills they learned and pump out UIs in Figma with no steps before or after, and armed with nothing but assumptions and heuristics. If there isn't a discovery and ux research phase (does not always need to include actual user interviews, though in many cases it should), it will likely be a 50/50 shot on whether the designer's assumptions about the users and business domain is correct. There are also developers who are not designers who make interfaces with poor usability. Both should have an understanding of the other's key principles at the bare minimum. No web app designer should not understand HTML, CSS, and some basic JS at the minimum. No one who touches an application's code should not understand the core principles and workflows of proper ux design either. None of these things are that hard.
I suppose it depends on how you perceive what SW dev is and what it is for. I see SW dev as being focused on solving some problem for someone, those words aren't quite right, but they come close. Providing a great game experience isn't really "solving a problem" from the user's perspective, but it is from the developer's - they are solving the problem of what a great user experience means in the context of the game. I don't think that SW dev is only a matter of translating from on language (english for example) to another (python for example). Devs who see it like that aren't the people who build great systems. You need to understand the problem you are trying to solve! Whatever the nature of that problem.
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 😎
If I learned one thing as a UX Designer it's that programmer brains are wired completely different to those of most users 😅 most programmers I met (and am working with) think about how the data flows and how different parts of a software work together to build a mental model of how the software should work, but what they forget is that most of the users without a software background don't have this insight and look at software more in terms of things they want to achieve. Not saying there are no devs out there that can deliver great UX, just more rare then I would like 😅
Yes but he did not mean how it works technically. Many seems to think that. He means how it works for the user. Maybe that is what you meant. Just wanted to call out just in case
@@litjellyfish Yea that is what I meant. I think Coplien goes on the tirade in that video because so many projects gets caught up in technical complexities without keeping in mind who/why they are doing it. Is the software that we are building helping people? Which IMO touches on the points in this video - is the team building software for a user or for a design team?
@@MrCalyho I agree so much in this. And it goes for so many roles. Devs, UI, UX etc.. its a lot of do it for the sake of it or my own interest or snobbyim. And often the Product Owner gets bullshit from all when that person actually just is challenging what is being built. Noo that person always end up as the bad money grabbing evil manager. Then UX people can spend 3 weeks asking users questions that have not even been validated before. And UI sits moving pixels back and forth for 3 weeks. And finally hands over the design to devs who then fights over a PR for 2 weeks and then decided to do a refactor for a yet to be released feature for 4 more weeks. And then they wonder why things go slow...
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..
Have you heard of FIGMA and similar tools? It is literally made for visial prototyping and you can even include interaction in it. It serves as a blueprint for building the real thing before actually building it
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.
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.
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.
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
@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.
Very sorry, I have added the links, but for convenience, here they are... Sign Up for ATDD Guide www.subscribepage.com/cd-atdd-guide Sign up for User Stories Guide www.subscribepage.com/write-user-stories
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.
I don't know how many projects I've been on as a "back end" developer and had to go back to the UI/front-end team and asked "Why are we collecting that data?" and "What are we supposed to do with that?" I've seen times when they want to track every item every user looked at and I'm like why if management doesn't want reports on it, marketing can't do anything with the information, there is no way to push ads, etc., etc. Often they say they'll add that later or use it as a promise to the higher ups as if it can do that. And I'm like, where in your app are you pushing this back? Likewise, I've seen entire systems were it takes "user history" and I'm like, what is the point of tracking user history on searches which are all date-based? Those events are no longer available. The are advantages with data-driven requirements.
as an ape myself who’s never worked with an actual designer, i would agree on that totally. If i wasn’t id prob find facts somewhere in that haystack of shallow assumptions, specific to UX design being a design of the product, not the user’s happy emoji. That’s purely delight and post iteration. Step 1 is architecture, but wait…what is that? that’s right, its the build map. The rest is a careful art of threading the needle from that knot to the form of the interactions.
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.
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.
"But the UI dictate workflow is still one of the fastest ways towards a POC and/or an MVP" It's absolutely not, it's one of the *most common* ways for sure. But it's absolutely not the fastest way to a POC or MVP - a website with zero style, just text and form boxes is a fine POC and a whole lot quicker to build (for example). Even better might be to have no UI at all - a POC just needs to show that the underlying idea works, a hardcoded lists of steps in a test-case can do that just as well. I do find UI mockups to be a very handy discussion tool, a good way to fantasize about a possible future, but POC they are not.
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.
I experience this as “programming my remote control” - product owners working with designers to tweak and deliver designs as requirements- omitting story definition and acceptance criteria
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.
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.
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.
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.
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 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.
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.
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?
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.
I doubt that anyone has measured this collaboration specifically, but in general, teams that do well at working the way that I describe on this channel, including working with high levels of collaboration and autonomously as I describe in this video, spend 44% more time on new features that teams that don't work this way. (Source dora.dev)
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.
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.
I don't think that I said or implied any of that, if it came across like that I am sorry, but it wasn't what I meant. My point is not that UI design is easy or unimportant, quite the reverse, it is that it is an essential, but also integral part of everything that we do. Making our systems easy to use and easy to understand though is a skill that goes way beyond pretty pictures, and if you focus too heavily on the pretty pictures you won't achieve build systems that are easy and nice you use. The best way to achieve that is through constant, fine-grained collaboration and iteration.
@@ContinuousDelivery Ok. I didn't think you were unaware of the difficulty of the human connection. The video just didn't seem to bring those other contexts in very strongly. I am sorry if I misread your intent. One thing I see, whether hanging out with Developers, Designers, Writers, QA or whoever, is a tendency to be hyper aware of one's own domain challenges, but to discount domain challenges for other parts of the process. That was the concern that lead me to leave a comment. Not all of your viewers have as much experience as you, and they may not understand the need to be aware outside our immediate discipline. As you said above, the real need is for all of the perspectives to be participants in both the ideation and the iteration. Unfortunately, that is a less common model for arranging projects and teams.
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
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.
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.
I think that you made my point for me here, "the vast majority of developers don't do a good job and neither do the designers". That is because we use them and teach them that design is about drawing the pictures and development is about animating the pictures. both are nonsense and the tiny percentage of orgs and people that don't do this, is where the good software comes from, so maybe we should change how we organise these activities, and treat both parts as the output of a process of software development.
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 😂
@@jimmyhirr5773 No, I don’t want to chose the system architecture. I’d rather leave it to trained experts who I respect for the skill they have acquired over years. But I do ask for the same level of respect from the other side, too.
So true. Its all about collaboration and communication. I get when devs probe questions if its related to the tech aspect of it. Or if they seem some obvious logic flaw or can point to inchoerence. That is fine. But when it comes to opinions I think its the line. Also from my experince they often do so very direct. And if I (say in previous roles as PO/PM/UI/UX etc) would do similar, ask probing questions about tech like interfaces (do not happen often) and optimisations / set up (happens often) they almost go in rage with - you are not a dev, you should not micro manage how we would solve it. when often those question is just to confirm if they did get the design correctly. Problem is that is hard to see the big picture regarding UI etc. Even for a UI designer so its very easy to miss out things (even those I myself see as obvious) so many times I have ben cut off by dev as I went to deep in. To later test some feature an finding missing checks or state management and when pointing out, getting from the same dev that cut me off "well you should have told that or written that exactly in the specification) After 30 y in the business I am still at odd how bad a lot of code is it regarding doing state saving and global update when entering and exit modals. I mean even here on youtube I find those bugs so often. Take an example now. If I go into my "view profile page" where I have a big version of my profile picture and change the profile picture (in a new dialoge) the picture is changed in the drop down menu from top right profile settings round icon. But not in the big picture in the "view profile page" It do not matter if I reload. I need to change profile and then go back and then it updates. Meaning that somehow the flag that is triggering the update of the big profile picture is NOT in the dialogue where I change the picture (but it seems it sets it for the drop down meny icon - or that menu is pulling an update with each page refresh itself - something that is very stupid)
@@Wisaalmusic yeah. Abs often it’s also UX for UX etc so it’s not a fault tied to solely devs by any means. I find often most roles goes into the trap. Maybe when it comes to data science and product ownership less. Because you seldom get as close to hands on work which good and bad keeps you from getting to involved. For those roles it can actually be the contrary so they end up doing product for… well nobody
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.
To be honest it is pretty bad for Banking or Purchase Order apps too. I think it is a bit more than only the backend data, it is about the user experience that we are able to create, I can edit any backend data with a hex editor if I really need to, it is a good tool for some kinds of job., but I could also look at the same data with a 3D editing package if that is the model it represents. It seems to me that our job is trying to generate sensible, appropriate experiences in the context of our user's need, and while that is certainly related to the nature of the "backend data" I still think that there is more going on here.
@@ContinuousDelivery my disaster came a few years ago when I was doing an update to a robotics control system and I had the sales department trying to drive the UI with no idea about configuration data had to be configured it finally drove me into retirement
@@terrymackenzie6784 Yes, I think that good SW development only really happens when orgs and the people involved recognise that this is a HUGELY complex undertaking that demands expertise and collaboration. We have to be partners in deciding and planning the work, because only technical people will see some things that are ESSENTIAL to success, really whatever the nature of the system, unless that system is entirely trivial, and even then it is way too easy to miss things. SW dev is harder than it looks!
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.
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.
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.
@@litjellyfish The blame falls on both - either the devs or the des silo themselves or one another. Also there's a lot of misunderstanding and arrogance towards des as the "less productive" of the two. Many have never worked in an integrated way with a des, Then there's organisation quagmire… Even this channel is guilty of not appreciating what good integrated designer can do for a team.
@@scrooge-mcduck totally agree. It’s the old. “Devs are anal slow autistic people” from art. And “artist is fuzzy stupid people” and it seems little progress has been done here since the 80s Yeah I ask find that. Many times the guys here speaking seems to don’t have a clue on some design processes and also seems to see it very much from the devs pov. Which is normal. I just wish the different roles was more open to listen and understand each other
@@scrooge-mcduck it’s a bit funny with des are not productive when in most software the majority of time is spend in dev with the reasoning “it’s much more complicated. And that is also the reason why still exploration and design and mockups and prototypes phase is skipped or rushed through “we don’t have time for that we need to start building the real thing or we will not have it ready in time” when I hear such I know the project are doomed
The issue I have with your opinion is, that you assume all developers are 150k+ a year professionals. This is not always the case. Most big companies that aren't software companies don’t have the money to afford developers who actually can think for themselves. That is why we rely on outsourcing - and once you do that, you want to make sure you give as much up front as possible to avoid mistakes. The talent: UI Design, Marketing, Systems design, is actually not with the developers in these cases. The devs are just a tool that is used to bring that vision to life. It’s much easier to afford a Marketing agency and a proper Product Manager who think of UI/UX and systems design respectively and hand it over to a development house, than to afford top shelf developers who know their way around UX/UI + the legal ramifications of everything + the ability to actually implement it. In your mind, the people who build the thing, actually understand it - but should/do they really? What does a developer know about consent levels? about Cookies laws in different countries, about the Marketing Teams requirements for which font and style to use because it’s corporate policy? Your version of agile, simply isn’t rooted in the real world where everything needs 5 layers of approval from legal and Marketing. What happens if the developer builds a solution, then legal takes a look at it and determines that it isn’t allowed? Then we just wasted a bunch of time developing something that isn’t allowed to ship.
Just get a fullstack UI guy that is coder and ux/ui designer, those where common during the 90s and especially early 2000s until someone started the BS to split it up due to too many designer snowflakes not wanting to learn to code UI but join in the profitable IT market. So many things got diluted after 2005 when everyone was flocking to the Internet/IT-business.
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.
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: ruclips.net/video/3FoHvpt_ZEg/видео.html
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
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.
This 100%. I try to get involved with both BE devs and UI designers as much as possible, as they are the two biggest factors that impact my work on the FE. Expanding knowledge and content beyond the immediate 'corporate borders' is also super valuable, just creating a better understanding of the system you're working in. Though, it really depends on the company how far you can pry (and sometimes even designers are out of reach).
I also feel too often UX is confused with UI design or put into a box of 'making pretty screens'. The problem with pretty screens is that you can design anything your user wants, without limitations like 'what the system does/should do'. Request 'export the entire database' and it's easy to design a button 'export all'. Regardless of whether the technology supports such requests, or whether such a request is even usable by the user.
UX is an integral part of all parts in the application - 'how does the system work' in the general sense. Every boundary between layers works together to deliver a product that's nice to work with, AND nice to work in. This is also why using the system you develop is so good, because you automatically get a more complete picture of your app rather than the abstract subset that is your specialized part in the system.
This.
I agree. I'm a frontend Dev and have made it one of my unbreakable rules to iron out potential development issues that design or product had not considered prior to coming up with the spec. It's imperative for a technical member of the team -- a developer -- to evaluate the spec and confirm (at least approximately) whether or not the asks are achievable.
I can tell you that for most designer that feeling is mutual. Being asked to design something without having access to someone that can help you understand the limitations of the system is a horrible experience, and it cost a ton of time when you are forced to redesign things because of it.
Collaboration is very important, as is communication.
couldn't be said any better.👏
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!
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."
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.
Startups also carry fewer of the operational burdens of mature organisations. Developers being shafted by nasty code written 5 years ago by the intern is not disturbing them from the nasty code of today.
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
I'd answer: open a newspaper, look for the stock of the company which made it and compute how much an OPA costs.
@@ClaudioBrogliato 😂 good answer
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.
Yeah, give people context, and they will come up with ideas.
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.
I strongly believe that he's talking about the separation between the design team and the developer team
Like throwing a maquette to translate into code instead of taking the developer advise while making the design so they contribute and understand the system
This can be fixed by creating contracts that are created by FE and BE together where FE can use mocks derived from that contract to develop against. This allows FE to work on and even complete features without having to wait for BE to have been finished.
@@MrExiztence Sure you can. It does however depend on what you are building and the complexity.
Driven a lot by recruiters or agents who think it's two different things my niece who is a recruiter when I told here I was a software engineer asked, front end or back end, to which I replied a lot of my software doesn't have a front end
@@terrymackenzie6784 True. And those terms are very contextual. Since they are not talking about compiler frontends but the user experience of a web app, most likely haha 🙂
favorite quote: "The best solutions are achieved when we can iterate towards them as we learn more."
Bang on. Cannot count the amount of times this separation has caused atleast serious problems in delivery and delivery quality
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.
All I can say about this video is, "HELL YES!!" I haven't had this discussion with a group since this morning.
There's also the separation of UI and UX - which seem to be at odds with each other more often than not.
Often confusing the difference between UI and UX - calling it UiUX
most ui/ux people are in reality just ui
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.
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.
Yes I think that is the exact problem he is brining up. And same it do not work when tech are blocking some UX idea becuase its not possible to do (and often turns out to be indeed possible but was not understood)
@@3_smh_3 exactly. So instead of collaborating in a more free exploratory phase (with not to many people) they stress and blame each other and start working (with too many people ) on each sides.
That is the much better approach though. Developer time is expensive. The initial planning of a feature and system requires much more than a developer actually knows.
If you want to design a login flow you gotta consider Consent levels and talk to Marketing and Legal teams. You have to make sure the designs adhere to the Marketing guidelines. You gotta know your actual customers and business model well.
The product lead is the one with the vision - he aligns his vision with the Tech Lead who then brings it to fruition with developers
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?
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.
exactly. and it goes for all team members. nothing should be set in stone, because that's where you start to get problems
I agree that teams need to provide constructive feedback when necessary, however I do believe that organizations could benefit from promoting a collaboration rather than a transactional enviroment.
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
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.
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
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.
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
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.
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.
Where did you get that tshirt? That is awesome!
I get them from Qwertee and they offer a discount to CDonYT viewers.
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
USE THIS DISCOUNT CODE: ContinuousDelivery to get money off the already reasonably priced t-shirts!
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.
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 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 😁
All very good and correct in my experience.
I would add.. Sometimes faithful reproduction of certain separately produced UI designs, can present backend developers with challenges that may require a disproportionate amount of re-architecting, or even be impossible or illogical.
Conversely, backend knowledge can often inform what is (easily) possible in UI beyond what had been imagined by UI designers.
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.
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.
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.
Have you heard of refactoring? You're allowed to refactor as much as you want while all the tests are green. If you think there's going to be a lot of duplication in a new feature, then you can refactor your existing code to be more generic before you write tests for the new feature. Then you can make the tests pass with the more generic code.
If you have more questions, then you might have better luck asking a TDD trainer. There are lots of them. The rules for this comment section say "no advertising" so I won't recommend any specific ones.
1. Why do you think duplication of code in your tests is a bad thing? It’s not bad.
2. Duplication of code is bad most of the time - when you need to do the same update in multiple places. But, if your code is going to be independent and evolves in different directions after copy&paste then it’s much better than unnecessary coupling.
3. I’m not a huge fan, but maybe something like table tests can help in the situation you mention. If it’s truly the same thing, but you need to test all the cases then it will do the trick.
4. „Laws” - there is no TDD police. You can bend and break the rules. Including the advice I’m giving :) TDD laws are there because they work. But, in some cases they may not. It’s ok.
I agree with the other responses here, my all means you should use refactoring to improve the generality of you code. Treat the tests as specifications to drive design choices, rather than as "proof" that your code does something. Specification is the primary job of tests in TDD, IMO. So write enough tests to specify what you want, if you wan't other parts of your system to have all the advantages of "bolding" and you already have the generic code for "bolding" then I see no problem in writing a test that covers one of the more complex scenarios as a sanity check, but not necessarily repeating every incremental test that you needed to write to achieve "bolding" in the first place. Use tests to aid your ability to design more than as a proof of what you did, leave enough tests in place to show that your result is what you expect. This advice is a bit subjective, you'll need to make a judgement call on if you have enough tests, but if it wasn't subjective we could write code that did it for us 😉
This is an excellent example of working with enabling teams, thanks
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.
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.
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.
I think the key is the so called hand over. For me mockups in different ways are great. Both visual mockups and tehcnical functional mockups / prototypes. And both needs to be tossed away. They are not part of the product, they are part of the discovery that will lead to the product. By doing so many tech issues can be found early on. Performance issues. Or simply the realisation that what looked good on paper do not work in reality. Problem is that this phase takes time. or is seen as taking time. And just mentioning to some that this work as a function will be tossed away (or not used in the end product) but only the learnings or the specification from it will be used. I find it so odd. And yes I agree totally about word sucks. The closer to the reality you can get withhout it being the reality the closer the reality will be. Also it mean that it can be validated functionally as early as possible for all roles and function as a communication material. A bit like the classing "plans are worthless but planning is essential"
He is not advocating against mockups. He pushes towards more collaboration between UX, product and engineering. Something (like a story) should not include all of the mockups and there should not be a ton of upfront work. A user story should be a detailed description of the problem a user has, not the solution.
Mockups can still happen, but they get created during development and in collaboration. Not upfront as a specification of the users problem, combined with the solution.
@@florianfanderl6674 yes or ideally not a problem but a description of what the user wants to achieve as that is often more the case than a problem (depending on software of course)
That is why agile often fails when trying to distance itself from what is considered waterfall. The exploratory phase and the design / preproduction phase. Those needs to happen before going into the development of what will end up in the product. Of course this should happen iteratively all the time and not something that is done in a big lump. Hence the term “design sprint” appeared which is silly. As it should always be there. Often going in parallel with cleared development (which is not just code but all forms of assets that will form the final output)
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.)
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.
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"
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.
My point was, that if it isn't the real thing.... then it isn't the real thing. There is a translation that means that this is a model, an approximation, the real things is ALWAYS the only true representation, so why not specify more effectively than you ever can with pictures, and then evolve the REAL THING to be what you want.
@@ContinuousDelivery I agree the process should not be separated. First we do design then we do development. Sure.
I just reffered to the way you descibed design deliverables. It sounded like 10 years ago. :)
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.
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).
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 :)
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.
As a "backend" developer, I find the client-facing web (HTML, CSS, JavaScript, etc.) world undesirable to work in. Because JavaScript is so ubiquitous, the bar of entry for anyone wanting to "be a programmer" is VERY low. Tutorials are everywhere. An understanding of computation, design, etc is not really of concern/necessity to graduate from a bootcamp, finish a tutorial or even get many of the "entry-level" jobs in software development.
The industry is too busy trying to encourage everyone to "get into tech" and many people evangelizing the profession brag about not having formal education in matters programming. It is no wonder, to me at least, that JavaScript frameworks/libraries come and go, are full of vulnerabilities and bugs, etc. and that you find it hard to come across legitimate design training. The industry deems it unnecessary for front-end developers to have much beyond a portfolio of web tutorials they've completed (in many cases the source code is available in a completed/working state) or some small-talk about their favorite JavaScript libraries.
We have created this problem and will be dealing with it for many many years to come. For the record I do not believe one MUST complete a formal education is Computer Science or Technology to hold a programming position/role. I do believe the industry undervalues formal education and experience, while simultaneously relying heavily on contrived logic/intelligence tests/questions.
@@koderkev42 I agree, in my compsci degree I learnt ways of thinking and planning that I use on a daily basis that often a lot of web programmers (BE/FE) who have not studied just have never learned, things like GC optimisation in C#, minimising loop logic, for loops vs foreach, using UML/flowcharts to find problems in logic. Unfortunately in a lot of FE positions they just do not think of these things and so JS libraries have to pick up the slack, and often end up using a lot more memory that they need to. Even little things like someone wanting to use a JS MVC FE framework with a C# MVC BE, you already have the MVC structure in your system, adding that framework just duplicates half the work and doubles the points of failure when change occurs.
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!"
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.
Sounds like a more specific form of one of my common mantras: "Describe me your problem, not your solution"
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.
That seem to also be a good receipe for failure. I think working together early on is the key. By working as you do, you already lock down or away possibilties. Stil its better than the way around of course
@@litjellyfish These are scientific models and they only need fairly simple internal web interfaces so that others in the company can use them. Trying to get UI involved earlier has not really worked because the models can take years to develop and there is no real way to know ahead of time how long it will take or even what parameters the model will have.
You start with a basic math simulator, see if it can explain the data, find out where it is deficient, model more of the physical process, and repeat.
@@Immudzen ah ok then I get what types of software. Makes sense
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"
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.
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.
I think that the sort of model that you build via Event Storming is stronger than a traditional BPML, because it is more focused on the use and utility of the system from a user's perspective. It is not that you can't do that with BPML, but that isn't its natural focus, whereas it is the natural focus of Event Storming. en.wikipedia.org/wiki/Event_storming
@@ContinuousDelivery Event Storming was not something I came across in my day. I like that it has a lightweight feel. It might be stronger from a system dev perspective. However I think the set of outputs need to be useful to both business and the Dev team. Easily fixed I'm sure.
Business departments (users) need to get a tangible return from these workshop meetings. They could take a few days. If their best person(s) is(are) away for some days at an IT workshop, that business needs something to show for it, something useful ... Useful in their opinion and within a few days. Everything's a deal/trade.
I found nicely presented, (sometimes simplified) BPML diagrams create really good visuals. Business departments used them to speak to each other breaking open the silos. Business transformation in action. Often simplifying the UI that would otherwise be needed. E.g. The business process, UI and information requirements for discovering and chasing down a late X and why, isn't simple.
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.
I'm a SWE student but I eventually plan to get my masters in information with a focus on ux.
There are bad web and application designers everywhere. Graphic design is not ux design.
This is evidenced by the borderline unusable and poorly researched/understood interface design I see literally everywhere.
It's either:
- Pretty but terrible usability
- Ugly but terrible usability
Very infrequently do I encounter applications I'd consider well-designed from a UX perspective. I see some that are well-designed aesthetically for sure, but beyond art projects and media promotions etc. the aesthetics should not be the primary driver.
This is a twofold problem in my opinion.
1. Designers of applications who do not understand HCI, research, data analysis, etc. 2. Business owners who do not value the benefits of well-designed applications or see any reason to focus on it due to misunderstanding how people use things. They instead want the designer to ignore all the skills they learned and pump out UIs in Figma with no steps before or after, and armed with nothing but assumptions and heuristics.
If there isn't a discovery and ux research phase (does not always need to include actual user interviews, though in many cases it should), it will likely be a 50/50 shot on whether the designer's assumptions about the users and business domain is correct.
There are also developers who are not designers who make interfaces with poor usability.
Both should have an understanding of the other's key principles at the bare minimum. No web app designer should not understand HTML, CSS, and some basic JS at the minimum. No one who touches an application's code should not understand the core principles and workflows of proper ux design either. None of these things are that hard.
I suppose it depends on how you perceive what SW dev is and what it is for.
I see SW dev as being focused on solving some problem for someone, those words aren't quite right, but they come close. Providing a great game experience isn't really "solving a problem" from the user's perspective, but it is from the developer's - they are solving the problem of what a great user experience means in the context of the game.
I don't think that SW dev is only a matter of translating from on language (english for example) to another (python for example). Devs who see it like that aren't the people who build great systems. You need to understand the problem you are trying to solve! Whatever the nature of that problem.
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 😎
If I learned one thing as a UX Designer it's that programmer brains are wired completely different to those of most users 😅 most programmers I met (and am working with) think about how the data flows and how different parts of a software work together to build a mental model of how the software should work, but what they forget is that most of the users without a software background don't have this insight and look at software more in terms of things they want to achieve. Not saying there are no devs out there that can deliver great UX, just more rare then I would like 😅
@@kilor78 😅 true
As S. Jobs said: Design is not just what it looks like and feels like. Design is how it works.
Or like James Coplien says in his vid: ruclips.net/video/ZrBQmIDdls4/видео.html . The UI is the product! 😆
Yes but he did not mean how it works technically. Many seems to think that. He means how it works for the user. Maybe that is what you meant. Just wanted to call out just in case
@@litjellyfish Yea that is what I meant. I think Coplien goes on the tirade in that video because so many projects gets caught up in technical complexities without keeping in mind who/why they are doing it. Is the software that we are building helping people? Which IMO touches on the points in this video - is the team building software for a user or for a design team?
@@MrCalyho I agree so much in this. And it goes for so many roles. Devs, UI, UX etc.. its a lot of do it for the sake of it or my own interest or snobbyim. And often the Product Owner gets bullshit from all when that person actually just is challenging what is being built. Noo that person always end up as the bad money grabbing evil manager. Then UX people can spend 3 weeks asking users questions that have not even been validated before. And UI sits moving pixels back and forth for 3 weeks. And finally hands over the design to devs who then fights over a PR for 2 weeks and then decided to do a refactor for a yet to be released feature for 4 more weeks. And then they wonder why things go slow...
@@litjellyfish oh man don't get me started 😂
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..
Have you heard of FIGMA and similar tools? It is literally made for visial prototyping and you can even include interaction in it. It serves as a blueprint for building the real thing before actually building it
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.
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.
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.
May I note that POs are never responsible for software architecture.
@@Alex-tp5jj Sure. Not directly.
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
@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.
Very sorry, I have added the links, but for convenience, here they are...
Sign Up for ATDD Guide www.subscribepage.com/cd-atdd-guide
Sign up for User Stories Guide www.subscribepage.com/write-user-stories
@@ContinuousDelivery Many thanks. I really appreciate your channel
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.
Many things are based on defect ideas, from Scrum to Agile to UX
Most UIs I’ve seen from programmers are terrible. It’s far and few to find a good one. PC brain.
The programmers aren’t the idiots, the users are
I don't know how many projects I've been on as a "back end" developer and had to go back to the UI/front-end team and asked "Why are we collecting that data?" and "What are we supposed to do with that?" I've seen times when they want to track every item every user looked at and I'm like why if management doesn't want reports on it, marketing can't do anything with the information, there is no way to push ads, etc., etc. Often they say they'll add that later or use it as a promise to the higher ups as if it can do that. And I'm like, where in your app are you pushing this back? Likewise, I've seen entire systems were it takes "user history" and I'm like, what is the point of tracking user history on searches which are all date-based? Those events are no longer available.
The are advantages with data-driven requirements.
as an ape myself who’s never worked with an actual designer, i would agree on that totally. If i wasn’t id prob find facts somewhere in that haystack of shallow assumptions, specific to UX design being a design of the product, not the user’s happy emoji. That’s purely delight and post iteration. Step 1 is architecture, but wait…what is that? that’s right, its the build map. The rest is a careful art of threading the needle from that knot to the form of the interactions.
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.
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.
"But the UI dictate workflow is still one of the fastest ways towards a POC and/or an MVP"
It's absolutely not, it's one of the *most common* ways for sure. But it's absolutely not the fastest way to a POC or MVP - a website with zero style, just text and form boxes is a fine POC and a whole lot quicker to build (for example). Even better might be to have no UI at all - a POC just needs to show that the underlying idea works, a hardcoded lists of steps in a test-case can do that just as well.
I do find UI mockups to be a very handy discussion tool, a good way to fantasize about a possible future, but POC they are not.
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.
I experience this as “programming my remote control” - product owners working with designers to tweak and deliver designs as requirements- omitting story definition and acceptance criteria
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.
Damn straight - it is one of the most annoying (and frequently dangerous) things and has become more and more common.
That’s poor UX UI design
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.
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.
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.
This isn't even a UI development problem, but a wider one across the entire project and even industry.
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 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.
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.
ha yes of course, if the directors don't know what they're doing, there's no solution. You can only do damage limitation 😂@@gppsoftware
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?
Nah, he's just gonna say that everyone is doing everything wrong and not provide any alternative
Never had any issues with front-end/back-end dev.
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.
Couldn't agree more! Great video as always!
Glad you enjoyed it!
What is the percentage increase in cost with enacting this integration of labor?
I doubt that anyone has measured this collaboration specifically, but in general, teams that do well at working the way that I describe on this channel, including working with high levels of collaboration and autonomously as I describe in this video, spend 44% more time on new features that teams that don't work this way. (Source dora.dev)
Front end is "OwO", back end is "Oh no!"
Great session 🙏 Thank you.
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.
the last comment on user interface expert is absolutely right..
That shirt is so nerd!!! LOVE IT!
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.
I don't think that I said or implied any of that, if it came across like that I am sorry, but it wasn't what I meant. My point is not that UI design is easy or unimportant, quite the reverse, it is that it is an essential, but also integral part of everything that we do. Making our systems easy to use and easy to understand though is a skill that goes way beyond pretty pictures, and if you focus too heavily on the pretty pictures you won't achieve build systems that are easy and nice you use. The best way to achieve that is through constant, fine-grained collaboration and iteration.
@@ContinuousDelivery Ok. I didn't think you were unaware of the difficulty of the human connection. The video just didn't seem to bring those other contexts in very strongly. I am sorry if I misread your intent.
One thing I see, whether hanging out with Developers, Designers, Writers, QA or whoever, is a tendency to be hyper aware of one's own domain challenges, but to discount domain challenges for other parts of the process. That was the concern that lead me to leave a comment. Not all of your viewers have as much experience as you, and they may not understand the need to be aware outside our immediate discipline.
As you said above, the real need is for all of the perspectives to be participants in both the ideation and the iteration. Unfortunately, that is a less common model for arranging projects and teams.
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
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.
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.
I think that you made my point for me here, "the vast majority of developers don't do a good job and neither do the designers". That is because we use them and teach them that design is about drawing the pictures and development is about animating the pictures. both are nonsense and the tiny percentage of orgs and people that don't do this, is where the good software comes from, so maybe we should change how we organise these activities, and treat both parts as the output of a process of software development.
@@ContinuousDelivery I agree.
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 😂
Sounds good to me. If you want to choose the system architecture, then feel free to pick up a keyboard and code it.
@@jimmyhirr5773 No, I don’t want to chose the system architecture. I’d rather leave it to trained experts who I respect for the skill they have acquired over years. But I do ask for the same level of respect from the other side, too.
So true. Its all about collaboration and communication. I get when devs probe questions if its related to the tech aspect of it. Or if they seem some obvious logic flaw or can point to inchoerence. That is fine. But when it comes to opinions I think its the line. Also from my experince they often do so very direct. And if I (say in previous roles as PO/PM/UI/UX etc) would do similar, ask probing questions about tech like interfaces (do not happen often) and optimisations / set up (happens often) they almost go in rage with - you are not a dev, you should not micro manage how we would solve it. when often those question is just to confirm if they did get the design correctly.
Problem is that is hard to see the big picture regarding UI etc. Even for a UI designer so its very easy to miss out things (even those I myself see as obvious) so many times I have ben cut off by dev as I went to deep in. To later test some feature an finding missing checks or state management and when pointing out, getting from the same dev that cut me off "well you should have told that or written that exactly in the specification) After 30 y in the business I am still at odd how bad a lot of code is it regarding doing state saving and global update when entering and exit modals. I mean even here on youtube I find those bugs so often.
Take an example now. If I go into my "view profile page" where I have a big version of my profile picture and change the profile picture (in a new dialoge) the picture is changed in the drop down menu from top right profile settings round icon. But not in the big picture in the "view profile page" It do not matter if I reload. I need to change profile and then go back and then it updates. Meaning that somehow the flag that is triggering the update of the big profile picture is NOT in the dialogue where I change the picture (but it seems it sets it for the drop down meny icon - or that menu is pulling an update with each page refresh itself - something that is very stupid)
Agreed, "from developers for developers" is REAL. (said by a developer)
@@Wisaalmusic yeah. Abs often it’s also UX for UX etc so it’s not a fault tied to solely devs by any means. I find often most roles goes into the trap. Maybe when it comes to data science and product ownership less. Because you seldom get as close to hands on work which good and bad keeps you from getting to involved. For those roles it can actually be the contrary so they end up doing product for… well nobody
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.
To be honest it is pretty bad for Banking or Purchase Order apps too. I think it is a bit more than only the backend data, it is about the user experience that we are able to create, I can edit any backend data with a hex editor if I really need to, it is a good tool for some kinds of job., but I could also look at the same data with a 3D editing package if that is the model it represents. It seems to me that our job is trying to generate sensible, appropriate experiences in the context of our user's need, and while that is certainly related to the nature of the "backend data" I still think that there is more going on here.
@@ContinuousDelivery my disaster came a few years ago when I was doing an update to a robotics control system and I had the sales department trying to drive the UI with no idea about configuration data had to be configured it finally drove me into retirement
@@terrymackenzie6784 Yes, I think that good SW development only really happens when orgs and the people involved recognise that this is a HUGELY complex undertaking that demands expertise and collaboration. We have to be partners in deciding and planning the work, because only technical people will see some things that are ESSENTIAL to success, really whatever the nature of the system, unless that system is entirely trivial, and even then it is way too easy to miss things. SW dev is harder than it looks!
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.
Main solution proposed in the video is unrealistic, best compromise based on reality is comment right here just next below my comment!
Thanks for the video =)
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.
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.
Yeah I just dont get it. Maybe because team are so big. Still I have seen team of say 3 devs sitting isolated from their only UX person.
@@litjellyfish The blame falls on both - either the devs or the des silo themselves or one another. Also there's a lot of misunderstanding and arrogance towards des as the "less productive" of the two. Many have never worked in an integrated way with a des, Then there's organisation quagmire…
Even this channel is guilty of not appreciating what good integrated designer can do for a team.
@@scrooge-mcduck totally agree. It’s the old. “Devs are anal slow autistic people” from art. And “artist is fuzzy stupid people” and it seems little progress has been done here since the 80s
Yeah I ask find that. Many times the guys here speaking seems to don’t have a clue on some design processes and also seems to see it very much from the devs pov. Which is normal. I just wish the different roles was more open to listen and understand each other
@@scrooge-mcduck it’s a bit funny with des are not productive when in most software the majority of time is spend in dev with the reasoning “it’s much more complicated.
And that is also the reason why still exploration and design and mockups and prototypes phase is skipped or rushed through “we don’t have time for that we need to start building the real thing or we will not have it ready in time” when I hear such I know the project are doomed
@@litjellyfish True. It's the builder/architect argument. Architect will always be undervalued until the the building collapses.
The issue I have with your opinion is, that you assume all developers are 150k+ a year professionals.
This is not always the case.
Most big companies that aren't software companies don’t have the money to afford developers who actually can think for themselves.
That is why we rely on outsourcing - and once you do that, you want to make sure you give as much up front as possible to avoid mistakes.
The talent: UI Design, Marketing, Systems design, is actually not with the developers in these cases. The devs are just a tool that is used to bring that vision to life.
It’s much easier to afford a Marketing agency and a proper Product Manager who think of UI/UX and systems design respectively and hand it over to a development house, than to afford top shelf developers who know their way around UX/UI + the legal ramifications of everything + the ability to actually implement it.
In your mind, the people who build the thing, actually understand it - but should/do they really?
What does a developer know about consent levels? about Cookies laws in different countries, about the Marketing Teams requirements for which font and style to use because it’s corporate policy?
Your version of agile, simply isn’t rooted in the real world where everything needs 5 layers of approval from legal and Marketing.
What happens if the developer builds a solution, then legal takes a look at it and determines that it isn’t allowed? Then we just wasted a bunch of time developing something that isn’t allowed to ship.
Just get a fullstack UI guy that is coder and ux/ui designer, those where common during the 90s and especially early 2000s until someone started the BS to split it up due to too many designer snowflakes not wanting to learn to code UI but join in the profitable IT market. So many things got diluted after 2005 when everyone was flocking to the Internet/IT-business.
This is the reason I’m a “Staff Fullstack QA Designer”.
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.
The mistake is that in most cases project managers and app architects are inexistant or incompetent.
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: ruclips.net/video/3FoHvpt_ZEg/видео.html