It’s important to grasp how much the development cycle for apps and platforms differs from that of software from a previous era. The typical app will go through a far higher number of iterations than a comparable piece of software would have in a pre-smart phone era. There are numerous reasons for this ranging from changes in the operating system are more frequent through to the unpredictability of bugs in an operating environment encompassing numerous elements which are themselves changing. But the most interesting dimension of this continual iteration is the relationship to users it entails. There is a risk of frustrating the users with too many updates, as each one acted upon inevitably consumes time, resources and data, with the latter potentially being in short supply if the user cannot connect to wifi before undertaking the update. However too few updates implies a lack of responsiveness to the emerging community of users, one which might prove fatal if it eventually leads to App Store reviews being swamped with poor reviews and comments about a failure to update the software. Particularly when it comes to apps which involve a sustained relationship, such as cloud based note taking or productivity software, the accusation that a developer is lax in addressing problems or responding to user demands is liable to prove immensely off-putting. Therefore the app development process involves negotiating a relationship with an emerging community of users, iterating the project in real time in relation to a user game which is itself changing. The user group might be growing or shrinking it size. The average level of familiarity with the app might be increasing as users become committed, or it might be decreasing as a small cluster of sustained users are supplemented by an influx of new users whose engagement is at least heretofore shallow. Users might be growing in commitment as the app becomes part of their daily routines, or their decreasing engagement might be the canary in the coal-mine which marks the entry into the death cycle for a once promising service.
There are many ways in which the user group might be changing at any specific moment in time and this has important implications for the epistemic predicament in which developers find themselves. How do they know what users want? How can they anticipate how users might react? The are two means through which these questions can be answered: the transactional data collected by the app which is available to developers and qualitative engagement with the user group through social media, e-mail or feedback within the app. As we’ve seen, the data collected within the app might appear to be nuanced in terms of the data points which are collected on a specific user but it it also restrictive in that its scope doesn’t extend beyond the app itself.
However if developers are reliant on social media to manage relationships with their user group then they are inevitably subject to precisely the dynamics which we later analyse as the social media machine. If they use Twitter to engage with a user base then certain voices will be more prominent than others. Accounts with many followers, or a high ratio of followers to followed, will have more weight in the feedback they share than those which are less popular. The ephemeral nature of the platform means that feedback will tend to be offered in particular ways, such as being extremely brief and possibly impatient. A Facebook group has its own unpredictable dynamics, liable to attract only committed users but also to encourage them to express their views in certain ways. It might be that e-mail proves an effective means to interact with users, but there’s a higher threshold for engagement than other platforms. It’s easier and quicker to send a tweet to someone you have not spoken to before than it is an e-mail. It also creates the risk that the developer will receive long, possibly rambling e-mails, consuming more time than might otherwise be needed to discern what the take away message of the interaction should be. It’s not that one platform is intrinsically better than others for these purposes but rather that each involves a mixture of affordances and constraints, inflecting the relationship that its being built through the particular characteristics of the platform being used to build it.
If we recognise these as two dimensions through which a platform firm builds a relationship with a community of users, it opens up the possible tensions that might exist between them. What if users in a Facebook group are telling you things about the platform which aren’t borne out by the data? What weight should be placed on individual experiences conveyed by e-mail compared to the aggregate trends which can discerned from monitoring user activity.
Mark Carrigan 