What I do

At the beginning of our engineering design course, the professors gave their process of design.

Before learning structured engineering design, my workflow is similar to the professor's description, but with different weighting.

The main projects that I designed prior to taking the design course were programming projects: the two most popular ones were PocketInvEditor and BlockLauncher, two applications for Android. I had adopted the following workflow for app development:

  1. Identify the problem
  2. Examine reference designs
  3. Think of potential solutions'
  4. Identify feasible solutions
  5. Produce a model (often, this would be a prototype of the software)
  6. Evaluation of solution based on model (if inadequate, go to 4 and choose a different solution)
  7. Improve solution by identifying subproblems or related problems and recursively running this workflow from step 1
  8. Results in improved production-ready prototype

Steps 1-3, 5, and 7 corresponds to the "Jump forward" stage of design, step 4 and 6, the reflection stages, corresponds to the "step back" phase, and modeling in the form of prototyping is heavily used throughout steps 5 to 8.

After a term of learning in a engineering design course, my core workflow for design remains the same, but I observed that, in the course, I place greater emphasis on different stages of the workflow.

For app development, I placed emphasis on examination of reference designs and the production of prototypes - the "Jump in" and the "model" phases. With an application, a single idea can be prototyped with some difficulty, but improvement to the solution - step 7 - is relatively easy, and can lead to a production ready prototype. Furthermore, often the scope of an application can be quite narrow (for example, a recent application I worked on involves splitting a picture into 16x16 squares), which means that the number of possible ideas is low. To save time in app development, once I got one feasible solution, I often try to immediately produce a prototype for it without considering other solutions, so I could start on step 7 quickly. In the design course, I've learned to place greater weight on the idea generation (step 2) of the workflow, as multiple ideas could be tested within a group environment, while only one idea can be prototyped by myself developing alone. Additionally, the design assignments in the design course are broad in scope: in our conceptual design, for example, we were given the broad problem of reducing splashing, and we had to narrow down our scope, as well as coming up with diverse solitions.

Another change my design process underwent is the addition of emphasis on the "Step back" stage. Previously, I saw "stepping back" - re-evaluation and possible modification of ideas - as a panic action one does when one is stuck or when one encounters failure. Indeed, when I developed BlockLauncher only to find that my intended solution did not work, I was discouraged, and only started looking at alternative solutions after a month of recovery. However, when working in a group, I find that the group feedback is very helpful during the re-evaluation stage, so "stepping back" becomes more effective: solutions that do not pass step 4 or 6, after improvements based on group feedback, often returns in a better form. Frequent comments by teammates also remove the stigma that links re-evaluation to a lack of success: stepping back becomes a way of design. Much of this was realized during our conceptual design project.

I'm still watching my own behaviour to understand the results of these changes to my design process. The aforementioned picture slicer app had a narrow scope, so I followed my old path, but I expect to use some of the new strategies I learned when developing more complex projects.

I've written an article that further analyses my programming background's influence on my design approach.