I am a late adopter when it comes to technology. Whether it was with games consoles when I was younger or more grown up (i.e. less exciting ) tech today, my inclination will always be towards being a year or so behind the times to allow the technology to consolidate and the entry costs to come down. This month I bought my first Android tablet. My main intention was to use it for writing while travelling or at conferences to ease the pressure on my poor iPhone. With this in mind my first actions on firing the tablet up were to search for and install some blogging apps.
Despite my poor experience of the Blogger app on my phone I started with the official app, figuring that at least it would provide a useful basis of comparison. Mixed reviews had me expecting a limited experience but I was surprised at how much I struggled, and more importantly, how quickly I got into trouble.
I swiftly established how to load my existing posts and drafts from my blogger account into the app. My problems started when I attempted to edit one of my posts. It was easy to select an existing draft and view the content, however I could see no obvious way of editing the post. Next to each post was a checkbox and selecting this presented two new buttons at the top of the screen.
The dustbin was clear enough, but the other was not an icon I was familiar with, and I could see no obvious way of finding out what it did. I clicked it, not much happened apparently, I was just returned to my list of posts. I was not presented with any information on the action I had just performed or the results of it. On closer examination I realised that the result of my action had been to publish the post to my site. Needless to say the content was in no way suitable for publication and it's presence on there was potentially embarrassing. That was the first problem.
The second problem became apparent soon after. I could find no way in the app of reverting the post to draft status. Once it was posted it stayed posted, at least as far as the blogger app was concerned Being acutely aware that this non-post was sat on my RSS feed for any subscribers to see, I quickly had to access the web management console for my blog in order to revert the post to draft.
I had only used the application for 5 minutes and within this brief period had managed to make an embarrassing mistake. It was noticed too, with one of my colleagues mentioning that he'd seen the post in his RSS reader the following day. Within 5 minutes of use I had reached a point of being serially unimpressed with this app to the point that I never wanted to use it again. If I had spent longer working with other applications then it's possible the problem wouldn't have happened. The fact that the application was the first I had used in that environment, and my therefore being unfamiliar with the iconography, was a primary factor in my messing it up so badly. More importantly, it turns out that you cannot edit posts written in other programs within the app. If the inability to edit existing posts had been made clearer from the start then I would have created a fresh entry to test out the app. As an experienced blogger, however, with a pre-existing set of draft posts, it was natural that I would use one of these when trying out the app.
The First Five Minutes
In the world of highly commoditized software the importance of providing a good first impression is vital. When the SVP of engineering first joined my company as a Product Owner one of the first things that he prioritised was the `First Five Minutes` of customer experience. With a server side command line driven application being primarily marketed to technology departments, one would have thought that the initial user experience was a relatively low priority. On reflection the work that we did in that period on ensuring a simple and seamless setup and demo installation put us in an excellent position to give a good impression of the product to new customers. On more than one occasion we received positive early feedback from pre-sales engagements due to our software installation and configuration having been the least painful part of a multi-technology installation. As I wrote in this post having a smooth installation process is vital and merits targeted testing. The first five minutes goes way beyond that. It is about a users initial impressions of the working software. Yes a bad installer can drastically derail that, but an installable product is a minimum expectation. It is in the first few minutes of interactive use that impressions are really formed, and in the UX arena there are a wealth of techniques on how to provide a good user experience in those early minutes of use.
When testing scenarios covering the early user experience the temptation may be to adopt a 'clean state' approach to the user's data stat, the experience I describe above highlights a different scenario which is becoming more prevalent in modern applications.
The worst 5 minutes
The critical factor for my experience with the blogging app was that, whilst it was the first time I had used this software, I was doing so with my own set of pre-existing online data. With increasing levels of online personal data and APIs to access it, the context for many modern applications is that users will be bringing a wealth of existing data with them. Whether online data such as my blog above, or existing data being imported from other systems, users early experiences increasingly involve their own existing information. Consequentially the 'first five minutes' not only has to impress, but must also consider the risk that inexperienced use could present to the user's valuable data.
In a database archiving context testing in the context of both expectations and actual data from other systems is something that I have to consider inherently in our testing. Our users may be experienced with databases but it could be the first time they've used Linux, and we must consider the mistakes that could be made in that situation. Similar considerations are relevant to cases like my Blogger encounter, where we may have experienced online users, with a good understanding of their existing data, but who are inexperienced with the device and operating system.
With the increase in applications that operate on existing customer data in online systems, the scenario of initial customer experiences occurring on existing data is one that must be considered. When customers try many online products for the first time they are not only trying software. They are entrusting the makers of that software with their carefully crafted online personas, profiles and content. Any mistakes that they make risk damaging not just the experience but a person's data, pride or even credibility and livelihood ( I have no qualms about admitting that I messed up. Personally I feel that too few of us genuinely admit mistakes openly, but that is for another post. ) In these scenarios it is important to consider what harm could be done during those early minutes. What mistakes might they make and with what consequences? As well as trying to provide an impressive 'first five minutes', we also need to ensure that we respect the data that the user brings to these encounters, and target testing appropriately to ensure that these early moments don't become the 'worst five minutes'.