“There’s nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.” — Bach
This is how Bach described playing the piano. The simple execution of functions — such as notes, chords, rests — one after another. That’s all that’s needed to make music….
Upon hearing music though, it’s not so simple…
I’ve written previously (link here) about the challenges that 1st year UX Design students have. Often, their thinking about a problem is framed only in terms functionality. They see digital design as the assembly of features on a screen. When you consider their experience of using software, this makes sense. Many are used to the components and mechanisms that they’ve encountered through a multitude of digital experiences, from self check-out services at their supermarket, to browsing Netflix on their smart TV, to booking flights and accommodation on a travel site. So it’s not hard to see that when asked to make something from scratch, they lean on their previous digital experience by assembling previously encountered functionality.
It’s not just students though. I’ve seen a lot of organisations adopt a similar mindset when building software. A mindset, not only influenced by the digital experience of their people, but the organisational knowledge that’s been built up around how they design and build software. Reflected in how they go about doing the work (teams, people, structure and pipelines), it’s often just about assembling functionality, with the pervading mindset that once you’ve assembled all the features, then you’re done.
What I want to talk about is not the process of making software, I want to talk about an aspect of making good software. Specifically, aspects of the design process, that from my experience, support good software. For this I want to describe two aspects I’ve observed in my own work, which (when done well) characterise work that moves beyond just functionality and features but hits the mark in terms of elegantly and efficiently satisfying users needs across multiple levels.
It shows a potential shift, away from generative approaches to deisgn — making things — that align with delivery approaches such as agile, but is closer to design’s emergent qualities and how they manifest in digital product design.
Emergence versus production
In practice, and with any project i have ever worked on, it’s often hard to know what the design solution is before you start. Often, I have a gut instinct now and where I think it might go — and this is often a good starting point. However, the end-result, when I look back is often very different to what I first thought. However, in agile delivery, even one that champions small iterative delivery cycles, you’re often only focusing on building the next incremental change in the product of service. This places a skewed view on the here and now — the next unit delivery of delivery — with very little time to understand a product or services wider vision and context. This is where a drive to deliver something, ends up becoming a feature factory.
The issue here is that to deliver something good, it actually needs time to emerge. This may sound somewhat out of touch and incompatible with the commercial and organisational imperatives behind delivering software, but it’s not.
When doing any kind of interface deisgn work — whether that be prototyping, or screen design, or anything — as a practitioner you need time to work and re-work when you’re working on. You do this to create an opportunity for any latent ideas to emerge. With the ideas emergering from deep understandings about your users, or their context, or other parts of the problem space. Repeated working, re-working and exploration imbues your work with a deep level of sophistication. It not only solves the users problems but it solves it well.
And It’s a process that works are multiple levels.
In interface design, where the thinking process of remodelling and re-thinking about the problem, you’re pruning and shaping the experience into something highly efficient. This is the space where you’re shaping the fine details of the experience, from. the button presses, the readability of the text, the layout grid that forms the foundation the display logic as users move from screen to screen.
A similar thing happens in my practice when I engage in activities like research. By repeatedly Immersing yourself in data, a deep understanding emerges from it. This is why grounded theory is such an important approach to design research. It doesn’t look to impose a coding standard across the data, but seeks to frame the data through an emerging understanding of it. Whereas some approaches to coding help with a classification, what I have found really useful, especially in later making stages, is a deep understanding of the qual data. An understanding that drives innovation through making.
Agile delivery can sit at odds against emergent design practice
This is why one of the biggest challenges I find in agile software delivery is that Digital Design has been subsumed to a Taylorism approach to software production. The driver is to make sure the production line is flowing smoothly so that software developers are always making and releasing working software into users hands.
Optimisation here isn’t focused on delivering good software. The result being is many get good at making software, but they may not be making good software that solves users needs, in ways that delights and drives adoption. They’re also not open to the idea of innovation as the process doesn’t allow for the new and potentially counter-intuitve ideas that may offer up new product categories or services.
Songwriting and emergence
Music seems to provide the most common and easily recognisable examples of the process I am describing. I show this to students, to help them understand that things don’t spring forth, fully formed. It’s also a stellar example of creative partneship, that you can go much futher together than alone.
I’m not a huge U2 fan, but the emergence of the One from a scribbled lyric and a some chords is mesmerising.
“that there was no magic to it, we just had to put the work in a figure out the ideas and hone those ideas down”
Iteration
I touched on this earlier in the post, but I want to point out what a vital mechanism iterationis for the good stuff to emerge. It’s also the hardest to explain to people, because from the outside, it looks like you’re just pushing pixels around. But what is actually happening is the thinking process of repeatedly responding to the problem. It’s a mixture of testing stuff: you ideas for how elements may address the problem, but you’re also looking for the emergence of new, potentially unseen opportunities.
John Kolko made reference to this in his old but excellent article, which did an excellent job in demystify aspects of the design process. Designers engage in a precess of abdutive reasoning, driven by research, we’re often thinking about different aspects of the problem and data about the problem, and then also things which our outside of the direct problem, to come up with something new.
This isn’t a single step process, and repeatedly going over your work, your ideas, whilst simultaneously bringing in new ones, is hard work. For me, it’s the grind of design, a part of the craft aspect of design. Simone Giertz took 3 years for a folding coat hanger to emerge — many prototypes, and much learning. This is research through deisgn.
“When I look at this, it seems obvious now…but it required all of this to get here”
—
The process of creating good software goes beyond simply assembling functionality and features. It requires a deep understanding of user needs and the ability to elegantly and efficiently satisfy those needs. My belief is that good design involves emergent design practices, where ideas and solutions evolve and change over time. This may seem at odds with agile delivery, that can sometimes hinder this process, as it prioritises quick iterations and incremental changes rather than allowing for the emergence of innovative ideas. Agile isn’t bad, but there are deep incompatibilities, that need to be recognised in order for them to be resolved.
