Designers should have enough time up front to interview users, define the product and services, build a business plan, and design the application; just as architects need enough time to plan the project, analyze risk, and determine the systems design; IT needs enough time to figure out the server and network plan; and operations needs enough time to forecast staffing and define processes. This means weeks, and sometimes months, of calendar time ahead of encumbering the full dev team (and you better not roll all your devs into sprint zero in a big bang for the same reason), but it doesn't mean doing a full waterfall, either. It's just that if you have a must-deliver project, you need to have an atlas ready to go, even though the turn-by-turn directions will emerge through the project.
Even when designers go into refined visual design mode, the solutions plan should have them running at least one, ideally two sprints ahead of development to prevent starvation. My suspicion is that he's been a victim of the "let's throw everyone into the same timebox" scenario that projects default to in the absence of real solutioning and project governance. When "agile" is used as an excuse for a lack of planning, everyone suffers.
One thing my old BigCo does right is put a solution level between sales and execution that has veto authority on any project -- our job was to manage everything from scope to risk to staffing and timelines going into the deal, just to ensure that projects would run as cleanly as possible.
If a client balked at the time or price of a project, then we'd step in and renegotiate scope, risk mitigation, expectations, and responsibility until a balance was struck. If, after all that, we felt that a project was too high-risk, we (or any partner tasked with oversight) could pocket-veto the sale by refusing to sign off on it. (It's a testament to the sales teams that I rarely had to exercise that veto; out of those times, twice I had a veto overridden by partners higher up the food chain, and both times the projects failed along the load-bearing lines we identified.)
It doesn't always work out as planned, of course, but, in my experience (over a couple hundred million dollars' worth of work), we stuck the landing much more often than we failed. Trying to do this inside a company is a significantly different and more difficult experience, certainly, and it only works if the c-suite puts their muscle behind a disciplined innovation process that can exercise those same kinds of authority across internal silos.
I'll also point out that BigCo aligned on this overall approach because we, like most strategy/tech consultancies, experienced a lot of failures to launch, and burned out a lot of developers and designers along the way. When half the firm is coming out of massive waterfall-style projects that often fail because they're brittle and push risks to the very end, and the other half is used to just throwing devs at two-week timeblocks until something ships or everyone quits, you've got to find an approach that gives you as much knowledge and shape up front as possible, while still letting the development efforts come together flexibly through the dev process. Kudos to them for getting that done.
Even when designers go into refined visual design mode, the solutions plan should have them running at least one, ideally two sprints ahead of development to prevent starvation. My suspicion is that he's been a victim of the "let's throw everyone into the same timebox" scenario that projects default to in the absence of real solutioning and project governance. When "agile" is used as an excuse for a lack of planning, everyone suffers.