Introducing Navflow

As some of you may know we have been hinting at something new over the last couple of weeks. Not a new feature or a redesign but an entirely new app, and today I am happy to announce that the fruit of our labour is launching under the moniker of navflow.

With navflow we believe we have created a novel approach to testing how people navigate websites and applications. The traditional approach to running usability tests of this nature has mostly involved the testing of live interfaces. While this is a perfectly valid means of gaining valuable user insight, implementing design changes can be prohibitively costly and difficult to implement once a website or application is live.

Our solution was to move testing into the design phase and give designers tools that allow them to run user analysis using mock ups and wire frames. This approach has proven to be very successful on with almost a thousand people participating in and creating tests every day. For navflow we wanted to take design phase testing even further and let designers see how users navigate their designs without needing to build them first. To that effect we have built a testing platform that takes a series of images and creates a conversion funnel from it. The designer is responsible for highlighting areas of the image that result in successful conversions and we allow successful clicks to proceed along the funnel.

Navflow is currently in beta and open to registrations, however new accounts will need to be activated in batches in order for us to stay on top of any bugs or other issues that may arise with a new launch. Bear in mind that this is a beta and so may still be a little rough around the edges, we will be working hard over the coming weeks to get everything up to scratch. We are eager to hear your thoughts so please send any bug reports, feedback or even praise to

And so with that, happy testing!

How game designers can help application developers : Part 2

Last week I discussed how application developers often forget to think about the user in ways that would seem farcical in game development. If you didn't read it, go back here first and have a read! This week, I'll go into more detail about how the lessons learned from developing games (or even playing them!) can help you create better web applications. There is a great presentation by Dan Saffer here which I think is well worth a read. He speaks in some more depth about some of the topics I will brush over here. The crux of the problem for application developers is that an application is developed with an end result in mind and the experience of how the user gets there is secondary. In game development the process is obviously the other way round. The objective in a game is generally secondary to the experience. Often a game has NO objective other than the experience itself. So, going back to my example from last week of an RTS with an impending onslaught of enemy forces. In a poorly developed game, it may be possible to build the structures and forces you need to fend off the enemy, but it may not be enjoyable. If a game isn't enjoyable no one will play it. In application development we all to often say, "yeah it may be clunky...but it works". Just "working" isn't acceptable any more, if it ever was. Your application needs to engage, excite and promote word of mouth. Particularly if you're a startup, and particularly if you don't have a big marketing team to get out there and spruik the value of your software. As discussed by Dan in his presentation, we need to focus on making the user happy. In particular we need to make sure we aren't requiring too much of our user's: a) time b) effort c) attention In our RTS if we require too much from the user of any one of these things, the game will cease to be enjoyable. Things which take too long to do, are too hard to do, or require too much focus aren't fun. This is as true for applications as it is for games. Whilst our application may never be "fun", it should at least be enjoyable. Is your app too time consuming? Think of how annoying games can be with long load times before every level. Think of how bad it looks when an in-game menu stalls before loading. Think of how frustrating it is when you need to perform an action in the game and you lose simply because the action took too long for the game to complete.
  • Look for interfaces which are used frequently, or systems that involve repetition.
  • Can you cut down on page reloads? Perhaps look at AJAX to load sections of data rather than reloading the entire page. If you're using .NET do your controls NEED to do a postback??
  • When asking the user to add multiple items can you get them to add them into a list and then hit enter instead of "click add - type - click ok, click add - type - click ok, click add - type - click ok".
  • If you're building a web app, make sure you're pages aren't huge! Make sure you load your JS and CSS files effeciently. Reduce image size where possible.
Does your app take too much effort? Think about how annoying games are which require you to open 3 menus to use a spell and have no assignable hotkeys. Think about games which make you walk back to town to sell items instead of just opening a portal. Does the game become too difficult to manage with many controllable units on the screen?
  • Look for cumbersome interfaces, or non-obvious controls.
  • If you use drag and drop or right-clicks, is it obvious to the user?
  • If the page loads a lot of data, does it become a hassle to use? Scrollbars, "next" and "prev" buttons all add to the effort required to complete a task.
  • Make sure your users only have to fill out data that they MUST fill out. Don't ask for information you don't need to complete the job.
  • Is your navigation easy to use? User's should be able to get anywhere within 1 or 2 clicks.
Does your application require too much attention? Think of a SIM game that presents the user with individual salary data for every SIM in the game when all we really want is the unemployment rate. Think of a game with 20 active quests but no way to see what they are. Think of an adventure game with no mini-map or that requires you to remember where your next objective is.
  • Your application should ideally only show information relevant to the task at hand.
  • Banner ads are evil (Animated ones in particular!). Is the money you make of them really worth distracting your user?
  • Are frequently used items more visible than the less frequently used ones?
  • Is it always clear what the user needs to do next, or do they need to guess?
Hopefully this will give you some food for thought when you design your next interface. Once you stop thinking about your application in a goal oriented way and start thinking in terms of the user experience, you'll already be on the way to designing better applications. This week we talked about how application interfaces can be improved by thinking like game developers. Next week we'll discuss making applications fun to use by bringing a little bit of game to your application!