In terms of technical product development, design could mean a few things. We aren't worrying about that now. Instead, we will focus on design as in the pre-production phase of a well-structured development effort. Okay... so what does that mean exactly?
When a project to create some technical product (web site, application, game, etc) is thought up, it cannot just be created (or at least shouldn't be). There needs to be a time where you ask questions and find the answers. That is essentially what design is all about.
A lot of people fail to see the point of using time "designing" that could be used actually developing the product; but even in the smallest projects with no design effort, you will typically find a large list of "poor decisions" made through its production time. Design gives a person, or a team, a chance to think about exactly what will be done to make the product a success and, more importantly, meet the requirements and needs. The idea is pretty indepth and should viewed in layers. On the top most layer, you would define the overall goal. So for example, say we have a army of robots and we want to take over the world but can't seem to keep track of all the busy robots' personal ajendas. We need a planner of sorts; something that could run on our mobile devices would be great.
Here our goal is pretty simple and easy to define - create a mobile application that keeps track of all our robots. From here we can begin questioning the means of making this possible. What sort of features do we want or need? Track info on each robot; integrate with Google maps to show us where each robot is; remote shutdown of a robot; and so on. Once we figure out the list of required features, we can further analyze each; figuring out how each can be answered. Documentation during this process is key. Developers should be able to access design documents freely to confirm what they are doing is true to the vision or plan. It is not only a good way to judge when the project is going astray, but it is also a good way to plan and address new features that may come up. If something is being developed that was not designed or planned for, that effort could be completely wasted. It is in these "dead ends" that a lot of poor, quick decisions are made.
As a developer, I can say personally that it is easy add a few minor things without documenting them thinking it won't be a problem - "I can document it later (but will I?)". It is best to address a project's needs formally and generate the appropriate documentation before you do the work. It can also help with identifying potential problem areas in the coding process. One of our example features involved integrating with Google maps. Do our developers know how to do this? If not, figure it out. You don't want to be 6 months into a project and find one of the selling points is literally impossible to complete... that's not only going to result in wasted time, but very likely wasted money when the client rejects the product and refuses to pay. In the case of highly technical questions like this, the design documentation could even hold pseudo code clearly showing how something is to be done. Pseudo code is english readable text that is formatted like logical code. This makes implementing the "coded" process easier and doesn't create any dependancy on any one technology or programming language. Imagine developing half the application in one direction only to find you cannot complete it that way, but rather another completely different direction. This means you have to cut features or deliver an incomplete product; or you have to rewrite everything in the other direction. Designing a product can eliminate, or at least greatly lessen the likliness of that happening - which ultimately saves you time and money.
Design is also commonly misunderstood. It is often times seen as a formality or for those lacking experience or knowledge. That is incredibly inaccurate; any project can benefit from a solid design effort. It has nothing to do with skill or experience, but rather project planning and even estimation. It is also not commonly understood how in depth design is to be. Ideally no rock should be left unturned, assuming the rock is in your path to success. The importantly thing is identifying the "rock" and being aware of it and ready to handle it when needed. Most projects will have some process that gets labeled as design; but understand that a real design effort is not an afternoon in an office with 1 or 2 of the 6 core team members making the key decisions. In fact, even a week of dedicated time to the task could barely be consider a real effort. On average, a properly executed, well-structured project tends to need 20% to 25% of its entire timeline to design it. The entire core team should also be included in the process and, if there is a client involved, or some end user, they need to have a hand in the design as well. If for nothing else, at least to answer user focused questions. You can design a beautiful house, but if the client needed/wanted/expected a garage... you missed the mark.
Design is a huge topic that we will be posting about often. Look for more details on this stuff in the future if you are interested. Share your thoughts below and thanks for reading!