When building something new, try starting with an embarrassingly simple UI wireframe. It doesn't have to be perfect, just trying to capture the bare functional minimum. The goal is to start cross-functional conversations as early as possible and get early feedback from the end user.

Such wireframes seem especially important if there's no UI/UX designer available, or if the designer doesn't have the capacity to understand the project in depth. The wireframe doesn't have to be started by a product manager or a frontender; a backender can do as well.

For the initial wireframe, I like google sheets. We can focus on functionality over form, and people are familiar with the tool. Also, we often already have a project-specific gsheet, so it's a natural fit.

Cross-functional discussions over the wireframe often open up interesting questions. Sometimes, the questions touch upon strategic choices about customer experience, the frontend stack, or the backend architecture. For example:

• This task is async on the backend. Do we notify customers async, or do we keep customers waiting for the result to appear on the page? What are the downsides of switching to sync? How are we handling async in other flows?
• Is our data model on the frontend/backend/db aligned with the domain language concepts we are working towards? Do we have all the data we need on the backend?
• How will we handle unhappy paths? What will we show the users? How do customer care agents currently handle async unhappy flows? What's their experience? How can we improve that?
• For internal projects: Would new colleagues understand the process if there's employee turnover?

All in all, wireframes seem like a cheap and fast way to help prevent surprises down the road and increase cross-functional alignment.