I like how Kim Goodwin wrote the guide focusing on achieving a goal. It is usually the thing I’ve been missing out on as I tend to focus too much on details.
By setting out a goal for the iLight project, which was to let starlight be more impressive than city lights, there were a number of changes that were discussed by the team, and the questions we would ask were along the lines of, “Does it let visitors see that effect?”, which is similar to what Goodwin wrote about letting the user accomplish their goals.
Goal oriented design was also useful for communicating to the IEM side. Even though their main concern is to get the lights and sensors to work, telling each other our goals made the recent weeks of discussion much smoother compared to the first few weeks. One way we did it was it act out the situations and potential problems that different visitors have, making it clear on what needs to be solved.
Another thing we learned that was emphasized in the chapter was defining requirements, which is something we are still working on. The importance of narrowing down the needs of the engineering side, the form of the installation, and how it feels will allow us to have a clearer picture of what our installation should be. It is sometimes neglected because we keep delving into details and forgetting the big picture of what’s actually needed. This shortcoming will need more attention as we need to present to iLight staff our proposal, as they would like to have their needs to be taken into account.