Login
Software is complicated. Adding people makes it complex. The distinction is that in a complicated system, outcomes are usually predictable due to controlled environments and fixed variables.
For example:
- If this condition is met, do that; otherwise, do this.
Such systems can ignore, or be immune to, unexpected events because they aren't materially affected when certain scenarios aren't explicitly accounted for.
In a complex system, however, due to increased variability in interactions, outcomes from the same trigger may vary greatly, be more impactful, and require unique accommodations. Introducing users to software systems brings in their motivations, assumptions, hardware, preferences, learned behaviours, and many other factors, driving up complexity.
The variability of user interaction increases the cases to consider, more like:
- If this condition is met, do that;
- but if this happens, do this;
- or if this and this happen, instead do this;
- otherwise, do this.
Anyone involved in creating software-based experiences can provide examples to further illustrate the difference.
By choice or necessity, designers tend to focus almost exclusively on factors that drive complexity related to the intended user experience. This has had a detrimental effect on some designers’ professional development. While focusing on target user outcomes is essential, it shouldn't come at the expense of technical literacy around software systems.
Over nearly 20 years—spanning Web 1, 2, and 3—I have observed a growing divide between the knowledge required to design good software product experiences, and that required to program good software.
Designers, for example, may take for granted that non-functional requirements—such as cybersecurity, performance, or accessibility—are automatically baked into programming practices, and a merely complications. In reality, these qualities are also complex, and require effort on everyone's part to consider adequately.
Don't learn code, learn software
The sheer complexity in software products can be overwhelming, and the rise of surface-level, boot-camp approaches to education have sparked debates about whether it is necessary for designers to, “learn to code”. Resistance to deepening one’s understanding of technology may even grow with the advent of generative artificial intelligence.
The question, “should designers learn to code?” Has puzzled me as much as it has troubled me. I can't understand not wanting to learn more about the landscape one ultimately designs in—the constraints, and the opportunities. Perhaps, “learning to code” is the wrong framing; instead, we should be discussing “learning software.”
Personally, a basic interest in computer programs played an integral role in my desire to design interfaces. During my design studies (back in the day), I was introduced to emerging digital media and web technologies, which led to early career opportunities to stand out. I was able, for instance, to take on tasks that involved creating or managing web content, including Flash interactive media and animations which skirted the design/dev line at the time.
Programming may not interest everyone, and designers certainly have no shortage of other important skills to master. Still, professional growth and opportunities in a competitive market are reason enough to gain at least some foundational understanding of software’s building blocks. Web3, for example, is an emerging area ripe for designers to play a larger role. In my article Designing experiences for the third web, I describe how working on Web3 solutions requires a fundamental understanding of cryptography, distributed ledger technology, and self-custody.
To build an understanding of Web2 software—where I’ve worked for most of my career—I have relied heavily on personal projects to build knowledge and stay up to date. This website, Spowtr, is one example.
Building a blogging platform
Since 2012, I've been developing this platform, with two specific goals in mind. Firstly, being unsatisfied with the blogging options available at the time, I wanted a place to write articles that aligned with my sensibilities. Secondly, I wanted to explore more advanced web development concepts beyond what I'd mastered in creating static HTML/CSS websites, such as my portfolio.
Despite the countless hours I’ve dedicated to Spowtr over the years, I wouldn’t consider myself a “programmer.” This hands-on experience, however, has helped me gain a tangible—if basic—understanding of:
- Domains and web hosting
- SSH/SSL, and digital certificates
- Web server software
- Databases, database design and querying data
- Server-side code
- Client-side code
- Browser rendering
- Code commenting
- Server-side session vs client-side token based authentication and authorisation
- SMTP setup and email deliverability
- Optimisation, performance, and security
- Progressive web apps vs. native apps
- W3C accessibility standards
These are just a few of the foundational concepts that form the “web” we design within.
Acquiring this knowledge has not interfered with, but rather complemented, my design skills, enhancing my work in areas such as:
- Systems thinking and abstraction
- Creating working prototypes
- Building animations
- Considering semantics
- Integrated systems
- Adopting new technologies
- Remaining platform agnostic
Not to mention communicating with software developers. A major contributor to poor usability is interface design that directly mirror back-end logic. Understanding how systems actually work helps advocate for user experiences that effectively translate between software development needs, and effective human interaction requirements.
Beyond the technical
Aside from learning practical skills, building Spowtr has also affected my product thinking. I’ve reconsidered, for example, constant feature-adding, managing ideas, and principled design decision-making. I go into depth about this topic and how it relates to Spowtr in Deleting comments, how purpose helps strip back product.
In terms of workflow, I'm proud that Spowtr is a digital Ship of Theseus: it has evolved to the point where perhaps not a single line of code remains from 12 years ago, yet I have never started over. I’ve found this approach is uncommon in commercial software where—despite all the talk of Agile—many technology companies opt for revolution over evolution when it comes to software development.
It's actually a trip down memory lane to review Spowtr’s progression since 2012. Thanks to the Wayback Machine, I can see that in 2013, article layouts were very busy, inspired by news sites and filled with features like comments and links to other articles.
Spowtr article page layout (2013)
By 2019, they adopted a more focused, reader-friendly layout and adopted web-fonts.
Spowtr article page layout (2016)
Today, that idea has been refined further, with features such as text-to-speech added, along with bespoke cover colouring thanks to new front-end technologies.
Spowtr article page layout (2024)
The changes in experience design have been a combination of technology improvements, trends, personal taste, increased focus on accessibility, and direct (or indirect) user feedback.
Beyond the reading experience, changes over the years have included enhancements to authoring tools, code restructuring, performance, stability, scalability, data organisation, and security.
Final thoughts
To build, or not to build? That remains the question. Why have I put up with the frustration of a missing semicolon causing sleepless nights? I continue to develop Spowtr twelve years on because it remains satisfying—and, most of all, fun!
0 Responses
