This post is in response to Jakob Nielsen’s update on Sharepoint, entitled ‘Does Sharepoint Destroy Intranet Design?’. For the last year I’ve been working closely with Sharepoint, and want to wade in to this discussion.

Are intranets all the same?

Nielsen’s update argues for Sharepoint as an effective base for an intranet. Counter to the argument that the standard Sharepoint toolset doesn’t allow much flexibility when designing, he presents four different intranets, all based on Sharepoint, as evidence.

The evidence Nielsen supplies for this conclusion, that Sharepoint still allows intranet design, seems… dubious. For example, he lists the different top navigation categories as evidence that the sites design is different. I would hesitate to define the designing of an intranet to be entirely about information architecture (the categories chosen for top level navigation), and would suggest that the ability to design a flexible intranet goes much deeper than this.

About this much deeper...

Sharepoint isn’t perfect

Having worked closely with Sharepoint for the last year, it’s obvious that the usability problems within Sharepoint are more important than its ability to define navigation categories.

For example, this is how you’d upload an image from your hard drive onto the page you are editing.

1. Click ‘edit page’. Wait for new page to load.
2. Click in the area, and click on image button.
3. New window comes up, click on ‘browse’.
4. New window comes up, Only shows 8 images at a time – verify the image you want isn’t already uploaded (through lots of slow page refreshes).
5. Decide to upload, click ‘upload’ (note that the directory you have been browsing is not the directory that it’ll upload too – instead it always uploads to the same directory. And has no tools to move the image to a new location, besides opening the directory in windows explorer to do it)
6. New window comes up, click browse, find the file, click upload.
7. Find the image in the thumbnail viewer (remember, only 8 images at a time) –
8. Click ok on every box that’s opened
9. Click on ‘check in’ to view page.

A tad unnecessary?

Similarly, small usability ‘mistakes’ seem to exist throughout Sharepoint.  For example, Sharepoint keeps old versions of the file or page you’re working on, in case you need to restore it. (note this doesn’t work on ‘web-parts’ – areas of the page which contain JavaScript or custom html). To remove these, which is a common requirement due to file size restrictions, you must:

1. Right click on a file, select ‘version history’.
2. Right click on an invidual version
3. Select  ‘delete version’
4. Accept confirmation box
5. Refresh the page
6. Go to 2

I often encounter files with hundreds of versions. This process takes hours.

So the solution to this is obvious and widely seen elsewhere (even in other areas of Sharepoint!). A row of tick boxes down the side of the list of versions, with ‘select all/none’ buttons. Then a ‘delete selected’ button. This would save hours on intranet maintenance, and seems like a massive oversight.

Conclusion

Although Nielsen’s argument that Sharepoint doesn’t prevent intranet customisation is legitimate, I feel Sharepoint has more pertinent usability issues that prevent it from being the perfect CMS to build an intranet upon.

Nielsen over-represents the amount of customisation possible – although you can change the navigation, and the pictures/layout, Microsoft impose definitive restrictions upon what can and cannot be done, often prevent usability issues from being fixed.

Instead, I suggest an open source CMS like Drupal would provide a better base for an intranet. By giving the administrator full control over the CMS’s inner workings, Drupal not only allows a wider range of customisation, and design to take place, but it also benefits from a plethora of user created modules which add almost any pre-generated functionality that can be imagined. As such, it not only allows the limited customisation that Sharepoint can, but gives the user the chance to fix usability problems through customisation, and extend the functionality in ways limited only by imagination.

Related posts:

1. iPad Usability Study
2. The user experience of Ticketmaster ruins Christmas

The presentation first covers ways in which the UX lessons learnt from games have, or can, be applied to dull tasks to incentivise people to do them. Some examples of this can be found on Volkswagen’s thefuntheory.com website, such as turning a staircase into a piano to encourage people to take the stairs, or turning a bottle bank into a game to encourage people to recycle.

all the encouragement I need...

Deterding does provide some critical analysis of this model – what happens on day 2, for example? Is it still fun to recycle? I also question the justification provided by Volkswagen that the bottle bank performed better than a standard one. Although it did in the example, when the user was provided with a choice between two geographically-close bottle banks, this fails to be a conclusive proof of the fun bottle bank being more effective at encouraging recycling. (would the ‘dull’ one receive an equal amount of recycling to the fun one if there was no alternative – what about over a number of months?)

The typical theory of fun is that ‘adding points’ will magically make dull activities fun, because of It adds competition, re-playability, and a new ‘meta-game’ to the activity taking place. However, Deterding’s presentation challenges this, and says that ‘just adding points’ is a too simplistic understanding of the application of fun to menial tasks. Instead, games present an optimized version of many positive psychological features of real life, and through the recognition of this, real life can be optimised.

As I discussed in my review of Ralph Koster’s book, ‘fun’ is the act of learning and successfully applying, and adapting the knowledge learnt, and typically games present an adaption of this. Games optimise ‘fun’ because:

• They allow the construction of clear, realistic goals, with measurable progress
• The goals are presented in a manageable manner, with a clear ‘call to action’, indicating what is to be done, and when it has been achieved
• The player’s current status is clear, and their progress towards the end goal is indicated
• New tasks are built upon knowledge already gained
• Social comparison can be made with your friends to compare progress

So the obvious way of making dull tasks fun would presumably be to integrate these principles from games? However this conflicts with software, and menial tasks, core goals of efficiency. As I’ve noted before, ‘press a button to win’ is effective, but not fun.

Unlike games, software (and menial tasks) doesn’t give designers full control over the environment – instead the user defines the goal (such as ‘write a letter to the TV Licensing people’). This makes direct application of the features from games difficult.

We have taken re _ _ _ sses_ _ _ of your _ a _ s _ _ r

Instead, Deterding presents us with a list of ‘patterns, models and words for emotion and rule design’, that he has derived from games. Unfortunately, they are not as simple as ‘just add points’!.

I highly recommend watching Deterding’s presentation, it is an effective synopsis of a debate that is very much still in progress, and shows us why a simplified or direct application of Ralph Koster’s rules doesn’t work with non-games, despite what Volkswagen have been showing us. Instead, Deterding presents his own models, which are not as simple, or easy, and yet may turn out to be a more practical lesson for how we can apply knowledge from games to improve the user experience of mundane tasks.

Related posts:

1. Make work fun – examples of applying the UX of games
2. Get Lost! – Improving player experience through signposting and map design in games.
3. Games Usability Testing is not QA!

Just under 16 years ago Microsoft attempted to reinvent the desktop metaphor, and bring it up to date. The product, Microsoft Bob, aimed to shift computing from an office metaphor to a home metaphor. And it was a massive failure. My first home computer came with Bob installed, and so today I’ll be looking at why it failed, and what we can learn from this failure.

Usability advantages of the desktop metaphor.

So why has the desktop metaphor proved to be a lasting success? Introduced at a time when graphical methods of interacting with a computer were new, it had several key characteristics that led to its success.

...such as fun games

First of all, the desktop was familiar. Rather than having to learn context specific methods of interacting with a computer, it built upon the user’s pre-existing knowledge. For example, when deleting a file, a user could use their existing understanding of a trash can, and drag the file into it (rather than running a deltree command, which doesn’t map with any real-world knowledge). Therefore the desktop metaphor was easy to figure out, and consistent with real life experience, reducing the learning curve upon adoption. This meets Nielsen’s heuristic on a ‘match between the system and the real world’.

Building upon this familiarity was the appropriateness of the desktop metaphor for the tasks at hand. Before home computing, the workplace was the most likely place for users to use a computer, and the computer would be performing office-based tasks, such as word processing or calculating. Hence the adoption of a workplace metaphor seemed appropriate for developing a graphical user interface, as it registered with the target market. This meets Nielsen’s heuristic on ‘recognition rather than recall’.

Furthermore, the desktop metaphor was wide enough to expand to meet the growing roles that computers played. By extending the workplace metaphor through terms such as ‘cut’ and ‘paste’, and the development of graphical tools emulating image manipulation tasks, the desktop metaphor proved that it wasn’t static, and could extend to reach an ever growing range of requirements.

The desktop metaphor also met the heuristic requirement, of having a wide degree of flexibility, by allowing ‘experienced’ users to automate or speed up tasks, such as by selecting groups of objects, or utilizing keyboard shortcuts.

What did Bob try to do?

In the mid 90’s, Microsoft Bob was devised as the successor to the desktop metaphor. Recognising a growth in home computing, Microsoft aimed to shift the graphical interface model for computing from a business/creative focus, to the ‘home’. It was thought that this would open the computing world to a whole range of ‘novice’ users, who would have found the desktop metaphor inaccessible.

Bob presented the user with ‘their room’, covered with clickable objects, such as bookcases, clocks and a notepad. Clicking these things will launch the relevant program (or help you locate files), and you can add your own programs to the shelves. It’s just like your home! (assuming your home is littered with boxes that say ‘Internet Explorer’ and ‘Corel Draw’).

Bob in action

Why did Bob fail?

Microsoft Bob offered an alternative to using the desktop metaphor, aimed at novice users, but its primary failure was that it didn’t offer any significant advantages. For a product that came over twenty years after the ethos of its competitor, this wasn’t a good sign…

Despite being based on the home, Bob still had a learning curve, and so missed it’s key objective of being intuitive. Clicking on a clock to open a calendar, or a pen and paper, still required just as much learning as a calendar or notepad icon in a traditional desktop environment. More complex tasks than just opening programs still require further learning. Also, the enforced ‘home’ layout is just plain inefficient – rifling through a cabinet to find a file offers no advantage to browsing a list of files in a folder.

By attempting to change the way people interacted with computers, Bob alienated itself from existing computer users, and prevented new users from being able to ask for help from power-users. By offering only ‘simple’ ways of interacting with computers, the user was unable to allow users to grow, and learn superior (and more efficient) ways of performing tasks.

It’s also apparent that the ‘cuteness’ of Bob didn’t sit well with users. The two elements of this operating system which outlived the OS itself are among the most hated villains of computing – Virtual assistants like Clippy, and the Comic Sans font. Obviously Microsoft failed to understand the needs of their target market.

The final nail in Bob’s coffin came within a year of its release. Microsoft released Windows 95. It sold… quite well, and offered a fully-powered alternative to Bob based on the traditional desktop metaphor. Bill Gates punished those responsible for the mess that was Bob. He married lead project manager Melinda French. Burn.

What will replace the desktop?

It’s obvious through Bob’s failure that the Desktop cannot be beaten by a simple re-skin or appropriation of another metaphor without offering significant advantages.

As I wrote about in my review of The Humane Interface, Raskin proposes a ‘Zoomworld’ which offers a non-windows environment with no gaps between the operating system and the files. However development by Archy has stalled and they seem to have fallen off the internet…

Or maybe the future will be more like Google, and involve typing queries or commands into a prompt to find answers and perform tasks? Although this does seem like a regression, and breaks several key usability best practises.

So what other systems are out there that offer a viable alternative? Or will it be desktops forever? As ever, I’d be interested in hearing your thoughts in the comments below!

Related posts:

1. Evaluating existing technologies, paper prototypes in action, Windows 7 and the disappointing user experience of my DVD player!

An iPad Nano

Jakob Nielsen admits that the study is not as thorough as a typical usability study. However has decided to share it anyway, due to the over-inflated impact that usability studies produced early in a devices’ lifecycle have been seen to have. As an aside, this is an interesting contrary viewpoint to the disadvantages of being first-to-market noted in ‘Inmates’, which argues that being first to market is irrelevant compared to being ‘best’.

The report has some interesting key findings, including that the apps seen on the iPad and the iPhone suffer from the re-emergence of a problem not seen since the early 90’s. Unlike web browsers and desktop software, which has established graphical conventions to highlight buttons and GUI elements, iPhone and iPad software has not implemented standard conventions, such as making a clickable button appear 3D. Hence there is no consistent manner of designating important aspects of the UI, and users just didn’t know what they could click on. Nielsen likens this to the first emergence of graphical interfaces of the early 90s, when anything and everything could be a button.

Its therefore clear that the main recommendation of the study is to standardize common elements, like navigation, among first and third party applications, such as “swipe to turn page”, or “press and hold to delete”. This also links with the studies’ findings that users were unsure what reaction their action would cause, as the apps have yet to find a consistent manner in which to work.

Not just a big iPhone

The study highlights how the iPad is not just a big iPhone, and different usability issues emerged on the larger device – most pertinent is that navigation elements on the bottom of the page, as seen in many iPhone applications, will not work on the iPad. The larger screen means that these elements are too far from the user’s field of vision to be noticed – and hence are not appropriate. What this means for people who make apps is that a custom iPad version is needed, not just relying on the ‘universal’ up scaling of iPhone apps.

The full report is linked below, and worth a look if you’re interested in the usability, the iPad, or designing an application!

Read the full report, here.

Related posts:

1. Five essential iPhone apps for usability professionals
2. Usability Issues in Sharepoint
3. How real-world game usability testing is changing

Traditional Software Development

In the olden days, and today in large unwieldy companies unsuitable for adaption, software was produced using a waterfall methodology. The waterfall methodology involves splitting the design process into distinct stages, and completing each stage before moving onto the next. Exactly unlike a waterfall. Some standard stages are

• requirements gathering
• design
• coding
• testing
• deployment

Each of these stages would be completed, documented and signed off when completed. Effectively this means that there is little scope to go back and make changes based on emerging requirements. For example, after coding has begun, no further design work could be done, even if the user’s needs change.

Another danger of the waterfall methodology

This methodology was found to have numerous problems, and be unsuitable for a typical software development process. So in 2001, a group of engineers came together and devised the ‘Agile Manifesto’

Agile Software Development

The Agile process aims to address the inflexibility of a traditional waterfall methodology. Essentially Agile development is iterative, and consists of short repetitive cycles. These are typically:

1. evaluate the existing solution
2. design a solution, based on the last solution, to the problems found during evaluation
3. build this new solution
4. GOTO 1

With a cycle being completed every few weeks, this process should be repeated until the software is complete (or no significant problems are found with the solution)

Sometimes going in circles can get you somewhere

Agile and UX

So why is the Agile methodology best suited to integration with user experience testing? Since you ask, there are a whole bunch of reasons!

1. The Agile method gives a workable product that can be shown to users earlier, getting their opinions and insights straight away.
2. Has appropriate stages for fixing problems found by users earlier. In a waterfall methodology users won’t see a product until the last phases, and by then changes will be costly, or impossible.
3. Waterfall methodologies assume that you can know everything about the requirements of a project at the outset. Real life experience with clients shows that this isn’t often the case. Agile allows for input throughout the process, and doesn’t presume to know the unknowable.
4. Waterfall only engages the stakeholder s (anyone who is interested in the final product) at the beginning of the design process, and then keeps them in the dark until the final unveiling at the end. Obviously this makes what would normally be a minor problem with the final product into a big deal, because it is ‘complete’. In contrast, using UX methods on an Agile methodology keeps stakeholders invested in the product throughout the design process, minimizing dissatisfaction with the final product, and ultimately leading to happier stakeholders.

The UPA have recently been focused, in their magazine coverage and events, on integrating UX tools into an Agile methodology, but I’d be interested in hearing other people’s thoughts, or insights into the advantages of Agile. What are your thoughts on Agile?

Related posts:

1. The right environment for user testing
2. How real-world game usability testing is changing

Why do teams need to understand UX?

When working within a team, whether it’s a small web development company, or a large multi-national company, it’s impossible for one person to oversee every aspect of development. That is why it’s important for everyone to understand the principles of user experience, due to the large variety, and span of tasks that it encompasses. A good user experience designer is not the one who works longer hours, or has more creative control over the final product, instead they are the one who makes sure everyone understands UX  goals, and works towards them.

It is this reason that books such as Krug’s Rocket Surgery Made Easy heavily promote the idea of getting everyone, from the CEO to a junior developer, involved when testing with real user’s, as it is these people who will be able to implement user experience ‘fixes’. The solution Krug suggests involves inviting these people to view the user testing sessions, and bribing them with snacks.

Because encouraging successful user experiences requires everyone’s involvement, it’s important that everyone understands the goals of user experience, and can incorporate them into their work. The problem is making them understand what those goals are.

Pictured: not a goal

What are stories good for?

Homer’s Odyssey was composed in the 8^th century BC, and yet a canonical written version wasn’t produced for another 300 years. Before this, the tale was remembered, and shared orally, through song. Considering that the Odyssey contains over 12,000 lines, this is no small feat. That’d be like remembering, and reciting on demand, every blog post I’ve done so far… So how was it possible?

The answer lies in the power of stories. Stories, like Homer’s Odyssey, are memorable, due to the plot and the events contained within, and hence easily form visual images within the mind, and aid memory. Plots make stories interesting, and hence easier to remember than non-fictional texts (such as remembering all of my blog posts).

Stories can also be used to impart useful information. These be obvious life lessons (The Three Little Pigs teaching the benefit of putting adequate effort into your tasks), or life saving, such as Ring a Ring o’ Roses imparting symptoms of the Black Death (although this may not be true)

or Cinderella teaching us the dangers of stepmothers

Using stories for UX

So, stories are memorable, can be used to impart useful information, and are easily transferred, as made evident by the 300 years that Homer’s Odyssey lasted without being written down. Hence they seem ideal for the promotion of UX within teams, as they can be used to quickly impart the benefits of UX, and what each individual needs to do to aid a user centred design process, in a memorable and transferable fashion. By bringing the whole team onboard with the principles and goals of UX, a greater degree of coherence can be achieved across the team. Therefore to get better results without manually verifying everything the team does, a User Experience Designer needs to champion user experience principles with all members of the team, and stories are an easy way to do this.

Some examples of UX stories

Many authors have understood how stories help to impart information in a memorable fashion.

• In The Design of Every Day Things, Don Norman uses stories of real world examples to emphasise the dangers of ignoring user centred design, with examples including nuclear accidents and plane crashes.
• Stories based on metaphors are also used by Alan Cooper in The Inmates Are Running the Asylum to emphasise the importance of designing for the end user, by comparing the software design process to film making.

Also of interest, Sam Nixon shared a short story by David Travis called “The Fable of User Centered Design”, which aims to bring clients and team members on board with the benefits of a user centred design approach. Definitely worth the read, and should be shared. The book is available to download from his website.

If anyone has other examples of stories that help define the importance of user experience, remember to leave a comment below!

Related posts:

1. The user experience of Ticketmaster ruins Christmas
2. Evaluating existing technologies, paper prototypes in action, Windows 7 and the disappointing user experience of my DVD player!
3. The right environment for user testing

The task was relatively simple – design some worksheets, including textboxes, and pictures, and lay them out in an eye-pleasing manner. I’m sure there are many more appropriate packages to make this in than Word, but it was the user’s software of choice, due to familiarity, and the task shouldn’t be beyond MS Word. I observed, and let them lead the interaction, but advised when they asked for help (naughty I know, but it wasn’t a formal lab setting!)

The lab was busy that day anyway...

How my ‘less-technical user’ used Word:

I noted down (obviously away from the user) some of the more ‘interesting’ characteristics of how they used Word.

• Used the ‘cut’ function as a ‘delete’ (with no understanding of how it links to paste). Taken out of context from “cut and paste”, ‘cut’ would more likely imply removing or ending something, and so this mistake is understandable. Incidentally this method has some pluses. I still don’t know how to remove a table easily (not just the information within it), and cut seems to do this.
• No knowledge of the alignment tools, and so using spaces as a method to align text to the center or right. Obviously ran into problems when editing the text later, as changes would make the text run over the end of the line, ruining the formatting.
• Drew horizontal lines, across the page (i.e. a space to write in your own answer) with –‘s. Seems a pretty effective method, even though I’m sure Word has its own way of doing this. Is there a better way of doing it?
• Displayed difficulty moving images in Word. Is it right that you have to click on an image twice to move it? The first click just gives you resize options, which confused the user.
• Had difficulty with resizing objects. What happens if you make an image so big that it falls off the edge of the paper, and you cannot see the border to make it small again? I guess you could format picture, and manually change the size, but this is an entirely different method of resizing, and isn’t cognitively related to the standard way.
• Constant (constant!) rewriting of words, when word autocapitalised/auto formatted them in an undesired way (which was seemingly every autoformat). User had to delete the word, and re-write each time.

What could word do to improve?

This immediately throws up some questions about how Word was developed. It’s clear that the tools available, such as the alignment, or horizontal lines, are not making their functionality transparent to new users. It wasn’t clear to my user that they existed, or how they should be functioning. Obviously just having the icon on the toolbar isn’t enough, and this should be rethought.

This was also the case with image manipulation. The functions that the user needed do exist in Word (i.e. resizing, moving), but are modal in nature, and so are difficult to find, and don’t offer a consistent user experience to someone who is not familiar with Word’s nuances.

It’s also clear with auto format in particular that the system isn’t adapting to the user’s needs. The constant changes that Word was making to the user’s document, which were then undone each time only created a large degree of frustration in the user. The software should be learning how the user wants auto format to work, and adjust to their preference. In this user’s case, it was causing trouble, and should have turned itself off (or at least given the option)

What they need is some sort of helpful assistant

What should we learn from this?

It occurred to me that these issues were not unique to the user I watched since I encounter similar problems with Word. The difference is I’ve had enough familiarity to learn the workarounds, or solutions to these problems that Word throws at you. For example, it’s an unthinking reaction to press Ctrl+Z after Word incorrectly auto-formats things incorrectly. My user just hadn’t used the program for long enough to train that reaction, and so word’s error became more of a big deal.

Its important when considered usability to realise that users aren’t just like you. If you are in a position to make a difference with usability, it’s very likely you are not an ‘average user’, and as such its difficult to comprehend how ‘average users’ use software.

‘Average users’ are not stupid. They are your mum, and just don’t have the time, or effort to put into learning these workarounds, or making them second nature. The solution, rather than ‘educating’ users, is to make the programs better; make programmers understand who their users are, and how they use the programs. And make them program for the ‘average’ users, rather than the power users. And that is the point of usability.

Related posts:

1. Test with real users – not your team
2. The user experience of Ticketmaster ruins Christmas

I’m in the process of designing a GPS game, and am currently discovering the functional requirements for the project. As UX practitioners, we know that involving the user is of critical importance at this stage, hence we designed a questionnaire to establish peoples experience, and perception of GPS games, and what they’d like a GPS game to be like. (linked here)

When at university, our internet access goes through a proxy server, which blocks unsuitable content. For some reason, this includes surveymonkey.com, a site I’ve used a few times in the past to construct online surveys. Interestingly, the ‘site blocked’ dialogue said “for survey sites, try zoomerang.com”. However, when I search for some hardcore action, it never gives me alternate suggestions for that. Have I uncovered a conspiracy? Nonetheless, I followed the link.

And so I ended up on zoomerang.com. Being fair, there is one key advantage to zoomerang which immediately put me in a good mood. On surveymonkey, for a free account, you are limited to ten questions. On Zoomerang, you can ask 30 questions before you have to pay. This meant we didn’t have to redo, or concatenate our questions, and made me smile inside

Pictured: an inside smile

Problems with Zoomerang.com

This goodwill was shortlived, when I tried to use the site to implement my questionnaire. Heres why:

1. The workflow isn’t clear when making a survey, and so I entirely missed the step where you add your questions. Clicking through the process actually caused me publish a blank questionnaire. Which wouldn’t be a problem, except…
2. …You can’t edit an existing survey. Once its published, you cannot add/remove/change questions. Surveymonkey allows this. So I was stuck with my blank survey, and had to start again from scratch.
3. Having figured out how to add questions, I got started, and selected “insert question”. It added a header, which then had to be changed to type question. I guessed that was because it was my first item, but no, it always defaults to inserting a header (odd, since you’d only need 1 per page, whereas you’d need multiple questions).
4. So I finally got to add a question, and this is when the terribleness of the design struck me. I selected a question where a radio button would select from a number of answers, and typed in my list of 15 or so alternative answers into a rich text field. I hit submit, and … got an error, saying “answers can only be 1000 characters, including HTML”, and even worse…
5. …It deleted the data I had entered in that field. All 15 answers. This is a critical failure of any system, since the data a user inputs should be considered sacred.
6. There was no counter telling me how many characters I had entered, so I had to retry a few times. Eventually I realised that I could only enter 5 potential one word answers before it’d error that I was over 1000 characters. That had to be a mistake? I investigated further…
7. …Looking at the HTML, it turned out that the rich text editor was writing rubbish html. At the start of each answer, it’d add needless style tags, often multiple times. Heres an example of the HTML it generated for my one word answer “complicated”
   
   <p><span style=”font-family: Arial; color: #000000; font-size: small;”><span style=”font-family: Arial; color: #000000; font-size: small;”><span style=”font-family: Arial; color: #000000; font-size: small;”>Complicated</span></span></span></p>
8. …no wonder it was hitting the character limit after 4 or 5 words. I had to manually enter the html for all the possible answers, just so I could get round this.
9. My last fault with zoomerang.com is just a suspicion. I look after my email accounts, and so have never received spam in my current primary address. After signing up for zoomerang last week, I received my first random spam email. Might just be a coincidence, but I didn’t sign up for anything else that week!

I had to call this guy to fix my survey

How to fix zoomerang.com

To improve their user experience, they should look at red-routing the goals the user needs to achieve:

1. Make the progression through survey design clearer, highlighting which step questions are added in
2. Also make it clear how far through the design process you are, and what steps remain
3. Restrict what the user can do, so they cannot post a blank questionnaire. Its obvious if they are about to do this that they’ve made a mistake, tell them!
4. Don’t make question types default to “header”. Surely users will only use this type once at most, whereas they’re going to have more than one question on the questionnaire. Make it default to that!
5. Fix the WYSIWYG code generator, so that the user doesn’t have to manually code the answers in HTML. A lot of user’s would get stuck at this point!
6. Don’t send me spam!

And what can you do, until these fixes are made? Use surveymonkey.com. Or, if you’ve found anything better, leave a comment and let me know!

Related posts:

1. The user experience of Ticketmaster ruins Christmas
2. 7 aspects of successful usability questionnaires
3. The Problems with Surveys for User Experience Tests

The Digiscent iSmell

Have you ever been on the internet, perhaps visiting your favourite Star Trek fan-fiction forums,  and thought “yeah, this is pretty good – but I wonder what it would smell like?”. Well Digiscent heard your cries, and created a device that allowed you to smell the many scents of the internet.

...mostly tears and sweat

The idea was that the iSmell would combine its 128 ‘primary scents’ to create a custom smell for your webpage, advert or email. iSmell owners who visited your page would then have the custom made smell wafted to them through the power of USB, so they could enjoy it in their own home. The possibilities were endless; you could enjoy the scent of roses when receiving email from your favourite online-florist (what? we all have one!), or enjoy an endless supply of the ‘new car smell’ from your local car dealership. To say nothing about our ideas for the adult site i-like-feet.com

Unsurprisingly the product failed (I was shocked too!). Why? They never asked users what they wanted. If they had, they may have realised that “what does it smell like” was a question almost never heard on the internet.

well thats proved me wrong

Instead of using user testing as a way of determining what colour the device should be, they should have asked users, before even starting designing the product, what they would use it for. From lo-fi prototypes, and attempts to create scenarios of use, or personae of people who may need to use this product, they would have realised that the product wasn’t needed by their users, and didn’t give a noticeable improvement to their internet use. Since they didn’t use a user centred design methodology, they created a product that was useful for no-one. Oops!

So keep in mind, when you start your next project, that the user’s needs, the usability of a device, and the user experience should be a consideration from the start, and not just an afterthought. And the  most obvious evidence that Digiscent failed to ask users about their product? They called it the ‘iSmell’.

Related posts:

1. The right environment for user testing
2. HCI learning, a day analyzing user experience, and thoughts about remote usability testing
3. How real-world game usability testing is changing

Working with usability requires a wide range of abilities, and hence these tools reflect the wide range of roles a usability professional may be performing. When talking about each app, I’ll try to cover where in the usability process it may come in useful, and how it can help you to increase efficiency and get better results.

but don't forget lo-fi alternatives

1. Pidoco°

Starting off, this isn’t strictly an iPhone app, but Pidoco’s software has been developed to be compatible with mobile browsers and the iPhone. I saw them demo the software at a recent UX Brighton event, and they impressed upon me that it was built with usability in mind. Pidoco offers a quick way to collaborate on the design of wire frames, and quickly show these to the user or client, without the need to be in the same geographic location as them. The easy to use nature of the system means it’d be ideal when iteratively testing an interface with users, and is a mid-fi alternative to paper prototyping. Currently offering a month’s free trial, there’s no excuse not to give it a go!

Pidoco°’s website: https://pidoco.com/en/

2. Mocha VNC

Need to mock up a mid-fi prototype of an iPhone App? You obviously don’t have time to make the app in Xcode, buy the iPhone developers license, link the customer’s phone to the computer and copy the app over. Instead, how about making a prototype on your Mac, or PC and using a VNC client to make the iPhone look at the prototype. The user will still be able to interact with the prototype by clicking, or navigating around, and the ‘controller’ sat at the server can display the correct pages to the user. Easy mid-fi prototyping, on an iPhone, without the long set up costs and investments required to actually have the app running on the iPhone.

Mocha VNC’s website: http://www.mochasoft.dk/iphone_vnc.htm
 

3. Camera

Watching someone perform a task is an important part qualitative usability testing. What about those moments where you weren’t looking, or noticed something that you wanted to ask about later, but forgot about? Looks like you need to be recording your user tests. Camera comes with all iPhones, but is only available for video recording on the 3GS. Since you are always likely to have your phone with you, it’s a handy mobile solution that allows you to record your usability sessions without requiring any additional equipment, so that they can be analysed later. Maybe buy a stand for it though!

4. exZact Data Collection

Quantitative research is also an important part of establishing user requirements, and working towards a design that meets their goals. The Data Collection iPhone app aims to allow you to create, and answer, custom surveys on the iPhone, collecting information like geographic location, and responses in a variety of forms (1-10 ratings, drop down lists, yes/no responses, and comment boxes). They then offer real time analysis, so you can see the results as they come in, and claim to be massively scalable. Offering a month’s free trial, it seems an effective solution if you require your data collection method to be mobile, and accessible anywhere.

exZact’s website: http://www.iformbuilder.com

5. Insight – Basecamp on iPhone

You’ve seen from the diversity of the apps above that a usability specialist has to be experienced in a lot of areas, and its often hard to keep on top of these. A tool that I have found invaluable in project management is Basecamp, which allows you to collaborate on projects, assign tasks and see what everyone is up to. Insight is a mobile version of Basecamp, and will allow you to keep up to date with how everyone working with you on the usability project is progressing from one easy interface, and keep on top of projects. As a busy person, it’s likely to be an invaluable tool to any usability specialist or contractor!

Insight’s website: http://www.encampapp.com/

Conclusion

Its clear from looking for the most useful usability apps for the iPhone that this is a largely untapped market – although there are tools available to help with the individual steps in the process, there is no one ‘go-to’ app for usability and UX professionals. What is needed is a more holistic solution, one that can work with a usability professional in every step of the process, from the initial requirement gathering stage, through building up personas of the customers, to the iterative design process and beyond. Until then we’ll have to make use of the wide range of apps covered today to achieve these tasks.

Related posts:

1. iPad Usability Study
2. The importance of usability in Mobile Geolocation games.
3. 7 aspects of successful usability questionnaires