Looking Back Towards the Software Design Course from a Designer's Perspective
Hi, I am Jin, one of the few graduate students in the class. I come from Course 4 and have been studying computer science in recent years. Besides architecture, I have experience in product design and management.
I chose this course for a couple of reasons. On one hand, I want to create some innovative tools that enable designers to unleash their creativity. On the other hand, the project I have been working on, WeeHive (a beekeeping platform), needs a great social platform as one of its killer features.
After taking several programming-heavy courses, I'm able to write code snippets but have always struggled to think systematically about larger software projects, especially regarding how to translate our ideas into software language. Thinking about one or two ideas is easy, but implementing a robust peripheral support system to get the program up and running is difficult. This course teaches how to think about the skills of building full-stack software, which is very practical and interesting. Of course, not everyone needs to manage databases with hundreds of millions of records, nor do all applications need millisecond-level high performance. Often, a specific group of people has specific needs that mainstream tools cannot meet, and these niche areas require clever solutions and can bring immense value. The first half of this course lets us play the role of an independent developer to discover and solve these kinds of problems.
After the first phase of the course, I want to write a series of short articles to reflect on and compare what this course has brought to me and how it integrates with my backgrounds.
Chapter 1: User Research
In the fields of architecture and planning, we have always been taught that the users - the citizens -are the most important. However, almost all urban policies in history were not based on the most basic wishes of citizens, but on some kind of tacit conumdrum between politics, capital, and reality limitations. Most citizens passively accept the changes brought about by the surrounding environment, especially in rapidly developing regions such as China, India, the Middle East, and Southeast Asia. What's more, many people don't even know that change is possible. For designers, requirements are often written documents specified by the government and developers, and a large portion of such documents follow the decisions of historical documents. The city's hundreds of thousands of years of construction history means that any change requires a lot of compromises and time. Are users really the most important thing in this situation? I doubt it. The real user is actually the government, and designers are responsible for decision-makers, rather than the end users—citizens. Even in the most democratic regions, there is a politics of space. This institutionally determines the limitations of participatory design, because it is a restriction brought by the decision-making mechanism.
However, in the software industry and technology, the way of thinking is completely different. People use actions - installation, and usage to vote. This brings a highly competitive market. Almost every need is covered by more than a dozen apps. It is essentially difficult for new software to gain a foothold. To succeed, software must excel — be elegant, simple to use, functional, and meet the core requirements of the target audiences. Thankfully, the modification of the software itself is almost real-time. Under the agile development method, the add and drop of functions can be calculated on an hourly basis. This advantage enables the possibility of participatory software development. Listening to user feedback does not only occur in the process of initial research, but more importantly, it occurs in the infinite update iterations after the software is designed.
Which way is better? One is highly realistic and material, influenced by politics and government, but once built, it will have continuous influence for more than fifty years; the other requires rapid iteration, tremendous hard work to stand out, and taking risks. The software may be replaced in a few months, but it is possible to have an impact on hundreds of millions of people once successful.
Concept Design: Think beyond A Pattern Language
"A Pattern Language" is a must-read for every architecture undergraduate. Although this book is a very famous read in the field of architecture, it is not used as the bible for real-world architectural practices outside of academia. Why? Because buildings are physical, they (nearly) never update, yet the demand for customization is very strong. Moreover, even if we could summarize every element of all architecture ever designed into a dictionary, these human needs are endless, diverse, and richer than we can imagine. In any corner of a less formally developed area, we can find creative applications for space.
In contrast, its concepts have become a compass for the software industry. Formal language is very suitable for software, a discipline that allows for replication and mass modular development. In class, we also learned about the concept: just like the modular blocks that are used for building up the skeleton of the core software.
The application of 'concept' in software development has led me to add a new link in the traditional product design logic chain. Initially, it was: User Research-Need Finding-Function Development. Now it is User Research-Need Finding-Concept Design-Function Development. Concepts allow us to integrate a series of complex but intrinsically linked functions into modules that are evident. What's more, concepts can be easily translated into programming languages, like classes. In designing concepts, we are actually writing pseudocode. The concepts provide us an excellent way of finding a balance point between making it understandable for both computers and humans.
Chapter Three: Technical Implementation - The Virtual “Reality” and the Virtual “Virtual”
In many fields like art and architecture, designers work with physical objects or create digital twins of physical objects to better create their physical counterparts. Physical design requires logic, such as room layout, functionality, and people movement.
On the other hand, software is virtual. We may understand it as electrons flowing through chips, but essentially, it is a combination of a series of logics and is intangible.
Physical objects can't be easily altered. Sometimes it's easy to add but hard to remove, like a pillar; sometimes it's easy to remove but hard to add, like expanding the room on a tiny land. These constraints sometimes shape wonderful designs, like the feather-shaped tallest residential building 111 West 57th Street next to Central Park in New York, which makes a slender luxury apartment on a narrow land. However, these constraints can also become the final regret of a project that could have been spectacular.
In the virtual world, especially when storage, internet bandwidth, and processor speed are nearly limitless (for our small programs), adding and subtracting are no longer constraints, but ideas are! These ideas can be big: creating a collaborative, all-purpose online design platform, or small, like making a tool to coordinate meeting times. Regardless, the physical world is no longer a specific constraint. The virtual world gives each of us infinite possibilities. For every student learning to code, perhaps you haven't realized it, but compared to engineers, you should feel fortunate and grateful. Programming endows you with the ability to be a creator in this virtual world.
Chapter Four: Product Management
I have led a small rural public building project from 0 to one, involving multiple stakeholders. I also interned under project managers in large engineering companies. In the tech industry, I have worked not only as a developer but also involved in the development and maintenance of software products as a product manager. Software engineering is indeed "engineering." We always confront the challenges of deadlines, the risks of unforeseen challenges, and budget constraints. However, the flexibility of software grants us the possibility of agile development. Agile project management through Jira in Scrum teams has become a widespread practice. Conversely, I am contemplating the feasibility of introducing agile development into architectural engineering teams. Perhaps one day, we could update a module in a smart home via OTA updates, or perform a hot fix on a congested corner in a smart city, who knows?
I am thrilled to be able to work on the Final Project with three exceptionally talented and nice juniors. They consistently reminded me of the principle of "less is more," correcting my sometimes overly elaborate but unnecessary proposals. This reminds me of "The Mythical Man-Month," where large teams inevitably lead to significant communication costs. In smaller teams, task division is much easier and more efficient.
The above is a brief reflection on my journey of course 6.1040. As my teachers at the architecture school always reminded me, despite the endless nature of technology, my starting point remains as a designer, and I should embrace this identity. In my world, technology serves needs. Whether you identify yourself as a computer scientist or a designer, finding these needs and creating impact is always the core.