Some people might argue that design isn't really a construction activity, but on small projects, many activities are thought of as construction, often including design.

Design
Design
Design Challenges
The phrase "software design" means the conception, invention, or contrivance of a scheme for turning a specification for computer software into operational software.

Starting from "good software requirements" and transforming them or turning them into "acceptable specification for computer software" requires a lot of office-politics, skill, patience and time.

Design is the activity that links requirements to coding and debugging. A good top-level design provides a structure that can safely contain multiple lower-level designs. Good design is useful on small projects and indispensable on large projects.

On some larger projects, a formal architecture might address only the system-level issues and much design work might intentionally be left for construction. On other large projects, the design might be intended to be detailed enough for coding to be fairly mechanical, but design is rarely that complete the programmer usually designs part of the program, officially or otherwise.
On small, informal projects, a lot of design is done while the programmer sits at the keyboard. "Design" might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it's done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it.
Design Is a Sloppy Process (Even If it Produces a Tidy Result)
The finished software design should look well organized and clean, but the process used to develop the design isn't nearly as tidy as the end result.
Design is sloppy because you take many false steps and go down many blind alleys you make a lot of mistakes. Indeed, making mistakes is the point of design it's cheaper to make mistakes and correct designs than it would be to make the same mistakes, recognize them after coding, and have to correct full-blown code. Design is sloppy because a good solution is often only subtly different from a poor one.
Design is also sloppy because it's hard to know when your design is "good enough." How much detail is enough? How much design should be done with a formal design notation, and how much should be left to be done at the keyboard? When are you done? Since design is open-ended, the most common answer to that question is "When you're out of time."
Design Is About Tradeoffs and Priorities
In an ideal world, every system could run instantly, consume zero storage space, use zero network bandwidth, never contain any errors, and cost nothing to build. In the real world, a key part of the designer's job is to weigh competing design characteristics and strike a balance among those characteristics. If a fast response rate is more important than minimizing development time, a designer will choose one design. If minimizing development time is more important, a good designer will craft a different design.
Design Involves Restrictions
The point of design is partly to create possibilities and partly to restrict possibilities. If people had infinite time, resources, and space to build physical structures, you would see incredible sprawling buildings with one room for each shoe and hundreds of rooms. This is how software can turn out without deliberately imposed restrictions. The constraints of limited resources for constructing buildings force simplifications of the solution that ultimately improve the solution.
The goal in software design is the same.
Design Is Nondeterministic
If you send three people away to design the same program, they can easily return with three vastly different designs, each of which could be perfectly acceptable. There might be more than one way to skin a cat, but there are usually dozens of ways to design a computer program.
Design Is a Heuristic Process
Because design is nondeterministic, design techniques tend to be heuristics "rules of thumb" or "things to try that sometimes work" rather than repeatable processes that are guaranteed to produce predictable results. Design involves trial and error. A design tool or technique that worked well on one job or on one aspect of a job might not work as well on the next project. No tool is right for everything.
Design Is Emergent
A tidy way of summarizing these attributes of design is to say that design is "emergent." Designs don't spring fully formed directly from someone's brain. They evolve and improve through design reviews, informal discussions, experience writing the code itself, and experience revising the code.
Have you prototyped risky or unfamiliar parts of the system, creating the absolute minimum amount of throwaway code needed to answer specific questions?

Divide and Conquer
As Edsger Dijkstra pointed out, no one's skull is big enough to contain all the details of a complex program, and that applies just as well to design. Divide the program into different areas of concern, and then tackle each of those areas individually. If you run into a dead end in one of the areas, iterate!
Incremental refinement is a powerful tool for managing complexity. As Polya recommended in mathematical problem solving, understand the problem, devise a plan, carry out the plan, and then look back to see how you did (Polya 1957).
Design is an iterative process. You don't usually go from point A only to point B; you go from point A to point B and back to point A.
Virtually all systems undergo some degree of design changes during their initial development, and then they typically change to a greater extent as they're extended into later versions. The degree to which change is beneficial or acceptable depends on the nature of the software being built.