We've recently taken the decision to "release" the WISERD DataPortal. This isn't to say that all the functionality we're after is 100% implemented, but that which is there is working in a fairly stable manner. There are bugs, but all software has bugs - I'll write a further post about how bugs can be defined and dealt with later on.
Releasing software, especially the first roll-out of a new service, is stressful. I'm having to force myself to say "This works, let people try and use it", when my gut feeling is more "But what if I've overlooked something major, and end up looking stupid?".
As far as I can tell from the releases of all software, - and even hardware - from small end "Indie" games, to huge operating system scale products, bugs are always going to be discovered and it's up to the developers to manage these issues as they arise.
At this point, different companies and institutions have different ways of managing their users expectations. I'll take 3 examples from common household names and describe their reactions to users issues with their products. On the "low" end, there's Mojangs Minecraft, considerably larger is Canonical's Ubuntu, and on the very high end there's Microsoft's Windows 8 operating system. For a bonus example in the hardware sector I'll describe Apples iPhone 4. I hope my reasoning for choosing these becomes clearer as I go.
Indie games are generally smaller products, produced by small teams, with low budgets and are targeted at a fairly niche audience. These are not summer blockbusters, but rather more experimental pieces which can afford to drift slightly from the accepted expectations of what certain genres normally offer. Due to the need to get a revenue stream going as quickly as possible, alpha, beta and RC (release candidate) versions are pushed out to the public for testing very frequently, up to multiple releases per week. The users expectations are managed by the developers by a continuous discourse through social media, where it is admitted openly that the product is not finished, major features are likely to be broken or missing entirely, or that each version may be incompatible with previous releases.
This is not a lazy or incomplete way of working, as both the developer and the users gain from this relationship. Developers, as long as they listen to the user feedback, essentially have a free testing panel, and new features can be added dynamically with the users requests in mind. Obviously managerial oversight and vision is required, but the overall development process is very inclusive of the users wishes. It is also a more personal approach, with users often getting to know the developers by name, and personalities can show through.
In contrast, the development and release of massive software packages such as those created by Microsoft, Apple or Google are not able to be as collaborative with the user base. It is easy to say there is zero relationship with the users until the release of the final version, though this is not entirely true.
Microsoft managed their user expectations very early on, by releasing initial press releases describing Windows 8 very early on, with screen shots, slideshows and videos of actors looking very happy to maximise application windows in new and exciting ways. A beta version of Windows 8 was released for those interested in the "Developer Preview", which was downloaded over half a million times in the first 12 hours of it's release. This was a totally different type of user interaction, essentially talking to developers of future software designed to run on Windows 8. Regular users would have little input on features within this development, their feedback would mainly be in the form of bug reports or forum posts to customer services representatives. While there is a development blog, the general vibe is still one way, information flowing from the developers outwards. As a market leader, new features are designed to show users what they can have, rather than creating what users want.
Bridging the gap between the fairly small and extremely large, Canonical develops the Ubuntu operating system in a way that utilises user input in a very collaborative way, (users code can end up in future releases) while retaining overall quality control and direction. Both forums, blogs and press releases are used, of specific interest here is the Brainstorm feature request site, where users can create and vote upon ideas within the community. This is a great way to crowd source the development process and target efforts at those most in demand.
To finish up, I'll mention the PR fiasco that occurred around the iPhone 4 when users complained about reception issues. It turned out that holding the phone a certain way caused a short circuit across the metal band around the phone which acts as the aerial. User feedback was met with a very strange reply which confused and angered users, eventually ending in a class-action lawsuit and a free phone cover for all iPhone owners. The message here is not that lawsuits are a convenient way to improve product design, but rather that interaction with users should always be collaborative and productive to both sides.
So the message here, which I've taken a long route to get to, is that communication with users improves products and user experience, as well as providing valuable insight into the needs of the user when planning future features and improvements. For smaller audiences, social media and a more personal interaction can be invaluable in building a user-base that can actually make the developers life easier, rather than more stressful.