UI/UX design feels like waterfall, What do you think should be the proper process?

Question

I'm currently working as Fullstack developer, our frontend is being built in React.

Our current process involves:

1. The client / product owner describes a feature to the UI / UX designer.
2. The designer creates a nice template in Figma, or any other UI tool like-so
3. The design is given to us the developers to implement
4. The code is written, then QA'd, any differences between the design and the product are flagged as bugs

That's fine a dandy for small features, but let's say we want to write a DateTime selector, as you might know, these are complex components, so ideally we want to look at existing components that are open source and solve our problem.

But is going to be really hard, even with advanced tweaking to make a built component look like your design, and building the component from scratch is an ardous task.

So my ask is, What is the proper course here? Should we (as developers) grind our teeth and create the component? Should we send back the design? Or try to match with an existing component and diminish the inadecuacies between the built component and the design?

Answer 1

What you describe doesn't feel like waterfall - it is waterfall. One of the twelve principles of Agile Software Development is that "business people and developers must work together daily throughout the project". Today, the phrase "business people" is interpreted to mean project and product managers, which often include user experience designers. Your current process doesn't the key stakeholders working together in a collaborative environment.

From an agility standpoint, the recommendation would be to get more people involved earlier. People with expertise in development and test would be involved potentially as early as talking to the client or product manager, but certainly by the time the UI design was being created in your UI mockup tools. The UX designers, developers, and testers would have real-time conversations about trade-offs between existing components in a component library, open-source components, and the effort to build and test custom components and what the best options are to satisfy the stakeholders. The collaboration would continue through the release, with everyone involved at every step of the way.

However, no one here can tell you if this way of working makes sense for your organization or team. There may be organizational impediments that prevent this highly collaborative way of working, and until those are resolved, you may have to have other mitigations for the risks associated with working sequentially and having hand-offs and late testing.

Answer 2

Agile would say do an iteration with the quick off the shelf component and add more stories, each estimated for where it falls short of the desired goal.

The problem is this relies on the customer, internal or external, buying into the core idea of any Agile methodology. That half a solution has value.

If your customer wants the exact design and nothing else, then they haven't bought into that idea. You can still internally iterate but there will be a disconnect between your internal agile process and what you show the customer.

So, your question boils down to "What is the best process to produce something with immutable specifications?" The answer is Waterfall. People use Agile because they know that for lots of problems, an early partial solution has value and a late perfect solution has no value.

I believe that that tenet has been proven and you should use an agile methodology for the component in your example. Your customer will find value in a partial solution. The only question is whether your relationship with them is structured in a way which allows them to blame you for the shortfall.

Answer 3

The problem with what you describe is very common. The team is receiving requirements, not creating them collaboratively.

Agile principles:

Business people and developers must work together daily throughout the project. The best architectures, requirements, and designs emerge from self-organizing teams.

In the common scenario you describe, the Product Owner and UX have decided that the team doesn't need to talk with stakeholders, and doesn't need to be involved with writing requirements.

There's no one-size-fits-all answer. Sometimes they will come up with decent requirements. The problem is that if they're not technical they may only see a certain range of solutions to the client's problems. (UX designers have a tendency to look for solutions that involve a UI.)

Other times they'll come up with requirements that don't make sense from a technical perspective.

In either case, they're likely to have meetings where they tell the rest of the team

This is your opportunity to look at the design and ask questions.

That's not collaboration. That's a nice way of asking

Do you understand what we've decided that you're going to do.

Again, I can't propose a one-size-fits-all solution. I'd recommend something more like this:

• Everyone working on a product has some degree of contact with users and stakeholders, even if it's occasional meetings. Developers should be able to straight to users with questions. If there's concern that developers will say the wrong thing and make promises, well, don't do that.
• When the team understands what problems the user needs to solve, they discuss possible software solutions. Again, stakeholders and users should be present.
• When everyone agrees on a likely solution, they design it together. If you have a UX expert on the team they can contribute a lot to this. If you want to sketch something out together and let the UX designer create a polished version, go for it.
• Build the product.
• If the UX designer thinks something should be two pixels to the left, they can use their hands to go into the code and change it.

UX designers are valuable, some more than others. They must act as part of the team. They are not above it or outside it telling it what to do. Neither Product nor UX should interfere with the communication between the team, users, and stakeholders.

---

I'll allow for one big exception: If you're Amazon or Pizza Hut this might not hold up. Maybe you need an uber-UX-expert who monitors peoples' brainwaves as they look at different designs. Maybe the choice between A and B means millions of dollars. In that scenario I understand if a company prefers to do more up-front design.

That's the exception, and even then UX shouldn't go too far off the rails before consulting with the rest of the team.