So one time, I showed a friend a Web site for a project I was working on. And he asked an interesting question:

Well, you’re design guy right? Shouldn’t you be writing a design document?

And what I suddenly realized was unclear was that the Web site was a design document. It was just a design document of a very different sort. It was basically a step one design document, serving as a way to put the ideas in a concrete form for discussion. The team kinda knew what the product should do, but not every last detail yet. Some team members were ready to jump in and start coding right away, and just call it Agile Development if we needed to justify the work. Instead we said, “Wait a minute. We have a vision, but no details. If we don’t explore what some of the users will demand from the system, we won’t design the architecture to accommodate them properly. So before we can write a line of code, we need to explore what a range of users need. Then we can design an extensible architecture that should support most of those needs. And then we can jump in and start coding.” So the Web site was, in part, a format for exploring what different sorts of users would want, by telling stories of how they would use the system. And since the system was intended to be marketed to users who could use those same stories as a way to envision using the system themselves, it made sense to document those stories in a marketing-oriented Web site. But marketing-oriented or not, the Web site still served a purpose as a design document.
Now my friend would never be so rigid and unimaginative as to say that the Web site wasn’t a design document; but I have met people who are so wedded to hidebound procedures that they would have argued exactly that, just because it didn’t conform to some formally defined design document template or fit into some formally defined design methodology. And that reminded me of Kipling:

“There are nine and sixty ways of constructing tribal lays,
“And-every-single-one-of-them-is-right!”

Design is a heuristic problem, meaning that there are techniques that can lead to a solution, but no single guaranteed and inviolable path to a solution. Quoting from Wikipedia:

In computer science, a heuristic is a technique designed to solve a problem that ignores whether the solution can be proven to be correct, but which usually produces a good solution or solves a simpler problem that contains or intersects with the solution of the more complex problem.

Note the word “usually” in that description. Some heuristics are better than others, but none can be proven to be right, especially not in the general case.
There are many ways to design, because design is really just a means of communicating and refining your ideas. Different people communicate better in different fashions. Some people are more visual, and some or more verbal. Some are more instinctive, and some are more methodical. Some are more detailed, and some have a broader view. And so there’s no one right way to communicate a design to other team members and stakeholders. The only “right” approach is multiple approaches, to ensure that you cover the same material in different ways to gain different perspectives.
As an example, some people love written design docs, and just can’t see any benefit in design diagrams. Others believe in making excruciatingly detailed UML diagrams, and sometimes see those as “complete” designs. Now I’m pretty fanatical about using UML for my designs; but when I teach UML, I always point out that neither text nor pictures is sufficient. You need both. Different people and different teams will emphasize one over the other, but you need both.
That doesn’t mean that there aren’t better ways and worse ways to design. I would never consider a marketing-oriented Web site to be a complete design, just a step in building the design. But when we built that Web site, we were definitely participating in a design effort. Because…

“There are nine and sixty ways of constructing tribal lays,
“And-every-single-one-of-them-is-right!”