No, you do not need sketches.

You have asked for mockups of how that new thing you are building is going to look, but your project or organisation is not ready for them.

You need data.

You need data because you are asking a designer to make design decisions: where information goes, how stuff hangs together, what people need to be able to do. But the designer is asking a lot of questions you can’t answer: how many people will use this, what the majority of users would do here, and about today’s worst (and most costly) issues. You aren’t measuring any of these things. And because you aren’t collecting this information, the designer is stuck and you are stuck, because neither of you can make design decisions that prioritise the most important things.

You need to prioritise the most important things.

Because there is no data about what is most on fire or which functionality is most used, each decision about how things should be seems to have equal weight. Schedules for the work to be done do not front-load the most urgent or important things; neither do discussions. The amount of time spent discussing a thing is not in proportion to how important it is. Because nobody has oversight of organisational goals and how those relate to user needs today, discussions are also easily hijacked by people who care more about a particular thing than anyone else, even if that thing is not important.

You need oversight of how organisational goals relate to user needs.

At the moment, people who do similar jobs work together on their piece of turf. Everyone is very happy that they have control over their piece of turf. Attempts to map the entire customer journey/user experience founder for lack of budget, but also because it’s super easy to ask untrained people to use shitty software to make a shitty map that nobody gets any real value from. Consequently, nobody has oversight of the whole. Which means that today’s user experience reflects your business model, internal structures, politics, and jargon — and that the people who own different parts of the map are not sufficiently incentivised to work together. The user interface is not designed around models that reflect your organisation and its customers.

You need models.

Because your organisation is not in the habit of talking regularly to users of today’s system, the words they use to talk about it, and the mental models they have formed about it, are a mystery. Today’s information architecture and navigation is based on internal reckoning from 15 years ago, not what people need or do now. It is also difficult for developers building the new thing to construct a data model, because even if they can get access to subject specialists, the latter operate at the level of “Let me read you several contiguous Bible verses”, rather than “So, there’s this thing called the Book of Job”. What subject specialists and developers do have in common is that neither is regularly exposed to the needs of people using the system today, because the organisation has not identified regular user research as a priority.

You need to prioritise regular testing with real users.

At the moment, you only test something right before the big-bang launch date, and testing is largely limited to discovering technical errors. Then there’s a big last-minute scramble to fix the problem. Any internal people who test whether the system is easy to use have way too much inside knowledge to be useful. After launch, there is a flood of calls to your support services about things nobody inside the organisation had thought of. Because all work is scheduled 2 years in advance, it will be at least 6 months before you can start engineering a solution. (This does not stop the phone from ringing in the meantime.) Feedback loops are long and lossy.

You need shorter feedback loops.

Because everyone has their own turf, it takes a lot of organisation to get people from different turfs just to meet. Things are sent for approval; eventually they come back, and then renegotiation commences. People who will actually be building the new thing are not usually represented in those conversations. And it’s very seldom that everyone in a meeting is empowered to make decisions about the thing under discussion.

You need cross-functional teams, empowered to make decisions.

At the moment, your organisation has not prioritised hiring and allocating relevant specialists to teams who build new features and functions. New words are written without content specialist input; new functionality is released without consulting an interaction designer. Anyway, the interaction designer is too busy doing a business analyst’s job (because your organisation does not employ business analysts), trying to develop a process flow that will help the organisation design and build things more efficiently.

You need a process for design and build.

Your current process for design is to call a designer into a meeting. The conversation does not introduce why this work is a high priority, or data that might inform design decisions. Instead, the designer is given a short explanation of the problem with little context (while various non-designers let fly with their own random design ideas), then asked for a design decision on the spot. The meeting is over when the hour is up, well before the designer has run out of questions. Designers aren’t given time to reflect, or to consider how this design decision fits into the bigger picture. Flat sketches are expected to substitute for interaction design and a bottomed-out model of all the if-this-then-that logic behind the thing being built.

This drive-by, whack-a-mole style of solving design problems is then propagated along the line to developers. Developers often appreciate sketches as a basis from which to start, but here, sketches are actually replacing essential discussion. Developers do not come back to designers to ask questions, because they have no idea who the designs they were handed came from, or of the context. They’re just doing the best they can. They can’t change how the organisation functions.

You need to change how the organisation functions.

The organisation’s leadership is afraid to take risks, where ‘taking risks’ means ‘changing things’. Changes that could help the organisation, like shortening feedback loops, empowering cross-functional teams to make decisions, and listening to what users need —such changes are viewed as risky, when in fact all of them would reduce risk to the organisation, making it more agile and responsive to reality. These changes would also reduce costs, including those associated with customer support.

Asking for sketches without these things in place is like trying to build a house by starting with the paint.

Many organisations are not mature enough to deliver good design, even when given the mockups they asked for. Mockups and sketches are often a distraction: it’s so tempting to believe that having something you can look at means you understand the whole. Your scarce resources might be better spent trying to find and collect data, and learning to prioritise. On beginning with depth and substance, not appearance. Building something ugly and basic, but which meets user needs. And in doing so, reducing organisational risk and lowering costs.

You cannot afford to ask for sketches.