The Creative Process in Software Development

When creating an interactive software application there are many aspects of the goal in its creation which are important in order to be successful. Success, in this respect, means "app does X function with the least amount of effort required from its user". And in this sense "least amount of effort" could be broken down to include "aesthetically pleasing" since using something that makes you happy is less effort than using something which makes you feel awkward; that is, you just use it without thinking about it.

But there seems to be a general impression in software development(especially in web development) that "design comes first, development comes after the design has been approved", and I feel that this kind of thinking hampers productivity, creativity, usability, and consequently profitability (for both clients and contractors).

In my experience it has been much more effective to gradually and continually work on all aspects of the goal for the app from the ground up and to make decisions (in conjunction with clients) as progress is made, making pivots and adjustments to the goal much more organic and less disruptive to the project team as a whole.

I think the main problem stems from the nature of software itself: in each case, designers and developers are creating something that has never been made before. There are no existing guidelines on how to make "an X app" because it hasn't been made before (and if it has been made before, why are we re-inventing the wheel?) As such, there is a necessary process of exploration and discovery, not just of the client's expectations, but of the app itself. What is an x-app? What should it do? How should it behave? What makes it easy to use? How do we even make it do X? What should it be called? Why is X important? Does anyone care about X; especially enough to pay for it? I don't think any final design can be contemplated without answering all these sorts of questions, and many of these questions cannot be answered without first exploring how the app actually does what it does. That is, it needs to be built, at least partially, before you can even know what it is you're dealing with and only then could you possibly define an effective visual language for expressing its functions in shapes and colors and words and sounds. Development needs to happen along-side design and one can't discover all it needs to know without the other.

As an example, I couldn't make the title for this piece of writing without first actually writing a draft because I didn't know, at the beginning, what it was I was going to talk about. If I had started with the title, it might have been called "Why I Hate Designers" but that's not what its about at all: out of a design frustration I had something to say about the process we all use in creating things and how different creators work together to create a bigger whole. It had nothing to do with designers per se, nor any kind of personal feelings. I needed to discover my thoughts only from a very vague and cloudy notion which inspired to start of a journey. Project, in general, are like this: they can't be defined up front; the creative process is a journey; and only after having travelled along a path can a creator know whether that path leads to her goal (or if her goal is even the direction she wants to walk in the first place).

It's the old parallel versus serial thing. Does it scale? I don't know. Maybe the way to do it is to create a small (10 or less person) team tasked with exploration and prototype creation, to push the app as far as possible with limited resources leaving all tasks related to scale for later. Then, once the app is well understood, both in terms of communication and code, the team can be increased and scaled up to handle more straightforward, but time-consuming, scaling problems. Teams bigger than 10 people, from my experience at least, don't seem to speed up creation time; and in fact more likely hamper it.

So what does this look like?

Well, for example, maybe when creating a web app/site, instead of creating a "clickable mockup" in a proprietary program from Adobe (or whoever), why not make an actual website with real, clickable, links? This initial site can necessarily be very simplified, and in fact should cut all the corners necessary to focus mainly on "get something working". Then, as the project developers further changes can be made directly to this initial prototype which can hopefully eventually evolve into the final product itself. Regardless, the things learned in doing some simple coding with some simple design in an excercise of making a "good enough" prototype that the client will understand will uncover huge amounts of necessary information for informing the best practices that will create the best end-goal.

Developers will discover things like "wow, I didn't expect this data visualization graph to be this hard" and designers will discover things like "omg, when you actually click on this link the screen change is very sudden; we should maybe animate a fade-in or something so it's not as jarring". Through this natural process of discovery and iteration the project can eventually be considered "good enough" to show stake holders and engage in a conversation about goals and expectations which can further inform the iterations that follow. In this way, all parties are informed of the project's overall state, its progress, its expectations, and everyone can plan ahead for how to solve the currently known problems. Everyone is also actually talking to each other in order to pull this off, so cross-diciplinary problems are fleshed out earlier and last-minute delays can be avoided. There is also a change of focus from "what it looks like" to "how it works" or "how it feels" which is better for an interactive design and is different from a static print design.

When a painter creates a painting, she might make some initial sketches, maybe some quick gestures and color tests, but most of the work is done on the actual, final, canvas. She might make a loose drawing first, then refine the lines, then apply some dabs of paint and in the process discover how the form interacts with the color and creates an overall composition. And then there is a long and iterative process of refining and touching up and tweaking and maybe even painting-over and redoing until finally, when stepping back from it all, the painter decides that no more can be done that would make it any better, in which case it is considered "done".

Software isn't exactly the same and is never, really, considered "done". But there is a time during initial creation that the app could be considered "done enough" to be put in front of the public and deliver enough value that it should shared. Up until this point, each aspect of the app should be worked on in conjunction with other aspects because it is the whole that is important and this can only be seen, and judged, with all the aspects together beside each other. This is why, I believe, an app should, as quickly as possible, and as loosely as necessary for speed, be made as a prototype first(with everything that involves from visual design to code development to deployment on a real server with a real domain name) and then step back, consider it against the goal, and then go back in and iterate on what needs improvements (some changes cross-affecting other aspects which cascade and need to be considered together). The whole is then built up gradually and in parallel and at any point during the creation process, the client can look at a full working piece of software.

As an individual, a creator likely works on everything all at once all the time until the creation is done. As a team, the same sort of thing is going on for each member of the team, only each member also connects with other members from time to time, in the middle, and exchanges some information and/or connectivity (imagine an individual creating a single jigsaw puzzle piece which is put on the table and connected to other individuals' puzzle pieces to contribute in creating the whole). Now, in reality, work is not so clearly defined as a puzzle piece and overlaps with other people's work too. It is like the way we descibe atoms with neutrons/protones and orbiting electrons when in fact they are less like planets and more like blurry overlapping waves of probabilities. But that's hard to picture in our limited human brains; but keep it in mind and don't treat the analogy too literally ;)