Archive for the ‘Good Design’ Category

Older Entries »
h1

Credit to Crucial and a rant about the OSX Finder

June 28, 2010

A bit of a departure, but given my temporary World Cup induced break I thought I’d try to remember to give a little bit of credit where it was due.

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!

Posted in Good Design, Software Review | Tagged , , , , , , , | Leave a Comment »

h1

Prototyping and Minimal Viable Product

June 9, 2010

Historically, the software industry has been plagued by spectacular failures: massive enterprise developments which fail to meet even the most basic requirements; applications whose feature sets are over-complex and confusing; web portals promising the earth but delivering very little – the list goes on and on.  Countless budgets have been swallowed in the pursuit of the ‘next big thing’, the ‘killer app’ which will change everything.

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.

Posted in General Business, Good Design, Prototyping | Tagged , , , , , , , , | 1 Comment »

h1

iPad: the software prototyping game changer?

April 26, 2010

Unless you’ve been camping solo in Outer Mongolia for a few months, you can’t have failed to have heard about the new Apple iPad.  Though to my shame I haven’t yet managed to get my grubby paws on one, I’ve thought a fair bit about what it represents and where it fits.  To wit, it’s a compelling alternative to, rather than evolution of, the portable computing device.

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!

Posted in Good Design, Prototyping | Tagged , , , , , , , | 1 Comment »

h1

Review: iShowU HD Pro

April 5, 2010

Creating great software designs is a tricky process.  To do it well, you need to keep a whole lot of different people happy: the stakeholder, the end-user, perhaps a steering committee and almost certainly your own project team. We need to involve each group at various points along the way, checking our design ideas against their needs, expectations and preferences.

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 :-)

Posted in Good Design, Prototyping, Software Review | Tagged , , , , , , , , | Leave a Comment »

h1

Pick your battles…

March 24, 2010

Designing software is a bit like fighting a war.  There are battles on many fronts, and as the ‘general’ of your army, it’s important to direct your ‘troops’ where they will have the greatest impact, without leaving a gaping hole in your defences through which the enemy can pass.

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.

Posted in General Business, Good Design | Tagged , , , , , , | 2 Comments »

h1

Wireframe or Interactive Prototype?

March 6, 2010

We often talk about wireframe prototyping and rich, interactive prototyping, which are both powerful techniques for getting conceptual designs into a form that can be explored and expanded.

Where to actually use either approach, though, is something that would benefit from covering off here; a recent email from a reader reminded me that I’d promised to give some tips a while back and so, without further ado, here we go…

Wireframes

Leaving sketches and paper-prototypes to one side, Wireframe prototypes are the quickest way to explore a visual concept.

Wireframe teddy bear

Wireframes are a little bit like the plans for a house; they represent the outlines without getting hung up on the actual implementation.  It’s about deciding on the layout of a floor, if you will, without getting concerned with the colour of the carpet.

By limiting ourselves to essentially static designs, we have to gloss over a lot of the implementation detail.  We won’t attempt to model how a dynamic panel works, or the validation on an order form.  We will, however, be able to quickly create visual representations of designs for forms and pages with a minimum of fuss.  We’ll be able to do it quickly, and because our tools don’t attempt to let us do anything particularly complicated (such as navigating between wireframe ‘pages’), we won’t get distracted as much and can focus on our designs.

Wireframes, then, are ideal for the earlier stages of requirements prototyping, when there are layouts and ‘broad-stroke’ design choices to be explored.

Wireframes are suitable for:

  1. Deciding on what things should be included in a page;
  2. Investigating where things should be placed on a page;
  3. Creating low-fidelity mock-ups to help build the ‘skeleton’ of an application without investing too much time;
  4. Comparing and contrasting different layouts;

…and so forth.

What Wireframing doesn’t do so well is allow modelling of paths through a system, or interaction, or the finer detail of design.

Interactive (Rich) Prototyping

Rich prototypes are more commonly used once the basic decisions about a design have been made.  In other words, by the time we switch to rich prototyping, we generally know how many pages, and roughly what will be on each page.  We may not know how the various parts of a page will work, nor how individual pages will inter-relate with other pages, but the basic shape of a design is there.

Prototype car of the future

The move to rich prototyping is borne of a need to explore the specific implementation of designs.  In other words, modelling how functionality works, rather than simply glossing over such detail.  A good example for a rich prototype would be building a tabbed dialog so that clicks on tabs change the content, showing the tab state change and effectively simulating a real tabbed dialog.

Rich prototyping takes a proportionately longer time to do than Wireframe prototype development, due to the need to provide additional detail, interaction with forms, navigation and even simulated data.  Rich prototyping also varies in its complexity – it’s possible to create incredibly rich and accurate simulations of key pages, whilst building lower-fidelity versions of less important pages.  This allows the designer to prioritise her efforts to ensure that maximum value is extracted from the creation of prototypes with regard to ironing out any design gremlins.

Rich prototypes are suitable for:

1) Exploring the finer design details once the basic shape is in place;
2) Providing a realistic ‘finished system’ experience to allow users to get a chance to try out the complexities of a design ahead of the development phase;
3) Really ‘getting inside’ a design of key pages to ensure that a design really does work.

The drawback of rich prototyping is generally in the time it takes to do, and the need to use (often expensive) software.

A combined approach

The purpose of this article was to give a few reasons why a designer might choose a wireframe or a rich prototype approach.  However, the best approach is generally to mix and match as suits the needs of the project.

Crazy prototype gadget

For instance, work with the business to mould the basic shape of a system using wireframing techniques, comparing alternative layouts or page compositions, without worrying too much about how it looks and the finer detail of how each page will work.  Once the major layout and composition detail is stable, select parts of the design which might be either fundamentally important to the success of a design (e.g. a registration process) or involve a slightly unusual layout or functionality.  These are the things that can then be modelled in a rich prototype, and examined in more detail – perhaps by using them as the basis for user feedback sessions.

Whichever method you use, be assured that just by adopting requirements prototyping techniques into your project, you are dramatically increasing your project’s chances of success!

Posted in Good Design, Prototyping | Tagged , , , , , , , | 2 Comments »

h1

Guided demos…

February 27, 2010

Effective software design isn’t just about designing a thing and then turning that design loose unto the world; it’s also about communicating that design to the people that matter and ensuring that they understand what your design is about, why it is the right approach and what problems it avoids or solves.

When we create a software prototype, we have to make many design decisions of varying importance.  The prototype itself might be demonstrated to various audiences and so a little guidance is worthwhile.

Holding the prototype cardOne tactic which is worth covering is to understand your audience and how they will perceive your prototype.  A technical audience will doubtless look at your prototype in an entirely different way to a business audience, which in turn will probably look for different things than would an audience of end-users.  The key is to tailor your approach to demonstrating your prototype so that:

1) It uses language and terminology that the audience understands;
2) It respects the motivation of that audience – in other words, what they want to get out of the demonstration, and
3) It prompts for any specific feedback that you, as the prototype designer, wish to solicit from that audience so as to feed back into the design.

The very best approach is a personal demonstration, particularly a one-to-one hands-on tour.  Letting a user have a play with a rich prototype is an incredibly engaging and fruitful technique, which also gives you the opportunity to watch how that user explores the design.  You might be very surprised by the varying way that different users interact with your design.  If you spot any confusion or hesitation in their use of your design, it could be a strong indicator of a problem which you can then fix.

Keeping the audience awake

However, it’s not always possible or even desirable to do a personal demonstration.  Sometimes it’s not even feasible to let users actually use your prototype at all – either for technical or business sensitivity reasons.

In these cases, one powerful method that has emerged in recent years is the use of screen-casting technology, so that a prototype can be demonstrated and a recording of the screen made (along with an audio voice track).  These can then be replayed by any interested party.

The most important thing after all this is said and done is to ensure that you are in regular contact with your end users, stakeholders and anyone who needs to be involved.  Prototyping is all about getting feedback and refining designs based on that feedback, so however you want to do it, getting your audience looking at your designs is one of the cornerstones of effective requirements prototyping.

(I’d like to recommend a very useful tool called iShowU HD Pro, which is a very low cost solution for screen-casting.  I’ll review this at the end of March, but would strongly recommend anyone who would like to try screen-casting to give it a try.)

Posted in Design Critique, Good Design, Prototyping | Tagged , , , , , | Leave a Comment »

h1

The iPad As Quorn

January 28, 2010

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.

The iPad as 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!

Posted in Design Critique, Good Design | Tagged , , , , , , , , , | 2 Comments »

h1

The Tragedy of Software Development

December 18, 2009

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.

Posted in Good Design, Prototyping | Tagged , , , , , | 2 Comments »

h1

Design Feedback (part 1)

December 4, 2009

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.

Picture of mad dancing

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.

Image of feedback survey and pencil

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.

Image portraying clarity and tranquility

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.

Posted in Good Design, Prototyping | Tagged , , , , , , , , , | Leave a Comment »

Older Entries »