Not that kind of “process."
I see Software Development as beginning from two critical terminal points and converging in the middle across the mottled terrain of compromise. The two critical terminal points are:
- User Experience
Not all software is well grounded. By well grounded I mean that the software has a clear purpose and expectation. Without being well grounded, it is difficult to define the terminal points, but, not impossible to arrive at a satisfactory conclusion. My perspective is drawn from developing well grounded software.
Why is data first? How could I consider data to be more important than user experience? Does the order of my tiny list even have meaning? In reverse order: yes, easily, and because, the purpose of a tool is more important than the ease or joy of using it except when the purpose of the tool is the ease or joy of using it.
Computers would not exist if they did not serve purposes held in esteem far greater than the ease of their use as evidenced by smashing successes such as UNIVAC and every mainframe ever created. Software is just a smaller section of the overall computing fractal. Data represents the purpose of a computer, even if you must consider it abstractly. Input from a user is data. Output from a program is data. Whether this is a voice from a human responded to by synthesis, or keyed text responded to by errors about its format, the interaction with a program is data and it is well defined.
It is an essential requirement to define the data in order to define expectations about the processing of the data. Definitions can seem very loose, but, actually be very specific. For example, in audio processing, one may be tempted to consider a voice as extremely loose. But, the voice isn’t the data. The voice is a signature of meaning held within the data. The data is the audio signal, and it is quite easy from the perspective of the machine to define it in mathematical terms.
So there you have it. You can’t even begin to set realistic expectations or even idealistic goals for the User Experience terminal point if you don’t know what the tool is meant to do. That is why Data comes first.
That isn’t to say that Data is ultimately dictatorial. In the end, a user must be served by the tool. If a user is not served due to incorrect data design and expectations, then the data design must change. However, in the process of invention it is almost always easier to define the data before the user experience. In future iterations, the opposite becomes true. For this reason, the definition of terminal point two can be considered a very early second iteration of the tool’s design.
It is incredibly common to see arguments about form following function or the opposite. It is less easy for people to understand that they are integral in the final result, because, it is difficult to imagine them as integral during the invention process. That’s because they are not integral at this phase. Refinement during development, or the path one decides to take across the aforementioned mottled terrain of compromise, is responsible for merging the optimum combination of form and function.
The user’s experience of using the tool is critical to the design. There is no point in producing a tool that a user can not use just as there is no point in producing a tool that does not succeed at its goal. With fortune, then, we realize that we can adjust the goal to accommodate user experience. So long as we do not lose perspective and move it too far, this is the way that user experience drives development primarily. Data can be redefined over time based on the changes in the goal that are driven by necessary compromises in user experience. When a developer truly shines is when they are able to solve these conflicts by inventiveness of engineering instead of acceptance of compromise. But, let’s be realistic: that approach is often revealed as foolish and far too commonly leads to a worse overall result.
Two Terminal Points
I define the data that the tool will accept. I define the data that the tool must maintain and understand. I define the data the tool must produce. I define the reasoning about the data so that a foundation for the goals of the tool can be laid atop of it. From there we gain a great understanding of what the tool truly is. From there, we can begin to understand the ideal ways in which the user will engage the tool and leverage its benefits. And from there, we can begin the process of refining the tool’s design to meet the best compromise of user experience and functionality where the goal is to compromise on neither, but, the understanding is that a good tool with a good user experience is ultimately better than a bad tool with a great user experience or a great tool with a bad user experience.
That said, across many scenarios, people will often be happier to accept a great tool with a bad user experience if the purpose it serves is important enough to them. This is fairly important to remember particularly when designing software that accepts complex or critical responsibilities for its users.
Today I will begin the process of defining the first point for a new personal project that I have been dreaming about for some time. Within this phase of the process, I will experience a great degree of introspection and face hard decisions about the realities of the goals I prematurely set for the project. However, in strictly defining the data for the tool, I will come to far more concrete terms about what is feasible. In the end, I will be far more satisfied as I will have set achievable goals and have something far more recognizable as a path to follow during the subsequent phases of development.
Wish me luck. I hope to write more about this project in the future.