0

My problem is how to improve and make my workflow efficient. For example, I have a task. I do some research, prepare layouts, make a presentation. But I feel that this is not enough.

Communication with the team is strained. And I think for the most part I don't cooperate with the team, but I fight. Moreover, I try to listen to everyone and take into account every opinion and idea.

All this makes my workflow infinitely long. Tasks can take years. And everything goes in a vicious circle. But maybe this is due to project specific. On the other hand, we do not have much practice of presenting any diagrams and comprehensive studies, in fact, clients do not want to invest in this. The current process is simple - get task in common abstract details, prepare some variant and demonstrate mockups and user flow description.

In general, I thought, what is the general workflow of designers? What can be proposed to interest the team in effective communication? Could you give me some advice or source?

Improve this question
2
  • It sounds like you are designing more or less in isolation, going back to your team with a solution, and then they are vetoing it - is that correct? Commented Oct 26, 2022 at 13:39
  • 1
    well, yes and no. I'd rather say that I'm designing in isolation but then on presentation a lot of opinions come ups - like a teamwork from developers, managers, salesman and so on, and they never can agreed with something solid. Commented Oct 27, 2022 at 13:08

2 Answers 2

Reset to default
1

Oh man, this can be a tricky situation. I have been there and it can be very hard and really demoralizing. In many cases you CAN overcome it; in others, you may realize that the process will never properly incorporate user perspective and your work, and it may be time to consider other options. I've been there too.

Some of this may be purely relationship building, some may be the possibly painful but often necessary task of evangelizing and educating your development team - and possibly your product owners. Decisions should come from the product team, so if you can get them to prioritize time for research and up-front ideation/flows/wireframes/research/etc. BEFORE the development team has begun building things, it will make your collaborations easier and create a better product in the long run.

Some of it also may depend on the development team's process. Is your team working "waterfall," some flavor of Agile, Rapid, Lean, XP, something else? Not all of those play as nicely with design unless it is deliberately integrated into the process. Again, the product owner usually has to define and enforce the process and flow of work. If Engineering managers are part of that process - or the product owner is an engineer at heart - it can complicate things... in which case the education piece is critical.

I had a development team that not only barely knew we existed, but had no real idea what we did or why we could be useful to them. A colleague and I did a series of road-show short presentations about UX, why it matters, how we can help, and some things to keep in mind when we aren't around (because we had a ratio of like 80:1 eng:UX at that point). The basic points of the first two presentations are in the comments of these videos - the videos were meant to be entertaining ways to drive some of the points home (and yes, they are silly, but meant to make some of the details more memorable - it sort of worked):

Intro - Who we are and how we can help: https://vimeo.com/132271405

Design Principles - Gestalt: https://vimeo.com/132273309

Ok - I'm sure you know all this, but for any newbies out there: Ideally as new features/functions/updates come along, the product team prioritizes them - with your input for user perspective - then gives you and maybe an architect some time to work with them to define the requirements (business and user) for the thing, possibly with some research input. Then you and the product team work together to define how all of the controls, options, parameters, and data need to come together in a nice flow for the user to get the task done. Then wireframe out the flows based on your expert understanding and the team's guidance, and run it by some users to see if it makes sense. Iterate, redesign, and make sure the dev team is involved - they will help understand level of effort, system limitations that might affect your designs, etc. When things are deemed solid, mock it up (or possibly not if you have a component library), and get it over to the devs for building. Make sure to offer to work with engineering and be available for questions, and have them include you in demos. Try to partner with QA and have validation of the designs be a part of their process for vetting the engineering build.

Sometimes you will just be fighting against business priorities, which will almost always win. It is possible the business truly does not care about putting resources and effort towards improving their user experience - either because they don't really understand the benefits of putting time into a proper product design process (counter with evangelism and education); they might simply have larger priorities or immediate system limitations that mean they can't do what you know is best (make sure you have a backlog of issues that need fixing when time and system can accommodate them); or it's possible they are "X-washing," which is my term for when companies hire UX teams to say they are user focused, but they don't let them do any substantial work or ignore all of their recommendations that might cost them anything extra.

Good luck with this - it's the existential struggle for UX in a lot of cases, and you are not alone. Let me know if I can help any further, or just be part of your support group :-)

Improve this answer
1

It sounds like you are working with stakeholders who are poorly aligned with each other, which is unfortunately a common scenario for us UX designers. They might even be in conflict, and you're caught in the middle of some political battles that are indications of a larger problem in your organization.

In these cases, it's helpful to shift the feedback loop earlier - before you start wireframing, even. Try to get as many of the key stakeholders (with the power to veto your design) in a room together and lead them in an alignment exercise. Ideally you want them putting as many assumptions out there as possible so they can be validated or challenged. Find out where disagreements need to be researched and resolved with data.

Some questions to cover:

  • What customer problem are we solving with this design?
  • Who will be using this design? (As specific as possible. If they say "everyone!" then push back and ask them to be more specific. Usually you're not serving 14-year-old students and 80-year-old retirees at the same exact time.)
  • What are your target user's goals and struggles?
  • What would this ideally be replacing? (An earlier concept, a competitor's product, a spreadsheet...)
  • What is our metric of success? How will we know we did this right?
  • What constraints are we dealing with (time, technology)?

If you're not whiteboarding with this group, that would be a good next step. Once you have your assumptions and goals written out, put them on the whiteboard and start roughly blocking out information and functions. Some groups do co-design exercises where everyone sketches on paper, which are good in cases where you have one or two dominating stakeholders who want to control the discussion.

After you've co-designed as a group, then it's your turn as the designer to use all that feedback and data in a design that makes sense for the user. Get some early testing done and use the feedback to bolster direction if you get pushback after designing. Show videos of users expressing delight or struggles if your group isn't believing you.

Good luck. It's a tough situation. Remember that calm seas don't build skillful sailors.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.