Back in November last year I bought a Macbook Pro, and upgraded the ram via Crucial to 4Gb.  The machine never really ran properly, however: it always felt very sluggish when swapping between applications and even simple things like Dashboard or even accessing menu items resulted in the ‘spinning beachball of despair’ for a few seconds.  I tried everything – reinstalling OSX and all apps was the final straw, but even that didn’t cure things.  I really had no clue what was up, but a chance loan of a friend’s Macbook (with 2Gb ram) made me curious about whether I had some defective memory.  Inspired by how fast a contemporary Macbook was, and how sluggish my (theoretically faster) Macbook Pro was in comparison, I decided to dig out the original Apple ram, and re-installed it.

Bingo: instant zippiness.  For sure, there was something wrong with the Crucial ram.

So, this is where I want to thank Crucial for a totally no-fuss replacement.  They handled my warranty claim with great efficiency and professionalism.  I don’t know what the actual problem with the ram was (it had always tested fine in various hardware tests that I tried) but it was no longer my problem: a new pair of 2Gb chips arrived within a few days and since then the Macbook Pro has got its mojo back!

On the subject of Apple, I’d like to take a pop at the Finder.  How is it that, in 2010, following ten years of iterative enhancement to OSX, we are still saddled with a buggy and inconsistently designed file manager.  The Finder, quite frankly, is the elephant in the room where the Apple system is concerned.  It’s prone to crashing when accessing SMB based network shares and when it goes, you’ve often no choice but to power down (software restarts frequently don’t work).  This is not a good thing in an otherwise class-leading operating system.  I simply don’t get why Apple don’t look to what’s going on in the third party file manager market and learn a few lessons.

Case point: Path Finder, an affordable and really well put together file manager, offers so much more, with tabs, a drop-stack and loads of useful features.  Ordinarily, I prefer to stick with the supplied ‘core’ applications, but I thoroughly recommend any Mac user to try to minimise their use of the ‘Flaky Finder’ and give Path Finder a try.  No ties to Cocoatech, who make the app, apart from being a very satisfied (paid up) customer.  Go try it!

It’s a tough industry at the best of times, but sometimes we make it tougher by simply aiming to do too much.  We put our heads together around our funky meeting tables and let rip, resulting in huge, complex lists of possible features and requirements.

The sad truth is, though, that we’re not always that great at getting the basics right.  In fact, scrub that, we don’t even know what the basics are.  Why?  Because in our rush to please, we forgot to really work with our users to identify what they really need.  We thought we knew best, and acted accordingly.

Wrong.

In the world of the micro ISV, there’s a strong trend toward keeping things simple and offering limited feature sets which work and serve the majority of users, rather than extended ones which aim to please everyone.  We call this ‘minimal viable product’ (MVP) and in essence it’s all about getting to market quickly at a minimal cost and maximum return on that cost.  It’s typically geared toward getting the first version of a product out there to effectively ‘test’ a marketplace.  And it works.  Rather than commit huge budgets toward building every little feature, a company can save time and money and concentrate on fine-tuning a product and its positioning within a specific market.

So, how does this fit into the software prototyping ecosystem?

That’s an easy one.  MVP is as viable an approach to test the acceptance and suitabililty of a prototyped solution design within an organisation as it is to a commercial product out in the big bad world.  The same rules apply; designers can focus their efforts on creating smaller, simpler prototypes to stimulate discussion with end users.  ‘Edge-case’ functionality is conveniently out of scope, and everyone turns their attention to the core, minimum feature set.  When this happens, we spend much more time really working out how those core features should work.  We quickly identify those features that users need the most.  Need, not want.

In conventional MVP, there is an emphasis on measuring what users do when they use a system.  The real power of MVP is collecting and interpreting this data and feeding it back into the refinement of the system’s design.  Sound familiar?  Of course – it’s simply an ‘in-the-field’ version of what we use software prototypes for: gathering contextual information about what works and what doesn’t before committing to particular aspects of a design.

MVP is, in a way, both a compliment and an alternative to conventional software prototyping – both have their uses and there’s a strong argument to think of MVP as simply ‘live prototyping’.  Either approach can deliver real benefits by saving time and avoiding unnecessary design of flawed or non-viable features.

The problem is that too few people really put in enough effort up-front, which results in significantly higher risks further down the line.  Take, for example, the developer who dives into code before really understanding the requirements.  Perhaps those requirements aren’t immediately obvious.  Maybe there’s disagreement over what needs to be done.  Nevertheless, our intrepid developer wants to “make a start“.  Bad move.

Just like building a house, we need to have some baseline guidelines about what we’re going to do.  A builder won’t start work before he knows what kind of a house he has to build.  A four storey mansion requires a totally different approach to planning compared to a bungalow.  Yet, in software, we’re frequently at the beck and call of clueless management who pressurise developers into starting work without even draft requirements.

You’d think that in this day and age this would be the exception, but you’d be wrong.  I was recently involved in the development phase of a large and complex financial data collection system, whose delivery date was decided before anyone had any concept of the scope or what would be involved.  Worse, the necessarily unrealistic schedule depended upon having workable specs available in good time.  Guess what?  The development was almost complete before the merest hint of requirements documentation materialised.  And it was, basically useless when it did arrive, being as it was incomplete, full of errors and false assumptions.  Remember, kids, bad requirements can be as damaging as no requirements at all…

Despite this, we’d had to press on because the management – or should I say lack of management – had clearly no interest in letting its responsibility to manage the project get in the way of those juicy meetings.  Mmmmm… donuts!  So, not only had we useless requirements delivered way too late, we had absentee management of the very worst kind.

Ultimately, today’s article isn’t really meant to be a gripe.  After all, anyone who has been in this game for any length of time will have similar tales to tell.  What I did want to stress was that we, as the hopefully ‘enlightened’ techies, invariably have no choice but to take on the responsibility of pushing through requirements and kicking back against incompetent management.

If we don’t do it, we can’t really expect anyone else to do it.  Sure, it’s nice when it happens as it ought to, but don’t count on it…

[If you don’t already use one, it’s a good time to think about subscribing to this blog using our RSS feed and a suitable reader]

That’s not all, though: not only are people expecting more, they’re also far less willing to put up with anything which doesn’t quite measure up, anything which requires too much effort to use.  The sheer vastness of choice out there on t’interweb, combined with the increasing competition for limited attention means that the modern software designer must really make his software stand out in a good way.  As Seth Godin puts it, it must be remarkable.

So, more than ever before, there is considerable pressure to ensure that designs are right from the off.  No longer can we, as software people, get away with poor usability or inconsistent functionality.  If we try, our customers will move on to our competitors’ offerings, and we will fail.

In recent times there has been an explosion of powerful and relatively affordable tools and utilities to help us get our designs right before launch.  Balsamiq Mockups is one such tool.

Balsamiq wants to stake its claim on the part of design which would traditionally be performed using paper wireframes or sketches.  It doesn’t aim to facilitate rich prototypes, and indeed takes a bold choice to avoid offering simulations of the ‘look and feel’ of modern operating systems or browsers.

Balsamiq Mockups - something I created in less than 3 minutes

I’ve written before about the dangers of creating high-fidelity, rich prototypes with close approximations to ‘real life’ – that is, the dangers inherent in getting caught up in a vicious cycle of nit-picking over element positioning, colour schemes and specific behaviours.  It’s not that these things don’t have a place, it’s just that it’s often difficult to educate our business stakeholders and users as to what is and isn’t important.  After all, if you commissioned an architect to design your dream home, she would give you a funny look if you started obsessing over the texture of the wallpaper before you’d decided on the number of rooms.  And so it is, and must be with software design.  Sketch the outlines early, get them right, and add the specific details – the eyebrows if you will – until later.

Balsamiq is a drag and drop-based tool which is available for PC, Mac and Linux machines running the Adobe AIR system.  This means that it is a truly cross-platform application, albeit swaddled in the AIR plug-in.  This raises one small stumbling block for anyone running in a large corporate environment – you know the type, where each machine is locked down tighter than Fort Knox.  In such environments, it’s common that Flash is unavailable or restricted to an archaic version, and AIR support is extremely unlikely unless you’re the system administrator and willing to install it in secret…

There really isn’t much to say about the use of Balsamiq that can’t be figured out in a matter of a few minutes of trying things out.  A panel contains a selection of screen elements, rendered in a sketch-like style, which can be dragged onto a larger pane which represents the prototype or mockup.  These elements can be resized or customised to suit, and once you’re happy with your arrangement, multiple elements can be ‘grouped’, or locked in place relative to each other.

You can easily annotate your mockups

Of course, as mentioned above, the point of Balsamiq is to allow the user to create low-fidelity wireframe mockups very quickly, so as to sketch out basic layouts and conceptual designs so that they can be discussed, improved or rejected.  One notable feature which I particularly liked was the presenter view, which allows a mockup to be viewed full screen, complete with a rather nifty pointer which makes it a breeze to highlight particular bits of the design when discussing it.  It’s also great fun to use, and that’s always a plus point!

Rather than try to explain the process, I thought a very quick (and not very exciting, I admit) screencast might be worthwhile:

At this point, I have to add that in modern software development, teams are often co-located in different places and this is one place where Balsamiq shows great promise but also could go further: collaborative design.  I’d like to see a version which perhaps incorporates cloud hosting, version control and perhaps rudimentary task management (so as to have a number of people collaborating on a variety of mockups).  This would certainly suit larger projects, in which a number of different parts of a system are to be prototyped.  From experience, without some structure to organise who is doing what and at what stage, it can quickly descend into a kind of chaotic mess.  So, that’s one area where Balsamiq could find a niche into the enterprise.  Update: a cloud-based version, Balsamiq Mockups Online, is planned for release this summer – get the low-down here.

For the smaller project Balsamiq is ideal for helping structure ideas into something a little less scrappy and a bit more useful.  Depending on the nature of the project, Balsamiq can be used to create the initial design which (if required) can then be ported into a more fully-featured interactive prototyping tool such as Axure RP Pro, or simply used as the blueprint for the development phase to work from.

I would say that Balsamiq is a real success because it doesn’t attempt to let you model interaction or use-cases.  By limiting the feature set to wireframe design, it allows the user to focus on the broader-stroke design issues without getting bogged down in details.  If I can be a little bit critical, it’s almost too spartan in its feature-set; it would be great if Balsamiq offered some kind of hierarchy support, so as to allow the user to build a mock site which could show paths through a larger system.  Sometimes this is necessary to really ‘get inside’ a conceptual design and work it through, but as things currently stand, there isn’t support for this beyond rudimentary hyperlinking.  It would also have been nice to be able to create my own library of element groupings, but it could be argued that that would open the door to creating ‘richer’ templates which in turn starts to distract the user with thoughts of aesthetics.  This feature is, however, in the pipeline.

Balsamiq is available as a trial version, but the full version is inexpensive and I strongly believe that, used appropriately, one can easily recover its purchase price quickly in terms of development cost savings and increased sales (when your design blows away your competitors’ offerings)!

So, with all that in mind, where does it take us UI designers?

The fundamental thing that it offers a very direct interaction between user and device.  More so than a mouse, which although familiar is still somewhat indirect.  Certainly more so than a keyboard, trackpad or stylus.  It’s also highly portable, but less ‘obvious’ than a sub-notebook.  It’s also not constrained by the conventional requirements of a desktop device – the impressive multi-touch screen allows elements to be sized using pinch movements, rotated and very easily organised in an extremely tactile way.

In normal UI design, it’s historically been quicker to sketch general ideas on paper or on a whiteboard, which allows the designer to provide immediate visual feedback to customers there and then.  However, it’s a bit limited and there is always a trade-off between speed and fidelity – the more detailed a design is, the longer it takes to draw.  Pretty obvious really.

Modern wireframing tools such as Balsamiq have tipped things in favour of doing this in software.  Drag and drop techniques, pre-defined element libraries and easy organisation of UI elements means that it is, for the first time, far quicker to use a software tool to work through a conceptual UI design ‘in the now’.  In other words, in the meeting, not several hours after the meeting.

The benefits of this are pretty profound: design feedback loops are shortened almost to the point of insignificance.  The designer can almost immediately reflect a page layout to a customer and try it out for size.  This incredible responsiveness means that it is dramatically quicker to reach a consensus on a basic UI design.  It’s also incredibly empowering: the customer really feels that their ideas are being incorporated right there, and this means that they buy-in to the design at the earliest opportunity.  We call this ‘adding magic‘.

So, given that such tools exist now, where does the iPad take us?  Well, it is once again a huge leap forward in terms of how easily one can interact with a software application.  The operation is intuitive – drag things around, anyone can do it.  With suitable software, a designer can create a prototype UI design right in front of the user, easily sizing or moving elements with instant visual feedback.  The customer can also take the iPad and ‘drive’.

All the while, with the benefits of modern ‘cloud’ based applications, these designs can be shared with team members wherever they happen to be.  And, with the 3G versions of the iPad, this fully immersive design dialogue could feasibly occur anywhere and at any time.  With dramatic speed and full customer buy-in.

Whether this really is a game changer for software prototyping remains to be seen; at the time of writing nobody has really created the ‘killer’ prototyping app for the iPad, but I am certain that it is only a matter of time.  It’s going to be an interesting time for the software designer!

It’s easy for me to sit here and preach about prototyping techniques but much harder to actually use those techniques.  There are lots of little questions to get out of the way first, including ‘what tools do we need to prototype’, and ‘when should we use them’.

The Prototyping Toolbox

The following things are basically the core of your toolbox.  You may have some of them already, whilst others might not immediately jump out as important but experience has shown them to be very useful indeed.

Hardware

• A notebook or laptop computer;
• A desktop machine with a decent sized display;
• A portable hand-held audio recording device.
  

  

Software

• A decent wireframing tool;
• An interactive prototyping tool;
• A graphics editor;
• A screen grabbing utility;
• A screen-cast capture utility;
• A decent word processor.

Services

• A network or web-hosted share;
• An incident/task tracking system;
• A version control system – either local or web-hosted.

These things form a core of useful tools that will enable you to capture requirements from users (taking notes on your notebook, recording users verbal feedback using either the screen-casting software and built-in laptop mic, or your hand-held recorder for meetings). If you’re anything like me, you’ll end up with print-outs containing screen grabs from your mockup screens; sticky notes can be useful to help organise these, or record feedback.

A fair amount of time will be spent talking with users and clients, and from those discussions many actions will arise.  A tracker system (for example, FogBugz) will enable you to capture, prioritise and track actions against design and prototyping activities.  This should be visible to the design and development team, management and ideally also to the customer and users, who should be able to submit feedback directly.

Once the design is underway, it’s always a good idea to start out with a light-weight wireframing tool so as to sketch ideas and basic layouts out without getting bogged down in the particulars of aesthetics and interaction.  There is plenty of time for that further down the way, when a more fully-featured prototyping system makes more sense.  After all, prototyping should be an iterative process and adding detail is time-consuming and best left until the major layout and navigational decisions are made.

Having mentioned that software prototyping is an iterative process, it follows that version control is important to consider.

Rather than rely on some arbitrary file-based versioning, why not explore one of the Subversion- or Git-based online versioning services?  Beanstalk is one that is well worth checking out.

Whilst not all prototyping systems offer sufficient file granularity or integration to support version control, it’s available in Axure RP Pro and likely to be added to other tools as systems become more complex and co-located design teams start to see the benefits that this brings in collaborative design.

Gaining feedback on your designs is of great importance.  This is generally best done with a demonstration where people are in the same room, but since that isn’t always possible, recording a guided demo using a screen-casting tool is a great way of

As a compliment to (rather than a replacement for) version control, it’s useful to have a shared network repository for the various documents, specifications, graphical resources and so forth that are created along the way.  DropBox offers a free 2Gb ‘cloud-hosted’ share which works beautifully for this purpose, using shared folders between users.  Did I mention that it’s free?  Go check it out!

Summary

This is just a short look at some of the tools that you might find useful for your software prototyping activities.  It’s far from comprehensive, of course, and there are alternative tools that can be used.  There are no hard and fast rules to what works and what doesn’t – heck, some people even use PowerPoint for prototyping.  Can you imagine?

If you’ve found any useful tools, or even techniques to help work more effectively, please do add a comment below.  Sometimes the ideal tool for your next task is just a recommendation away!

[If you don’t already use one, it’s a good time to think about subscribing to this blog using our RSS feed and a suitable reader]

Sure, we can do this by sending around written descriptions, or by putting together sets of screen-shots.  Neither of these methods really gives much of an impression of how a design feels to use and so this is where an interactive model or prototype really earns its keep.  We can get great feedback in a very short space of time and use that to shape and refine our design before costly development phases begin.

In an ideal world, we’d be able to get everyone around the computer and conduct a real hands-on feedback session.  However, in this age of distributed working it’s not always possible or even desirable to get everyone together.

This is why tools like the excellent iShowU HD Pro application can help.  In a nutshell, iShowU HD Pro is a sophisticated screen capture tool which runs on Mac OSX.  It offers a very slick and high performance way to record ‘guided demos’ of pretty much whatever you want, provided it’s running on your machine.

Whilst iShowU HD Pro isn’t the only software to do this sort of thing, it’s certainly one of the most effective and powerful. One of the neatest things it offers is great flexibility in how it handles larger screen resolutions; it’s possible to set it to either scale from a fixed point, or pan with the mouse pointer, and various other different behaviours.  Although at first this seems unnecessary, it means that it is quite easy to tailor the capture presentation to suit the requirements or limitations of its destination.  So, if you want to capture something at a lower resolution up to YouTube, then it’s easy – there’s even a number of pre-defined settings and resolutions to help.

Other great features include easy audio and even video capture (using the in-built iSight camera if you have one), so that you can include a ‘mini you’ in a corner, which can add a bit of personality to proceedings.  I found it best to reduce the size of the video overlay so that it didn’t interfere with the actual presentation too much, but since you can also change its position and even opacity you should be able to find a position to suit.

Nice touches, such as fine control over the format, frame-rate and size of the output, means that the generated files needn’t be huge, and therefore will stream well over the web.  I’d recommend anyone interested head on over to the iShowU HD video page to find out more, as they do a far better job in describing how this all works than I could.

Of course, this is all very well and good, but the purpose of this review is also to show where this can fit in with a remote workflow, especially where communicating designs is concerned.  Well, in itself it is simply a very handy and powerful way of recording what you are doing, but in combination with a cloud-based shared disk solution, such as that offered by DropBox, it can form part of a very powerful and surprisingly interactive way of communicating ideas and designs back and forth with a remote client.  In combination with a fast and quick-to-use wire-framing tool like Balsamiq and its superb presentation mode, it’s possible to create the next best thing to a guided demonstration, which can of course be watched again and again (apologies for the somewhat lacklustre demo

In software design, the threats are plentiful: bad management decisions, poorly defined requirements, bad technology choices, scope creep, regulatory change, personnel change, budget cuts, overpromising sales people, lack of time, lack of skill and so on…

As the ‘general’ you know that you cannoy possibly fight every threat all at the same time – you’d end up with many ‘overs’ – over-stretched, over-stressed and over-whelmed!

What’s important is to pick your battles – look for the areas in which small changes can deflect immediate threats.  Look for the ‘low hanging fruit’ – in other words, the things that you can influence now.

If your project doesn’t have clear requirements, work with the business to get some.  If your timescales appear unrealistic, take a step back and re-scope.  If your sales people over-promise, take the time to educate them as to what is and what isn’t achievable.

There will always be battles that you cannot really win – the much wider-ranging changes, such as changing regulation, competitors, the economy – and you need to accept that you can only roll with the punches, come what may.

By picking the battles that you can win, your development project will be better prepared to endure and possibly better placed to actually turn these threats into opportunities.

That way you won’t miss out on any of the various articles that eventually find their way onto this blog, such as:

• The power of small teams 
• Adding Magic 
• Guided demos 
• Pushing the Envelope 
• Save money: invest in a big display 
• Individual versus conforming design 
• The tragedy of Software Development 
• Distracted by shiny things 
• Reduce wasted effort

If you like anything you read – or even if you disagree and want to vent in my general direction – please do feel free to add comments!

Which is why it comes as no surprise to hear from so many of you who use it to put software prototypes together.

Perhaps this is preaching to the choir, but I strongly believe that PowerPoint is the wrong kind of tool to use for any prototyping.  It’s a little bit like using a hammer to affix screws to a cabinet; yes, you can if you really must, but you do so by sheer bloody-mindedness and end up fighting the tool, cursing a lot and inevitably compromising the end result.

The standard argument for using PowerPoint is that it’s there; in other words, most people will have it already installed on their machines.  You won’t, then, have to navigate the corporate bureaucracy to get some third-party software installed.  You’re making use of an existing tool which spits out a generally standard format that your customers can view without too much difficulty.  This is a fairly justifiable reason for PowerPoint prototyping, but consider the following:

PowerPoint was never designed with prototypes in mind.  In fact, it’s a downright lousy tool to use for this purpose.  It has neither the functionality to allow you to create effective interactive prototypes, the fidelity to facilitate precise visual prototypes, nor the ease of use and widgets available from a custom-designed prototyping tool.

All of this is well and good, but I didn’t write this post to knock Powerpoint.  In fact, if you want to do a presentation, it’s a competent tool (though trails Apple’s Keynote by a country mile).  My purpose today is to persuade you to make your life easier by selecting an appropriate tool, and in turn support the many smaller companies who offer such tools.

For many people, prototyping is about layout and general design; it’s sadly still the exception to get support to build fully interactive prototypes, which is a shame, but that’s life.  For layout and design, we’re really talking  wireframing, although a lot depends upon the stage your project is at.

Let’s get one thing straight: PowerPoint is useless for interactive prototyping.  If you wish to do this, use  Axure or a similar tool.  Yes, you’ll pay for it but you will save the purchase costs many times over if you use it effectively.  That means using Requirements Prototyping principles, and engaging with your users and stakeholders throughout the design and development stages.

Fortunately, most people who attempt interactive prototyping with PowerPoint quickly give up, so it’s fair to say that wireframing with PowerPoint is what we’re really looking at avoiding.  And this is where I must direct you toward Balsamiq, a superb and inexpensive wireframing tool which generates prototypes in an even-more-standard format – html.

I’m planning an in-depth review of Balsamiq in April, but it is worth considering some of the benefits a tool like this offers over PowerPoint:

1. It’s designed specifically for wireframing – no bloat;
2. It comes supplied with wireframing templates;
3. It’s drag and drop, without the pain;
4. Output in html means that everyone can view your prototype;
5. Speed – it’s an order-of-magnitude quicker to create a wireframe as compared to PowerPoint;
6. You’ll be giving support to a smaller company…
7. …which will in return offer superb customer service and support.

Crucially, you’ll be using a tool that was designed from the ground up to support the wireframing process.

As a parting note, I hope I can persuade some of you to push back against the PowerPoint hegemony and make prototyping the responsive process it ought to be.

I’d love to hear from anyone who wishes to defend PowerPoint, or perhaps tell us about how you pushed through the switch from PowerPoint to a dedicated tool.