14

What have been your frustrations with working on your team?

almost 4 years ago from , Founder at Professor Beekums

I've spent a lot of time working to help product teams (designers, developers, product managers, testers, etc) communicate better and work more efficiently. Would love to hear the struggles other people have had on their own teams.

13 comments

  • Andy MerskinAndy Merskin, almost 4 years ago

    Typical things that come up. Some are situations that just need someone to speak up and constructively confront the issue from the product perspective. Others speak more broadly to management problems that affect teams:

    • Not applying (or at least trying) critique feedback and ignoring it altogether, no justification, no questions, just flies into an empty void
    • Watching as the group agrees on a crappy solution when there's ample time and energy to explore more options
    • Allowing a dominant person to make the calls in the product's design because he/she likes it, without further justification or concern for usability
    • Determining scope, timelines, and jumping to solutions before the team is even involved
    • Mysteriously abandoning a project and reassigning team members to do something else without explanation
    • Assigning key project members to a different project and having a brand new team come in and try to wrangle something they're unfamiliar with
    • Opting not to use a project management tool (like Basecamp, Trello, etc.) and instead use sticky notes and managing hundreds of emails, and having to tell each other what you're working on multiple times per day
    20 points
    • Eythan D'AmicoEythan D'Amico, almost 4 years ago

      "Not applying (or at least trying) critique feedback and ignoring it altogether, no justification, no questions, just flies into an empty void"

      This a million times.

      0 points
  • Katelyn Caillouet, almost 4 years ago
    • No goals or ambiguous goals like "make more money"
    • Product owners writing stories with zero requirements and then asking "when will this be done?" repeatedly
    • No concrete deadlines, or if there are deadlines, they are extremely rushed
    • Lack of strategy behind the overall product which makes designing for it feel like sword fighting in the dark
    • General communication problems, especially with feedback ("I don't like it," "What don't you like about it? Keep in mind we're trying to appeal to our users")
    • No shared resource storage, which leads to a lot of forwarding files around, people getting upset when said file hasn't been forwarded to them because "they should see it too"
    • Power struggles between the design team & the marketing team
    • Marketing team unconcerned with usability issues and thirsting for more leads at any cost

    I've experienced these problems at most places I've worked.

    3 points
    • Marvin Hagemeister, almost 4 years ago
      • No concrete deadlines, or if there are deadlines, they are extremely rushed
      • Lack of strategy behind the overall product which makes designing for it feel like sword fighting in the dark

      Oh my god! Just this! So many projects could've gone a lot smoother if it weren't these 2.

      3 points
  • Stephen Hill, almost 4 years ago

    Like Andy mentions really....

    Although I've been in my team for a year or so now, I'm the first UX / UI Designer to join our in house Development Team. Because of this, people don't know how to treat me i.e. what rules and processes do we need to follow. The Developers do however.

    We've got the basics right e.g. I'm called upon when big features need to be scoped out properly from a set of requirements and I tend to work 2 - 3 sprints ahead of the rest of the actual development team to allow me team to complete the work and hand it off to the front-end team to pick up without delay.

    Common problems are:

    • Poorly put together requirements from a part-time product manager, which in turns leads to unforeseen changes when the front-end team picks up the work. Changes which change my designs massively. To the point where my original designs are redundant.
    • 'Signed Off' designs changing when it comes to final development because the developer prefers it a different way. I obviously make my point about user research etc... but because the developer is more 'senior' and baffles me with developer speak about how much harder it would be, and how it would cause further delays - I feel like I'm forced to give in.
    3 points
    • Katelyn Caillouet, almost 4 years ago

      Omg that last bullet point — but the developers I work with are more junior, so they usually say something would be more difficult and would add more scope. What they really mean is they don't know how to do it and they're unwilling to learn.

      5 points
      • Darrell HanleyDarrell Hanley, almost 4 years ago

        This is such a major problem with developers. I'm robust enough as a developer myself that I'm able to call bullshit and essentially dictate a path that I know the design could work in, but I've heard so much bullshit about why a design wouldn't work. Scale seems to be the go to excuse if you can't think of a better technical reason.

        2 points
      • Stephen Hill, almost 4 years ago

        My go to response now is always to suggest putting the two versions up for testing internally to see what our internal users prefer. The majority of times I come out the winner because inevitably mine is more usable. Then it's up to the developer to fight the battle of time vs. benefit to the product owner.

        Sounds like a cop out - and to be honest it is.

        EDIT:

        Oh and another thing I've just thought of in the battle of Design Vs. Developers is the whole "we don't do that elsewhere, so why should we do that here...". Take for example in the last couple of weeks one of my designs used a slider for a form. Amazingly it's the first time we've ever had the need to use a slider on one of our forms and the response from the developer was that because we didn't use it anywhere else on the site - we shouldn't use it here. I was astounded.

        My response was just because we haven't used it anywhere else doesn't mean that it isn't the right solution for this particular problem! I get it. Developers want to re-use as much code as possible - but this was just a massive cop out!

        1 point
  • Marcel van Werkhoven, almost 4 years ago
    • Testing, testing, testing, people never test enough

    • Commits and versioning (oops, I forgot to commit my changes last week...)

    • Priorities: "I didn't complete this more important task, but did spend my day polishing this button. This is now the best button ever." "I never asked for this"

    • Deadlines: "Despite the fact that we discussed it this morning, there's a huge note on my desk and 33 e-mails about today's progress from our client... honestly I didn't know TODAY was the deadline."

    • Breaking things that work: "The old code worked right?""Yes but it wasn't 'good' so I've rewritten half of it today" "Does it still work?" "No, we need to rewrite everything else too" "But it did work?!" "Yes, but... now it runs better or rather it will"

    • Meetings without results: "Status?""Well, we had a great meeting, I think we've nailed it" "It took about 2 or 3 hours, must've been productive. What about notes? A plan, anything on paper?" "Well we haven't decided on anything yet so..."

    Over the years I figured out it's very important to know what drives the other team members. Some are very ambitious, others value teamwork, some just want to get paid more. Also, some developers never seem admit that they can't do something even if it's practically impossible.

    Finally clear goals. Until you know exactly what the 'goal' is, don't start on anything. I've seen projects being worked on for 6 months without any clear result. Sure all SCRUM tasks were met, status was reported etc. but no one had the slightest clue as to what end result they were working towards. Usually this happens halfway during projects. People lose track of the end goal and the bigger picture and they're too far along to go back to start, so you end up with something in development hell.

    1 point
    • Laura McCartney, almost 4 years ago

      Also, some developers never seem admit that they can't do something even if it's practically impossible.

      That's because nothing is impossible, it's just usually not worth the time and effort.

      1 point
  • Dirk HCM van BoxtelDirk HCM van Boxtel, almost 4 years ago

    Nothing too tough, other than dealing with being heavily under-resourced due to cutbacks.

    0 points
  • Cory MalnarickCory Malnarick, almost 4 years ago

    Everyone has their own workflows, and deadlines prevents standardizing workflow. Things such as canvas headers, layer and symbol naming conventions, etc.

    Folks are too bogged down with work.

    I'd like some time built into our schedules to get everyone aligned, but that's a big ask for many reasons, the most frustrating reason being no one cares as much as I do to get everyone aligned.

    0 points
  • Matt WalkerMatt Walker, almost 4 years ago

    Getting into a rhythm of time-boxed cadence for research, testing, and pairing. It can be a juggling act sometimes between meetings, and having actual time to design, think through problems, and synthesizing the research.

    But if that's the worst of the problems I'd say we're doing pretty good.

    0 points