Yesterday, Apple announced their long-rumoured and much speculated-upon iPad.  The world, it would seem, waited with bated breath for confirmation of the “Jesus Tablet“. 

What we got was a competent looking, stylish device that many have already deemed a disappointment and doomed to failure.  I wanted to try to down-play the physical iPad somewhat and think about its place in the society of the (very) near future.

The key to the iPad is to think of it as one would Quorn. 

If you don’t know Quorn, let me elaborate: Quorn is a mycoprotein-based food-stuff made from eligible fungus and high in protein.  Doesn’t sound too tasty, no?  But wait, there’s more.  It is healthy and forms the basis for an entire industry of vegan-compatible meals.  Everything from sausages to meatballs to scotch eggs, minced beef and chicken fillets.  Except they’re not.  Quorn is most commonly regarded as a substitute for these non-vegan/vegetarian foods, and favoured, shaped and marketed as such. 

However, as someone familiar with Quorn, I’ve personally found that when you treat it as a meat substitute, it is often found wanting.  I’m not vegetarian – I do enjoy the occasional piece of chicken or beef, and I know what they taste like.  I know the texture, I know the mouth-feel, I know the taste.  When I eat a Quorn ’substitute’ for any of these, I am only too aware of the differences.

My success with Quorn has been to treat it as its own category of food.  Work with its characteristic flavours and texture – don’t fight against them to make them into what they’re not.  If you do this, you end up appreciating Quorn for being its own thing; a versatile and healthy alternative, not a substitute.

So, thanks for bearing with me whilst I’ve seemingly lost the plot.  There is a point to this, and I’m getting there.  We were talking about the iPad and I was trying to give it a fair hearing.

I think the iPad should be treated in the same way – not as a substitute for anything, but more as a new device – and it should be thought of simply as a piece of a larger system, rather than as a device unto itself.  This is where it’s connectedness is key.  The iPad v1.0, then, is simply the first generation conduit into a wider ecosystem of premium content.  iTunes for the publishing industry, if you will. 

Something which finally facilitates a workable model for book and magazine publishers to really exploit the possibility of paid content.  Sure, Amazon has its Kindle and a pedigree in online publishing retail (not to mention the beginnings of an e-book empire) but this is limited by the Kindle reader itself.  A fine device, it sadly falls short of providing an interactive, ‘added value’ reading experience – a void which Apple is keen to fill.

How Apple will achieve this will be down to its clout, established and new business agreements and the fact that it has made a (huge) success of doing the same within the music industry, perhaps even saving said industry along the way.  The traditional publishing ecosystem will be looking to Apple as some sort of savior, a means to finally offsetting the decline of conventional publishing with a new emergent marketplace. 

Perhaps nobody else can do this – who knows?

So, whilst the masses may quibble about little things such as the size of the device, or the lack of this or that, the key here is how this ‘first attempt’ device will place the final link in the chain of a truly viable premium content publishing model.  I believe the initial iPads are largely irrelevant in the grand scheme, much as were the original iPods.

The next few months will be interesting times!

Thought for the day:

If a picture paints a thousand words, think how many words you can save by creating an interactive prototype of your next software development. Think of how much easier it will be for people to understand what it is that you’ll be creating. Think of how the process of creating and demonstrating your prototype will highlight shortcomings in your design. Think of how much misunderstanding you will avoid, and how that will help your actual development set off on the right path. Think of the how much time will be saved by not building that feature that your users really don’t want. Think how much time will be saved by not missing that key feature that your users really do want.

Many people view software prototyping as something that’s only really worthwhile on larger projects. This couldn’t be further from the truth: prototyping brings benefits to almost any non-trivial software development.

This blog likes to talk about ways to improve your chances of delivering a successful software project.  One of our mantras is the use of software prototyping, but a recent conversation got me questioning whether building a software prototype might end up creating its own problems.

“Whoa!” I hear you cry.  Take a second to pick yourself up the floor; calling prototyping a liability on a site hosted at softwareprototyping.net might seem like a rather chilly day in hell.  And you’d probably be right, but I try to present the upsides and the downsides with a (relatively) impartial hat on.  Or at least that’s the plan.

So, software prototyping creating its own problems?  Surely some mistake?

Well, to answer the question: generally, no, software prototyping is usually a highly effective way of steering the early stages of a software project, therefore increasing your chances of success. 

However, if we widen our brief and consider requirements prototyping – i.e. the use of prototyping techniques as a core part of the analysis and specification of a new system – we hit across a small problem.

This is illustrated best with the story of Jeff*, at the time a divisional director in a large financial organisation. 

I was involved in the design of a considerably wide-scoped prototype.
Using the techniques of requirements prototyping, I was able to bring in feedback from users, stakeholders and technical analysts to help shape the design.  This was going rather well; hard work but with each revision showing real progress towards a killer design.  Along the way, however, Jeff started to sniff around in an example of classic hit-and-run micromanagement. 

Despite concentrating on building up the shape of user journeys, exploring the effectiveness of our interface and so forth, Jeff really wanted us to devote our time to ‘making it look just fantastic‘.  Which, unfortunately, involved endless fiddly adjustment to such things as the precise placement of fields, the exact colour of text, whether this image looked professional enough and so on.  All very interesting, but somewhat missing the point of the prototyping process.  All this served to do was divert significant time and effort into polishing the finest details of a prototype whose main purpose lay elsewhere.

On reflection, and in Jeff’s defence, it was pretty clear that he believed in making everything look as slick and professional as possible.  He knew that the project could gain support from his superiors only if the prototype gave the illusion of completeness, and so in a way he was right to push for consistency and professionalism in the appearance. 

Our failing (as a project) was in letting him do this at far too early a stage.  After all, we hadn’t decided if we were going with User Details Capture Journey A, B, C or D at that point, so polishing them all to a high gloss was always going to be overkill.

What I learned from this was that the production of any tangible output – be it a paper design or a full interactive prototype – invites attention from those who don’t understand its role, its place.  Even though they may be senior, important people, they may not be important to the project itself. 

Sometimes, these people get distracted by shiny things, colours, minor details.  This isn’t a problem if they remain as observers or on the fringes of the project, but can be a serious risk if they attempt to push their way into the proceedings.  As prototyping practitioners, such people really slow down the responsiveness of the prototyping process and dilute the benefits of prototyping.  In other words, these people cause more harm than good. 

The skill is recognising these people and finding a way to either educate them to the purpose of the prototype or reducing their involvement/exposure to the team.  If they really must have their fully polished, ’slick’ design ideas visualised, then at least explain to them that it simply isn’t realistic to do this over the entire prototype.  Offer to ‘polish’ up a portion of the prototype once the fundamentals are stable.  In other words, don’t wallpaper the living room until you’ve finished building the walls…

As a final word, don’t take this article as a negative reflection on the use of software prototyping techniques – there are far more benefits than drawbacks…

* name changed to save on blushes and prospective lawsuits…

Here are some links to other articles which might be of some interest if you want to know when software prototyping is appropriate:

• When not to prototype
• Before you begin prototyping

And then one day you find
 ten years have got behind you
 No one told you when to run,
 you missed the starting gun
  - Pink Floyd, “Time“

Once again, another year ‘gets behind us’ and another presents a new set of challenges and opportunities.  I’m fairly sure that Roger and the boys didn’t exactly have effective software project delivery in mind when they penned those immortal lyrics, but the sentiment rings true in this field as in many: time passes. 

I don’t mean to be negative, though: whatever your history of software project delivery, that’s in the past, history, done.  The present and the future are the only things you can change, so why not take a critical view of your software development processes and resolve to do things in a smarter way?  Perhaps your change process is a bit flaky, or scope creeps uncontrolled into unknown places.  Whatever your situation, I strongly recommend making a conscious decision to try something new – and software requirements prototyping is one such technique which might make all the difference…

Make 2010 your year of effective delivery.

If you’ve reading this, there’s a fair chance that you’re involved in the software design and/or development business.  Maybe you’ve read some of the many articles on this site which promote the use of prototyping techniques as a way to deliver projects more successfully, but despite this you’re not yet convinced.  We’ve led you to water, so to speak, but cannot force you to drink…

Well, why not resolve to actually try these techniques on a smaller project in the new year?  Perhaps try the use of prototyping techniques and direct stakeholder and user engagement.  I’m willing to wager that you’ll find it at the very least a stimulating and energising experience, and it might just help you deliver software projects in a more organised and effective manner.

All you have to do is to approach this with an open mind, and give it a chance. 

You shouldn’t just take my word for it – give it a go, and get in touch; I’d love to hear of your experiences (good and bad)!

Have a fantastic Hogmanay and New Year – best wishes for a prosperous 2010!

Did you know that less than a third of all software projects are delivered successfully?  By that, I mean on time, within budget and meeting the requirements of the users?  It’s not a great statistic at all.  As an industry we ought to be somewhat ashamed by this. 

The really sad thing about it, however, is the extent to which the remaining two thirds – those projects which fail - might have been avoided.  It’s pretty clear to see that a significant proportion of these failing projects fail for the same reasons, time after time:

• Inadequate Requirements;
• Poor Estimation;
• Low Stakeholder Engagement.

Of course, within each category the usual suspects crop up: lack of understanding of the context of a system, poor communication, scope creep, lack of organisation, corporate bureaucracy, and so on and so forth.  All of these things are common to almost any software project, so an outsider would be forgiven for wondering just why we don’t learn from our mistakes and do something smart to help reduce their impact.

That smart thing, of course, is the process of Requirements Prototyping.  Which is, as you will probably know by now if you follow this blog, the process of creating interactive models of designs and using them to solicit constructive feedback from business stakeholders, users and basically anyone who needs to have a say in the outcome of a project.  Sure, there’s more to it than that, but in essence it is not overly complicated and the benefits in operating this way outweigh the additional costs – significantly, in the case of larger projects.

So, it’s a real tragedy that doing this smart thing is still so rare in modern software developments.  Many companies might toy with the idea of building a prototyping in a half-hearted way, getting too bogged down in the stylistics without really using it as a powerful medium for evaluating designs, facilitating change and clarifying requirements.  Like driving a sports car in a traffic jam, it’s a waste of the potential and a real shame.  To get the real benefit – to get out of first gear, if you will – is to use a software prototype as a living, breathing specification and actively evaluate and refine it, involving all stakeholders.

If you do this, you will certainly increase your chances of finding yourself in that 1/3 of projects which are delivered successfully. 

To pass up the opportunity would be a real tragedy indeed.

A few weeks ago, I wrote the first in a series of short articles about who needs to be involved in the software design process if it’s to have an increased chance of succeeding.  We covered involving users then, but they are only part of the overall picture.

This article looks at the stakeholders – those people who have vested interests in the success of the project. 

To them, they may have been given the responsibility to see a project through to delivery and beyond; they may be in charge of teams of users and therefore their own productivity and effectiveness is impacted by that of those users.  Get it wrong, and their bottom line is threatened.  Understandably, they’ll want to get involved and keep an eye on the progress of the project.

In today’s troubled financial climate, you can guarantee that stakeholders’ bosses will be keeping a close eye on things too; the decision to proceed with a new software project is often made from fairly senior levels.  Support from senior execs doesn’t grow on trees, so when you do get it, you can’t take it for granted.  They’ll expect something in return, and that price is invariably success. 

Stakeholder management is, of course, a science and an art unto itself, so I won’t cover that here, but it’s worth taking the time to scope where their individual priorities lie.  Some will be looking for a direct impact – software that enables their team to do better, say – and others will look to gains by association with a successful project.  Some may have competing priorities, or hidden agendas, and it’s certainly no bad idea to tread cautiously when involving these people.  Even if all is well, there is always a real danger of ‘too many cooks spoiling the broth’.

One project I worked on suffered from just this problem.  It was a large-scale system-integration which aimed to provide a consistent interface to a number of systems both old and new.  That in itself was fine and a challenge to relish.  However, every system within scope (and a few out of scope) came with its own set of stakeholders, many of whom would try to force their ideas upon the overall design without necessarily considering its impact to the others.  A difficult thing to manage, but software requirements prototyping helped by giving the freedom to build quick mock-ups to test ideas out and influence the stakeholders to reject the occasionally inconsistent, flawed or even wacky suggestion.

This said, stakeholders hold responsibility and accountability within the project, and they will want to be involved.  Do so, and they will provide domain and contextual knowledge which would be difficult to obtain any other way.  They will also invariably be involved in the eventual sign-off of any design, so by involving them throughout the design process, they will already have a better understanding of, and buy-in to, the eventual design.

In Requirements Prototyping, when a designer creates an initial prototype design for a customer, it becomes the starting point for a cycle of evaluations and feedback sessions.  These sessions can (and should) involve both the users who will work with the final system, and project stakeholders.  Though not necessarily at the same time.

What I’d like to touch on is this little dance of ‘build a design:evaluate’ – in many ways it’s one of the most fundamental cogs in the wholeprocess of requirements prototyping-led software projects.  We need to get it right and understand it so that it delivers real value.

In an ideal world of infinite resources and time, we would repeat this little dance as often as it takes until we had the perfect design.

However, this utopian world just doesn’t exist so we need to consider how to organise our evaluations so that we can get as much out of them as possible.  We need to think about the actual organisatinal cost of getting people together for feedback sessions, and make sure that we don’t just include everyone for the sake of it.

Jakob Nielsen has suggested that five is an optimal number for testing a design.  His arguments are that the majority of usability concerns are identified by the first few participants, and thereafter most new participants tend to repeat observations with the odd exception.  His suggestion is that, rather than blow the entire budget in getting everybody to test a design in one phase, it is better to have a number of smaller test phases and an iterative refinement of that design between them.  This is precisely what we should be doing when running feedback sessions with users.

What’s different about feedback sessions as opposed to Nielsen’s usability testing is the fact that feedback sessions are generally:

• Collaborative: we’re not looking for individual isolated reports, but engaging discussion about the general design;
• Objective-led: we’re not specifically testing the usability of a design, rather its suitability to meet the objectives set out at the outset;
• Cross-disciplinary: not restricted of any one type of person, feedback sessions are most usually composed of a cross-section of interested parties, including users and business stakeholders.

The objective is different as well – usability being, well, about how usable a design is, as compared to general feedback which aims to help steer and shape the direction of an ongoing design effort.  Different beasts.

That said, restricting any feedback group to a smaller number of participants helps with focus and coordination, and it’s also much easier to find a time to get everyone together and a place to meet when the group is a fraction of the size.

So, a recommendation here is to keep the numbers low – perhaps with a representative from each section of the project: sponsor, business domain expert, designer, manager, user.  Ensure that everyone actually understands what it’s all about and is willing to make an effort to be there; there’s absolutely no point in forcing someone to get involved in this process against their wishes.

Each feedback session should set out with the stated objectives and try to assess the latest design proposal or prototype against those objectives.

Previous efforts should be used as yardsticks to gauge progress and to ensure that things don’t end up moving away from what’s required.  Nominate a chair for these sessions, someone who will be responsible for maintaining control and ensuring that the session is focused and organised.

What we need to get out of each session is a clear picture of how well the latest design meets the objectives, and whether further refinement is required.  It’s about proving the suitability of a design from different perspectives.  It’s also a good progress indicator, something which can be fed back into the project plan.

The next thing is to try to ensure that these feedback sessions are reasonably regular – say, once every other day or once a week – whatever works for the project.  Of course, how often depends on how much design change is going on, and it’s reasonable to expect the amount of that change to decrease as the design firms up.

In the next instalment we’ll look at what constitutes a good feedback session, how best to organise it, what outputs to expect from it and how to feed those into the next iteration and into a project plan.

Have you ever seen a website whose interface is ‘way out there’?  Of course you have – there are many.  Sites where, for better or worse, the designer has chosen to make her own path rather than follow a tried and tested design.

Individual design is a highly creative discipline; it forces the designer to think about every little detail, how those details fit together and how they combine as a whole.  It allows the designer to express personality, demonstrate their technical and aesthetic capability, and challenge accepted norms.  To be brief, it’s something of a clean sheet with all the possibilities that this brings.

Conformity is the contrasting approach; it’s more constrained, conforming to established rules, guidelines, accepted practice, you name it.  It prescribes ways of doing things and in practice frees the designer from the tyranny of that ‘clean sheet’ which can be daunting.

Neither approach is ‘all-or-nothing’; the designer will find a balance that suits their own preference, experience and abilities, tempered by the requirements of the customer.  We’d like to consider some benefits and drawbacks of either approach.

First of all, let’s consider conformity.  The driving force behind conformity (in a software design context) is to take advantage of the hard-won experience of those who have gone before.  Over time, a solid body of accepted practice has built up, shaped by the lessons learnt about what works and what doesn’t.  There’s a good reason that things are the way they are.

In conventional software development, for example for Windows forms-based applications, a great deal of the hard-work is already done.  There are standard form styles, controls, menu conventions, buttons and so on.  A user, having never seen SomeCompany’s new ThingyApp tool, will at least be presented with something which has a basic familiarity.  A conforming design will behave in much the same way as other applications.  The minimise button will be where it always is; there will be a File menu, perhaps a tool-bar, et cetera.

What we as designers gain from this is a greater consistency with the ecosystem of other applications.  We also benefit from the re-use of common components and frameworks, which are probably more stable and better tested than anything we could come up with ourselves, if truth be told.  A common UI is, then, a starter-for-ten which enables us to concentrate on the functionality without getting bogged down too much in how we’re going to let you control that functionality.

The drawback to conformity is of course that everything tends towards… well, bleh.  ‘Bleh?’ I hear you say?  Unashamedly non-technical, it’s our instinctive reaction to the ordinary, the familiar, the taken-for-granted – dare I say it, the dull.

If you want to make a big impression with your software, it has to stand-out in a good way.  Maybe this can be achieved by solving some hitherto difficult task, or by improving radically on something that already exists, or perhaps by doing things in a novel way.

Individual design tends towards this ‘doing things in a novel way’ approach.  Rather than be constrained with the common UI, the designer can really go to town on a design.  No longer bound by convention, then, the outcome is completely at the hands of the designer.

And this is where it typically falls down.

You see, many designers want to express their individuality into their designs.  Especially in web development (whose actual content doesn’t have a common UI as such, beyond standard html controls and the typical page lifecycle).  Flash has a lot to answer for here.  Many potentially great website ideas have been compromised by the use of bad Flash design.  Slow, confusing, overly graphical and exclusive (in the sense that they exclude people who might have no choice but to surf using assistive technology, for example the Jaws screen-reader).

The difficulty is that deviating from well-worn path of convention is a real risk to the usability and accessibility of a design.  Whilst it’s possible that a designer might come up with something which improves upon convention, it’s far more likely that what is designed will fail.  A radical design may well please a small proportion of its user-base, but by messing with the accepted norms, it will doubtless alienate or at best confuse a significant number of its users also.

So, where does this leave us?  Well, the point of this article was to weigh up ‘individual’ versus ‘conforming’ designs, and the short answer is that we can’t really rule on either.  After all, designs exist for a reason, and that reason is to facilitate the use of the thing for which the design was created.  An individual design may well achieve this goal better than a conforming design – we can’t really judge this on a hypothetical basis.  What we can do, however, is look at human nature and suggest that anything which challenges our understanding of how to interact with a system, or forces us to leave our ‘comfort zone’, is likely to require greater effort than a design which plays to our existing understanding and experience in interacting with a system.  Where greater effort is required, we are more likely to make mistakes.  With mistakes come frustration, and frustration quickly turns into dislike and abandonment.

The designer should bear all of this in mind before she departs from the ‘standard designs’, and have good reason for doing so.  If she does take this route, then it places a far greater responsibility on her to ensure that her design works, and justifies its ‘individual’ nature.  There are many techniques which might be used to do this – requirements prototyping being one of the best choices – but at the end of the day a radical design is a challenging proposition and carries increased risk.

We don’t like unnecessary risk.  We can either mitigate it, with careful feedback using prototypes, or avoid it, by sticking to tried-and-tested ‘conforming’ designs.  What we mustn’t do, however, is bury our heads in the sand and hope it all works out…

Sometimes a design will arrive for an everyday item that’s so blindingly obvious yet revolutionary you have to wonder why nobody did it before.

Such a design is the folding plug, designed by Min-kyu Choi.

Taking inspiration from the Apple Macbook Air, which is advertised as being the ‘world’s thinnest laptop’, Min-kyu found irony in the fact that this wonder of modern design was saddled with the rather archaic and clunky UK three-pin plug:

In a breathtakingly simple but inspired design, Min-kyu has created a clever folding plug which occupies under 1/3 of the space of a conventional UK plug.  Thinner than your little finger when folded, this beautiful bit of design refactoring takes plug design forward in leaps and bounds:

As software designers, we should be actively seeking out the ‘chunky plugs’ in our world – awkward, unfriendly, approaches to interaction that have somehow become the ‘norm’.  These are the things that people put up with despite their shortcomings.  If we put the effort in, we shall and will find them.  We may even be able to come up with something significantly better.

Min-kyu deserves great credit and recognition for making such an improvement to an everyday object.  I hope that you can find your own ‘chunky plug’ and make your own mark.  After all, that’s the essence of good design – improving our everyday lives.