The Emergence of Meaning Through System Use: The central role of interaction and its implications in terms of design methodology

I have tried to show in previous posts how certain aspects of an interactive system such as how it works, what it does, or what it represents, could be seen as emerging in the framework of its actual use. Furthermore, I have tried to provide a theoretical grounding to such an approach by borrowing from social theory and more precisely certain forms of discourse analysis. I would like to continue to unpack this notion and see what impact it could have in terms of development methodology, and how we could use such a standpoint to evaluate the several software development methodologies currently available to interactive systems designers and developers (if such a distinction holds water).

The evolution of the software development field and the apparition of disciplines such as interaction design seem to suggest an shift in the conceptualisation of interactive systems from a set of inert processes taking place within the ‘black box’ of a computer to dynamic interactions sometimes involving several users as well as numerous other systems or services.

Thus, what we could ask ourselves is: what would be the impact of such a focus on the emergent nature of interactions on software development methodology? As one could argue, the apparition of agile development methods seem to be an encouraging sign of an (unconscious?) acknowledgement of the importance of considering interactive systems as sets of interactions. This evolution can not only be seen in terms of methodology, but also in the actual development tools now used in web development projects. In a few word, we could thus argue that the problem with linear, first generation software development methodologies was primarily the fact that they viewed software as an inert technical entity and not as a particular type of discourse embodying the practice of its users.

User-centered development approaches, which try and elicit a conceptual model of the system being built by communicating with its stakeholder seems therefore to make sense. The idea of building a model of the system first and building it once it is considered as complete (sometimes called the Big Design Up Front approach) seem to show its weaknesses if we start considering system meaning as emergent in the framework of user interaction. Indeed, it appears crucial to be able to observe what sorts of new meanings emerge from their interaction with the system being built: prototyping becomes a central problem, and iterative development the only sensible solution.

We could even push this notion forward by arguing that an outside-in approach, focussing first on the type of interfaces that will be provided to users (and therefore which objects will be presented to them by the system) seem to make the most sense if one is to adopt this approach. Simple, static interface prototypes can be provided to test users and refined independently of the more work-intensive business logic required to perform the actual operations that users which to perform on the objects represented by the system. Interaction with the systems entails the generation of new concepts, new processes and new practice.

These new practices are built upon and integrated as the system gets developed: the system is developed on the basis of the users’ practice, but influences it in a constant feedback loop until a certain point of equilibrium is achieved where user practice and the tools provided by the system complete each other in an optimal fashion. We could thus use this idea as a way to criticise approaches such as Behaviour Driven Development, which focus on coming up with sets of stories representing the behaviour required of the system on the basis of sessions with potential users of the system (in an ideal world). Considering the constant feedback loop between user practice and system features presented above, it seems uncertain that such stories can provide a fixed point of reference for evaluating the system’s fitness for purpose.

I have clumsily and very roughly tried to provide a theoretical grounding upon which development methodologies and tools can be appraised based on social theory literature. My aim is to reconcile disciplines such as interaction design and software development methodologies such as agile, and more particularly feature driven development, test-driven and behaviour-driven development. I think that although these have a lot of qualities in providing a solution to particular software development problems, it may be possible to create an integrated methodology taking the best of these approaches to provide a coherent software development framework. I would also like to add that such an approach would not be intended to provide an answer to the development of any software system: my main focus and area of expertise is web-based or mobile enterprise applications. I will try to give more flesh to this approach in future posts, and welcome comments in the meanwhile!

Related posts:

1. The evolution of the developer’s role: Let’s put all our eggs in the same basket
2. Social science for software developers – Using tools from social science to inform software design: should software developers also be social scientists?
3. Interface Design and Information Architecture for Enterprise Web Applications: Four Simple Principles
4. Applying Conversation Analysis Concepts to Interaction Design?
5. Software as Discourse