Agile Lab - Training, Coaching and Consultancy Blog

Thursday, 12 March 2009 at

New Course - Build Interfaces that Users want to Use

Introduction to User Interface Design and Development

User interface design and development is perhaps the hardest aspect of web and software development to get right. What makes it particularly difficult is that there are no good ways of developing interface software that don't involve getting feedback from users.

The good news however is that there are a set of relatively quick and easy methods for involving users in the process of designing and developing user interfaces. These methods can dramatically improve the speed and quality of user interfaces that are developed.

The course provides course participants with the basic skills that they need to develop better user interfaces – interfaces that users will actually want to use. As well as introducing the most important concepts of UI design and development, the course gives participants direct experience and practice of using the methods discussed.

Low-tech prototyping of interfaces and wire-framing
The fastest way to develop effecting and compelling user interfaces is by starting out with paper and pencil. Wire-framing is a computer based technique that is almost as fast but gives a better feel of what a final interface might feel like.

Really, really fast user testing
User testing doesn’t have to be a long drawn-out process, it can be done very quickly and can massively improve the quality of the final interface design.

Including feedback from user testing into production code: the lifecyle of user interface design
It is very rare that the first attempt at coding an interface is the final one. But rearranging the software development process so that it can take account of the feedback about the interface from users can seem like a daunting task. However the changes do not have to be major to have major effects.

10 Do’s and don’t for user interface design
We go through the 10 most important heuristics - ″rules of thumb″ that should be applied when developing a user interface. Applying these rules can substantially improve the quality of user interfaces in a very short time.

Mark Stringer is a trainer, coach and consultant. He has worked as a software developer and project manager for IBM and Xerox and for a series of small internet start ups. He has also worked as a researcher and taught Human Computer Interaction and Interface Design at Cambridge and Sussex Universities.

Mail 07736 807 604

Labels: , , , ,

Tuesday, 24 February 2009 at

Iterative Development

Mark talks about the process of iterative software development. This was filmed at our "Introduction to Agile Methods" training course that we did in Plymouth in January 2009.

For further information, contact (07736 807 604) or (07713 634 830)

Labels: , , , ,

Friday, 5 September 2008 at

How can we persuade people that Agile Methods reduce costs?

I've just read this article by my friend Tim Diggins. I think it makes very clear why he uses Agile methods and what that actually means for him - as he says - what he does do and what he doesn't do. I don't think it's so good at convincing people who don't really know anything about Agile methods that they really lower costs - so here's my attempts, in note form.

Lower costs are what they're interested in so that's what needs to hit them first. It's like the story about James Thurber - he had a job as a crime reporter and he was asked to cover a murder on his first night. He reported how he'd heard about the murder, how the police had been alerted, who'd actually discovered the body. When he gave it to his sub-editor, the sub-editor said "No, no, no! This is all wrong! You have to start with the most important detail, the most important word even, first and then give the details in order of importance rather than chronologically"

So Thurber re-wrote his piece and started it off - "DEAD - that's how they found him!"

So how would this start?

"CHEAPER! That's what your software costs will be when you use iterative development." Even this is better. It's to the point but it's not obvious how to bring in the arguments you'd need to convince the reader.

Another tack is the Minto method:

  • Bland statement nobody can argue with
  • Sophistication/Complication
  • Solution that deals elegantly with the Sophistication/Complication

So for Agile this might be:

Everybody wants to lower the costs of software development.
But this isn't easy because a lot of the costs are hidden.
They come late in the process because:
  • That's when the clients and the developers realise they weren't thinking of the same thing
  • That's when developers charge elevated prices for requested changes to recoup costs for wasted work
  • That's when it becomes obvious that some new technology doesn't perform as well as the hype would lead you to expect
  • These costs can actually be so high that the project is abandoned - the customers get nothing for their money - the ultimate high cost.

Iterative development [Here is where you would teach the concepts of iteration and working software] which produces working software throughout the lifetime of a project is aimed directly at reducing these late and hidden costs.

  • Every time the client is presented with a new piece of working software, the understanding of the clients and the understanding of the developers about what the software is for and what it should do is tested. The chances of terrible misunderstanding (and big late costs) are reduced.
  • Changes can be added throughout the project, because negotiation in an Agile project can be in terms of scope, as well as price, it may be that changes may have little effect on cost
  • The emphasis on working software means that trouble with new technologies emerges early in the process. Something can be done early to work round the problem and find and alternative solution.
  • Iteration by iteration the customers get closer and closer to actually having the thing that they want. At all stages they have *something* that provides the most important functionality. The chances of having to abandon the project are greatly reduced. Conversely, if a project just isn't a good idea, this will be obvious much earlier than with a conventional project, the costs of cancelling it will be reduced.

Labels: , , , ,

© Agile Lab, 2007-2009. All rights reserved.


Powered by Blogger

Subscribe to Posts [Atom]