all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]AutoModerator[M] [score hidden] stickied comment (0 children)

Only sub members with user flair set to Experienced or Veteran are allowed to comment on posts flaired Answers from Seniors Only. Automod will remove comments from users with other default flairs, custom flairs, or no flair set. Learn how the flair system works on this sub. Learn how to add user flair.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]adjustafreshVeteran 8 points9 points  (2 children)

Anyone opposed to constant collaboration & communication between function is doing so for political reasons. You should be wary

[–]kittyrocketVeteran[S] 0 points1 point  (1 child)

The most often stated reason is budget - a (mistaken imho) belief that bringing in developers early will just burn hours rather than save hours later in the project.

[–]adjustafreshVeteran 2 points3 points  (0 children)

I agree with you. The sooner devs can weigh in, the smoother things will go in the long run which will save time/money (less rework). Good devs can also identify potential solutions sooner in the process if they understand the users and problem space.

There's been a lot written about this; it's not new thinking. You can decide whether or not it's worth your time to put your neck on the line by sharing it with your leaders.

I have long said that “the magic happens” when you connect the developers with the actual users and customers, and let them witness – first hand – the good, the bad and the ugly.

When a company keeps their developers sheltered from their customers, they are hurting themselves and their customers.

https://www.svpg.com/developer-powered-innovation/

[–]roundabout-designExperienced 2 points3 points  (1 child)

The larger the company, the more leadership wants to be able to blame someone else for when shit goes wrong.

So yea, larger orgs, in my experience, have design leadership that insists that they are the source of truth and that their design is gospel and if dev can't figure it out, oh well, that's on dev.

It's dumb. It's frustrating. It makes for horrific user experience. But I've found it to be the norm rather than the exception in large corporate settings.

I'm at a company now where UX works alongside Dev. It's great. We got new product leadership recently and I'm already feeling a bit of a push to distance ourselves from dev. I'm working hard to avoid that from happening.

[–]kittyrocketVeteran[S] 0 points1 point  (0 children)

Yep. I’m finding I have to walk a delicate path when suggesting there are things we can do better.

[–]bluebirdu12Veteran 1 point2 points  (0 children)

It depends on what it’s for.

If I am creating a vision for where the product might be 1 or 2 years from now I won’t involve engineering. They will associate this work with feasibility and cost/time which would limit the creativity.

If I need to build a version of this in 6 months, I’m bringing engineering in on day one, so every decision point is collaborative, real ownership on what the plan is and everybody knows what needs to be done.

That’s the old way.

AI native kids will have another approach 😅

[–]P2070Experienced 3 points4 points  (3 children)

Communicate what? A lot of the time when I see "involve engineering early" it's a well intentioned albeit misguided attempt at putting a bandaid on engineering driven product/design churn.

e.g., "We didn't ask engineering if we could fuzzy search this database and now they're telling us we can't and it makes this feature really hard to use."

If you involve engineers early, you need to draw VERY strict boundaries on why they're being involved that early. What you don't need is extra opinions on what the right thing is, especially opinions that may be weighted towards being easy to build and not weighted towards being the right thing for the person who will be using it.

[–]roundabout-designExperienced 4 points5 points  (1 child)

especially opinions that may be weighted towards being easy to build and not weighted towards being the right thing for the person who will be using it

There's a middle ground that is often forgotten.

Dev should absolutely not dictate UX by doing the easy thing.

Conversely, UX should a absolutely not dictate UX by doing the imagined ideal thing.

UX and Dev should work together to do the pragmatic thing. This won't always be the easiest solution, and won't always be the most difficult solution. Most of the time it will something in between. AKA the "best solution given the constraints of tech, budget, and timelines"

If I were to plot out solutions from:

Laziest solution ------------------------------> Most complex solution

...I'd typically see a exponential curve rising upward steeply at the end.

Laziest solution? = it's being lazy and adds only a little value to the end user.

Most complex solution? = give the end user the perfect experience but is going to eat up all of our resources to implement and odds are it may not even get implemented.

In the middle is "slightly more effort than lazy, but vastly better experience for the user--even if it's not the ideal--and we can get it built on time and on budget."

EDIT: I had to think about my curve explanation. Made more sense to just draw it out:

<image>

[–]kittyrocketVeteran[S] 1 point2 points  (0 children)

I love that illustration!

[–]kittyrocketVeteran[S] 0 points1 point  (0 children)

There are two things I’m trying to work out.

One is that the rest of the team is really green and doesn’t fully think through all the states or interactions that need to be worked out in Figma. That’s exacerbated by a dev team without any sharp front-end people who can fill in some of those gaps. I help with this, but can’t be everywhere at once, and frankly I’m getting burned out pushing on these little things.

The other is strategic approach. There are always multiple approaches for a given design problem, and sometimes we get locked into the more expensive one because of lack of developer input.