humantypo

I have been doing a lot of thinking on the requirements side of software development lately and found an interesting memelet presented by Malcom Gladwell on TED that describes a paradigm shift in customer identification with physical products (in the tomato sauce space no less). The fallacy of the “median consumer” is explained in a way that is very similar to another paradigm I have serendipitously unearthed, personas, presented in Alan Cooper’s book,  About Face, on interface design. It is not a new concept, but it is one that appears to largely be ignored in most software development projects to this day and [I now believe] is a key reason for a much of the dissatisfaction with binary product across the software spectrum.

The coincidence of coming across these two perspectives whilst independently pondering this topic is less epiphany and more a slap to the forehead since it seems like something that I have always known, but never realized. Nevertheless, coincidence being the seed of awareness I take this intersection of information as validation of my desire to learn more as I believe that it represents a key improvement in the approach to developing better software.

The idea of gathering the input of “representative users” and trying to build a single User Experience from that corpora simply doesn’t make sense to me any more. 

Once my mind embraced this concept it set to work creating all sorts of troublesome ramifications. Traditionally—if there is such a thing in iterative development—iterations require the participation of the user early and often. Forgetting for a second the increase of resource demands on the development team, the introduction of multiple logical users interacting with the system takes the developer/user interaction model to a new level as it would seem to quickly introduce a need for a high degree of coordination between what might be competing inputs.

Perhaps one possible way to address this would be to develop a “meta architecture” that itself may be iterated (albeit with much pain). Such a design would focus on the means by which each user profile would be served by looking at the architectural characteristics of the requirements (as derived independently), not the features themselves.  As Cooper points out, it is not as simple as looking at feature anomalies; it requires complete evaluation of the overall way in which the system is interacted upon by each persona.  

Following this train of thought…if the differences are based upon divergent user expertise interacting with the same basic information techniques such as “toggling” features or “modes” might be the proper approach to accomodating both sets of needs. If on the other hand the demands on the system vary widely it may mean that independent interfaces are developed from the beginning and there is increased focus on abstraction between the UI and the back end (often talked about, even more often “whiteboxed”).  Again, architectural decisions at this level do not lend themselves to the same ease of iteration as the pursuit of a single mindset implies so there is much to be said for an increased level of “surveying” to occur before building.

At this point I have more questions than answers but the feeling of rightness this concept brings has piqued my interest greatly; I feel a shift in my philosophical approach to software development. It is fertile ground for exploration, one that I will be spending significant time contemplating more fully in the coming weeks.