In object oriented, we have requirements, use cases, and UML which can form a nice conceptual framework. The goal there, is to define objects, their responsibilities, behaviors and communications between them.
What would be the equivalent in functional programming world of objects / responsibilities, behaviors and communication to define a high preview of our program structure ?
Not sure this is going to entirely satisfy your question, but hopefully gets near.
Requirements / use cases / functional specs / whatever-you-call-them are still great tools for communicating an FP program design. But a visual design model for FP programs is a little less interesting. It amounts to defining inputs and outputs for each use case, and a function mapping the input to output. Boring right? Ok, some explanation...
An OO class is often the owner of 3 different concepts: current state of data (an implicit concept), structure of data (properties or getters), and behavior on data (methods).
FP -- as in: programming with pure functions -- generally only deals with 2 of those things. Structure and Behavior. Current state is pushed to the edge of the system as a persistence concern. So for example, a module responsible for Product would know what properties it had (structure) and what operations you could perform (behavior). But you have to tell the operations the current state of a Product before it can perform the operation. It will then return a new copy of the Product with changes applied.
You could model this in UML as a class with only static methods for behavior. And a data class where all properties are read-only for structure. The data class would be used as part of the input/output on the behavior methods. But connecting these to other modules is where the UML-type design would break down, because...
With OO, you often have a lot of interconnected classes communicating with each other. Each one of them owns some part of the state that the system needs to operate. But with FP, modules like Product described above are typically self-contained and independent since they hold no state. They are "connected" only in that higher-level functions (i.e. use case functions like placeOrder) will call the more-specialized functions (like Order.validate and Product.canBeOrdered) to help convert the input into a return value.
This is where tools like UML fall down for FP because they are essentially modeling state graphs, but functional programs are more like function call hierarchies. A probably more useful way to model functional programs is with data flow diagrams as mentioned in the comments of this question. You could also use a nested flow chart where each decision step has its own separate flow-chart to describe its internal flow.
I would assert that modeling the specialized functions is a waste of time. These are often small and pure functions are easy to refactor, so they could be updated frequently. You might get a lot of churn in updating your design model if you go down to that level. Probably the lowest level you want to make a design model for are the use-case functions.
However, I haven't observed program design models as common practice in FP (not that UML is common either... never used it professionally myself). The extent of most FP design methods I have seen are just defining function signatures from the top down in code. Then as you fill in the implementation, create fn signatures for the more-specialized functions. Organize those into modules and then start working on their implementations. Just keep going down this recursive process until you hit turtles.
Edges
The edges of a system are where things start to get more UML-compatible. Since programs do, in fact, need to know current state to be useful. This is where you wire in the various technologies like databases, external API calls, etc. This system-level design is about the only kind of diagram I ever do.
Otherwise defining use cases with their inputs and outputs (visually if you wish) is the level at which you would make a design model of a functional program. Define input structure, output structure, and a function which maps the input to output.
