5 ms·

I have a fair bit of experience here as I work with many teams struggling with this. The root cause I have found is getting designs done in isolation and then

I have a fair bit of experience here as I work with many teams struggling with this. The root cause I have found is getting designs done in isolation and then treating the Figma/Sketch/whatever file as a hard business requirement, instead of treating the user experience as a collaborative exercise that is a tradeoff between usability and feasibility. Sorry for blogspam but I sketched a model of the two approaches. https://bitbytebit.substack.com/p/waterfall-design?sd=pf https://bitbytebit.substack.com/p/waterfall-design?sd=pf

542458 4y ago
I agree with this. I always tell people that the designs aren’t carved in stone or written in blood, and if something looks or feels wrong to bring it up. There’s no point in the process where the design can’t be improved, and anybody can be the one who finds an opportunity for improvement. And there’s also no shame in changing a design to make it easier to code. Ultimately no design is ever finished, and anything can be adapted or improved.
jacobyoder 4y ago
UI/UX has to be treated as an iterative process. Collaboration between multiple parties (eng/dev/design/pm/etc) is almost orthogonal to the root problem I've seen: "design" gets treated as "this is it" and the moment you start being 2-3 pixels off, or a shade of red isn't what was in figma/ps/etc, "you're deviating". "These were already signed off/approved/whatever". "But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile." "Stop deviating - we already interviewed customers!" "But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc" "Stop deviating". I've had a couple of good experiences working with a couple design folks in the last year, but EVEN in those cases, "design" was sort of treated like "one and done". Once the product is in the hands of real users, feedback - implicit and explicit - comes in, and there should be processes in place to make rapid adjustments - possibly multiple iterations - to deal with the feedback. That's one of the biggest hurdles I've seen, even when there's decent collaboration and respect.
- recroad 4y ago
  I've found that there is a mindset issue with designers that needs to be addressed if they are working closely with software development teams. If you come from an agency background then you are conditioned to only show perfect/close-to-perfect stuff to your clients because you don't want to leave poor first impressions. It's why there are multiple reviews and approvals before you show anything to the client. You want repeat business and a "failed" design would be treated as a strike against you. When working closely with teams there is no need for that and you can bring in low fidelity artifacts like sketches for feedback without fear of the whole design group being judged. This is a big change to how designers generally work when they're employed by agencies. Unlike agencies, this is a safer environment (all things being equal) where imperfection might be rewarded by engineers, but unfortunately, the agency mindset is retained. There definitely are ways to improve how we work together by playing some games, doing activities like assumption busting, diverge-converge design sketches etc. but the organization has to prioritize this mindset shift. The chance of it happening organically is limited. There are issues the other way as well: developers are often conditioned to expect perfect designs for fear of "re-work". I find good software design, solid testing practices and EMs with an eye to ways of working (not just technical stuff) can help address that.
  - tolkienfanatic 4y ago
    My previous company almost exclusively hired designers from agency backgrounds - it was a huge problem.
- corrral 4y ago
  Part of this isn't designers, but "stakeholders" and managers and such wanting to put their stamp on things. They often do this through design, I suppose because you can show anyone a screenshot in a powerpoint and they can appreciate it, but you can't show everyone a program logic flow chart and have them appreciate it. One way to push back, if you use anything like story points for estimation and scoping, is to point low-design and high-design options separately, for any elements where design choices may have a major effect on that. "This is a 5-point feature with a basic button with the correct brand colors and a spinner for busy state—but a 13-point feature with what's presented in the designs, including a bouncing hover animation and the button morphing into the company logo as its busy-state et c." Part of the problem is the cost of design on the development process, not just making initial mockups, is often ignored or not correctly accounted for. If you make it explicit, lots of times it turns out a simpler version (which is going to be better for users anyway, 90% of the time—but being good for the users isn't the reason for a lot of UI design, see: constant user-hostile but flashy redesigns across the industry) is in fact acceptable if it means you can fit another feature or two in a given sprint. "We can come back and do the fancier styling & behavior later when we have less feature development to do" but then, as with most things that get deferred, you never will, which is for the best.
deltarholamda 4y ago
Agree. In my experience, the design team tends to work closely with the client and the dev team is either silent or left out. Silent, because offering opinions on how something affects the backend may be completely moot when the next iteration is developed; or left out, because the dev team can't communicate "you can't do that" to the client in a way that doesn't sound annoying. The project manager's primary job is to keep the client happy, so they tend to overpromise. Which is weird, because (especially in Web design) they client was more or less happy with the limited set of functionality that Facebook gives them. They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit.
- corrral 4y ago
  > They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit. I, for one, am extremely skeptical that the intense focus on making sure every little thing on every page or app is "on brand", and the significant costs that preference incurs, has positive ROI. Nonetheless, every company seems to have become obsessed with it.
  - deltarholamda 4y ago
    >Nonetheless, every company seems to have become obsessed with it. You don't have to know much to have an opinion about it, therefore everybody does, and it's the most important thing in the world to them. "Normalizing the database? Wha? I'm not technical, guys, I'm more customer focused. We really need that sidebar to scroll with the page, let's work on that."
necovek 4y ago
I feel like the biggest problem is the lack of "tooling" (not necessarily in the strict software sense) for doing iterative designs. In software development, we've already developed approaches on how we can iteratively deliver features (sometimes half-baked or "unfinished", but still delivering "value"), and we've developed an understanding that this is how we get to a final solution (and an understanding that we might need to cut scope, and any one of those iterations might be the final result for the time being). Even with all the rage tools like Figma get, it still requires each designer to come up with an approach that will effectively communicate intermediate usable design steps on their own, and it feels like that's still missing with most designers. Perhaps the agency background that a sibling comment mentions is what's part of the problem, but just like with "design systems", I am sure even better "tools" are going to come soon as this problem is better articulated and taken upon by designers working embedded into software teams.
KronisLV 4y ago
> The root cause I have found is getting designs done in isolation and then treating the Figma/Sketch/whatever file as a hard business requirement, instead of treating the user experience as a collaborative exercise that is a tradeoff between usability and feasibility. I've actually seen this happen when the development stages of either part are wildly out of sync. The design folk finish a mockup of the UI and figure out how the components should look... while the developers are struggling to get the back end up and working properly, talking with the front end etc. And so the developers can't feasibly put the design demands in place, without ignoring other important needs. So while one part of the team is talking about how the dropdown components and multi-select components should look, the other is struggling to get all of the API endpoints up, the DB migrations done, the server/container configuration working properly, put package updates in place and fix various bugs and issues, as well as write tests. Some companies do distribute those responsibilities amongst multiple teams, but I've definitely seen cases where there are designers whose responsibilities are way unbalanced with those of developers, who are putting out fires a lot of the time and doing other stuff, creating friction and complicating communication and collaboration between them. In those cases, making the dev team 2-3x larger may help (or may make everything worse, it depends), yet it doesn't seem to occur to anyone working on the project.

542458 4y ago

I agree with this. I always tell people that the designs aren’t carved in stone or written in blood, and if something looks or feels wrong to bring it up. There’s no point in the process where the design can’t be improved, and anybody can be the one who finds an opportunity for improvement. And there’s also no shame in changing a design to make it easier to code. Ultimately no design is ever finished, and anything can be adapted or improved.

jacobyoder 4y ago

UI/UX has to be treated as an iterative process. Collaboration between multiple parties (eng/dev/design/pm/etc) is almost orthogonal to the root problem I've seen: "design" gets treated as "this is it" and the moment you start being 2-3 pixels off, or a shade of red isn't what was in figma/ps/etc, "you're deviating". "These were already signed off/approved/whatever". "But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile." "Stop deviating - we already interviewed customers!" "But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc" "Stop deviating". I've had a couple of good experiences working with a couple design folks in the last year, but EVEN in those cases, "design" was sort of treated like "one and done". Once the product is in the hands of real users, feedback - implicit and explicit - comes in, and there should be processes in place to make rapid adjustments - possibly multiple iterations - to deal with the feedback. That's one of the biggest hurdles I've seen, even when there's decent collaboration and respect.

recroad 4y ago
I've found that there is a mindset issue with designers that needs to be addressed if they are working closely with software development teams. If you come from an agency background then you are conditioned to only show perfect/close-to-perfect stuff to your clients because you don't want to leave poor first impressions. It's why there are multiple reviews and approvals before you show anything to the client. You want repeat business and a "failed" design would be treated as a strike against you. When working closely with teams there is no need for that and you can bring in low fidelity artifacts like sketches for feedback without fear of the whole design group being judged. This is a big change to how designers generally work when they're employed by agencies. Unlike agencies, this is a safer environment (all things being equal) where imperfection might be rewarded by engineers, but unfortunately, the agency mindset is retained. There definitely are ways to improve how we work together by playing some games, doing activities like assumption busting, diverge-converge design sketches etc. but the organization has to prioritize this mindset shift. The chance of it happening organically is limited. There are issues the other way as well: developers are often conditioned to expect perfect designs for fear of "re-work". I find good software design, solid testing practices and EMs with an eye to ways of working (not just technical stuff) can help address that.
- tolkienfanatic 4y ago
  My previous company almost exclusively hired designers from agency backgrounds - it was a huge problem.
corrral 4y ago
Part of this isn't designers, but "stakeholders" and managers and such wanting to put their stamp on things. They often do this through design, I suppose because you can show anyone a screenshot in a powerpoint and they can appreciate it, but you can't show everyone a program logic flow chart and have them appreciate it. One way to push back, if you use anything like story points for estimation and scoping, is to point low-design and high-design options separately, for any elements where design choices may have a major effect on that. "This is a 5-point feature with a basic button with the correct brand colors and a spinner for busy state—but a 13-point feature with what's presented in the designs, including a bouncing hover animation and the button morphing into the company logo as its busy-state et c." Part of the problem is the cost of design on the development process, not just making initial mockups, is often ignored or not correctly accounted for. If you make it explicit, lots of times it turns out a simpler version (which is going to be better for users anyway, 90% of the time—but being good for the users isn't the reason for a lot of UI design, see: constant user-hostile but flashy redesigns across the industry) is in fact acceptable if it means you can fit another feature or two in a given sprint. "We can come back and do the fancier styling & behavior later when we have less feature development to do" but then, as with most things that get deferred, you never will, which is for the best.

deltarholamda 4y ago

Agree. In my experience, the design team tends to work closely with the client and the dev team is either silent or left out. Silent, because offering opinions on how something affects the backend may be completely moot when the next iteration is developed; or left out, because the dev team can't communicate "you can't do that" to the client in a way that doesn't sound annoying. The project manager's primary job is to keep the client happy, so they tend to overpromise. Which is weird, because (especially in Web design) they client was more or less happy with the limited set of functionality that Facebook gives them. They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit.

corrral 4y ago
> They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit. I, for one, am extremely skeptical that the intense focus on making sure every little thing on every page or app is "on brand", and the significant costs that preference incurs, has positive ROI. Nonetheless, every company seems to have become obsessed with it.
- deltarholamda 4y ago
  >Nonetheless, every company seems to have become obsessed with it. You don't have to know much to have an opinion about it, therefore everybody does, and it's the most important thing in the world to them. "Normalizing the database? Wha? I'm not technical, guys, I'm more customer focused. We really need that sidebar to scroll with the page, let's work on that."

necovek 4y ago

I feel like the biggest problem is the lack of "tooling" (not necessarily in the strict software sense) for doing iterative designs. In software development, we've already developed approaches on how we can iteratively deliver features (sometimes half-baked or "unfinished", but still delivering "value"), and we've developed an understanding that this is how we get to a final solution (and an understanding that we might need to cut scope, and any one of those iterations might be the final result for the time being). Even with all the rage tools like Figma get, it still requires each designer to come up with an approach that will effectively communicate intermediate usable design steps on their own, and it feels like that's still missing with most designers. Perhaps the agency background that a sibling comment mentions is what's part of the problem, but just like with "design systems", I am sure even better "tools" are going to come soon as this problem is better articulated and taken upon by designers working embedded into software teams.

KronisLV 4y ago

> The root cause I have found is getting designs done in isolation and then treating the Figma/Sketch/whatever file as a hard business requirement, instead of treating the user experience as a collaborative exercise that is a tradeoff between usability and feasibility. I've actually seen this happen when the development stages of either part are wildly out of sync. The design folk finish a mockup of the UI and figure out how the components should look... while the developers are struggling to get the back end up and working properly, talking with the front end etc. And so the developers can't feasibly put the design demands in place, without ignoring other important needs. So while one part of the team is talking about how the dropdown components and multi-select components should look, the other is struggling to get all of the API endpoints up, the DB migrations done, the server/container configuration working properly, put package updates in place and fix various bugs and issues, as well as write tests. Some companies do distribute those responsibilities amongst multiple teams, but I've definitely seen cases where there are designers whose responsibilities are way unbalanced with those of developers, who are putting out fires a lot of the time and doing other stuff, creating friction and complicating communication and collaboration between them. In those cases, making the dev team 2-3x larger may help (or may make everything worse, it depends), yet it doesn't seem to occur to anyone working on the project.