Quite apart from the many benefits of Requirements Prototyping, there’s nothing quite like seeing the face of your customer when they see their ideas transformed into something they can take for a spin.
It’s quite literally priceless…
Archive for October, 2009
Doing versus Thinking About Doing
October 29, 2009Traditional business methods spend a whole lot of time planning, organising, assessing – basically any one of a number of things which put days, weeks and even months onto an activity’s duration. Sometimes this is the right thing to do, but other times it is overkill.
The spirit of Prototyping can turn this on its head; build a model, critique it, refine it and so on. The emphasis is therefore much more about ‘Doing’ than it is about ‘Thinking About Doing’.
The opportunity this gives us is to be able to start chipping away at a task from a much earlier point, and using the experiences of creating our models to support our planning, organisation and assessing requirements as we go. The benefit, of course, being that we start building momentum and focus early on, and have tangible models to show for our efforts long before the traditional approach would have even begun to ‘Do Anything‘.
In today’s fast-paced, cost-conscious world, we need any advantage we can get to deliver effective results – and Prototyping definitely delivers those!
So, stop navel-gazing with your traditional ways and give your projects a ‘Doing’ focus – today!
Coping with Change
October 28, 2009One of the great things about software prototyping is its responsiveness to change.
Oftentimes, changes are requested without enough thought being given to how those changes might be received by the people who will use a system. The Requirements Prototyping approach allows our prototyping analyst to get involved at an earlier point to help establish the suitability and impact of a change before that change is given the green light.
So, when a business stakeholder comes in and tells you that he thinks the order screen now needs to use tabs rather than accordion-style panels, it’s not a huge effort to be able to put a prototype together to let him try it out ahead of that change being added to the project. The activity of building a model of the change focuses our minds on the impact of a change, and we can feedback realistic development estimates into the project planning. Tweaks to the proposed design are quick to make and the feedback cycle with the stakeholder is short, allowing expert design input to help influence and inform the business decision-making process.
Sometimes, after creating a prototype of a proposed change, we’ll collectively learn enough about it to reject it; on other occasions it might need refinement or even trigger additional change. What’s great about Requirements Prototyping is the way that it brings the various parties together in this process, allowing each individual to feel that their voice is being heard. This has a motivational kick to it too, and fosters additional ‘buy in’ from those involved at all levels.
Change is inevitable – it’s the pulse of business and something we can’t avoid. Better then to choose techniques such as Requirements Prototyping which allows us to handle change in a positive way.
Do we really need prototyping software?
October 27, 2009In a blog post a few months back, Karol Zielinski puts forward the idea that we don’t need prototyping software.
It’s an interesting angle to take, and before we take a look at his arguments, it’s only fair to state that of course we don’t need prototyping software in the same way we don’t need a word processor or Visual Studio or whatever modern software we use on a daily basis. We could manage without, but it would be a much harder existence and what we’d accomplish in a day today would take weeks without our modern toolset.
I believe we should use the best tools we have available wherever possible, though Karol takes a bold stance when he says that:
‘the most important thing in creating web-based application is to create it as fast as it could be created; using the easiest and the cheapest possible methods and tools.
Looking at that statement, it’s certainly good to be responsive to changing requirements and so I can put no argument up against that. I also agree that using the easiest tools is never a bad idea. However, bringing cost into the equation might be a false economy.
For example, we could do all of our prototyping using html and javascript. It’s certainly cheap – free, in fact, as we could do it all with any text editor – and it’s not rocket science as html+javascript are pretty well understood and there are many books out there. However, it’s going to take a LOT longer than using a quality prototyping tool such as Axure and didn’t we just argue the case for responsive prototyping? In any case, your customer might not be prepared to wait and the cost of a dedicated and supported prototyping tool would quickly be recovered in cost savings and workflow efficiency.
Karol definitely favours wireframing, because it is ‘the most powerful, the cheapest, the fastest and the easiest method’. I disagree; its power is limited because its output cannot convey the look and feel of a finished product; it’s also static – your boss can’t interact with it, and so you lose the intrinsic value of a prototype as a promotional tool to gain support and increase awareness.
In fact, wireframing is in many ways one of the worst approaches to take if your intended design is interactive – it’s difficult to visualise the interaction and the flows through the design.
Creating an interactive prototype might well be somewhat more complicated to achieve than simple wireframing, but I argue that it is a far more powerful technique and justifies that extra effort.
What do you think?
Requirements Prototyping in an Agile World
October 24, 2009Agile methods are currently one of the hottest topics in business management.
Agile methods break tasks into manageable increments with minimal planning. Agile is an iterative process, splitting larger tasks into phases of fixed duration. Though there are many Agile methods in use, we’ll concentrate on one of the more common, which is known as Scrum.
The Scrum Method
Scrum incorporates a number of key processes, 
techniques and roles. In Scrum,
each project phase is known as a Sprint and can be considered as a mini project in itself. The objective of each sprint is to create a ‘latest system’ which has been tested, debugged and can be demonstrated to stakeholders, and its objectives measured against an overall plan. Depending on the complexity and scope of a project, there may be many Sprints, each one advancing the development in measurable steps.
Agile projects emphasise people over process, with face-to-face communication and collaboration underpinning all activities. Agile teams are normally composed of between six and ten people having a variety of different skills and experience. Larger projects may split into multiple teams, but the optimal number is generally in this range. Each team aims to be largely self organising; each member takes responsibility for both their own individual objectives and the progress of the Sprint itself. Location is another important consideration, with teams ideally located in one location and coordinated by Daily Scrums – that is, brief stand-up meetings to report progress, allocate tasks and communicate any ‘blocking’ issues.
Each Agile team includes someone who will represent the business stakeholders and act as liaison between the team and the business – the Product Owner. This roles involves acting as a single point of contact for questions and as a reviewer at the end of each sprint, to ensure objectives are met and minimise any expectation mismatch between the team and the business. A Scrum Master is another individual role, responsible for maintaining the processes and performing general project management duties, including resolving any problems.
During a Scrum project, it is recognised that the customer can and probably will change their minds about what they want and consequently Scrum aims to focus on responsiveness to change.
Drawbacks of Scrum
On the surface, Scrum appears well suited to business software development. However, the lack of structure and documentation output is seen as a real drawback, with significant risk of requirements mismatch and knowledge loss. It also lacks the rigour of conventional software design, leading to short-cuts, unnecessary reworking, inefficiency and a lack of overall architectural governance. Moreover, it is notoriously difficult to provide useful estimation due to the fact that development begins before the full scope and requirements are identified. Lastly, though it aims to respond quickly to change, it fails to provide any real mechanism to help organise and channel that change and is entirely passive in working with its customer to ensure that any change is properly scoped, designed and managed.
The Power of Requirements Prototyping
Requirements Prototyping is the structured use of conceptual and interactive models to help stakeholders and users shape the design process. Executed and coordinated properly, iterative prototyping is normally performed in several iterative cycles which may include multiple prototypes to explore alternatives. The prototyping consultant operates with many responsibilities, including acting as a liaison between different business units, a technical adviser, usability expert and business analyst. Of course, input from business domain experts is required and the skill of the prototyping analyst is to distill this knowledge into models which reflect the basic objectives of the project and help put ‘flesh on the bones’ of the requirements and design.
Use of Requirements Prototyping in the Agile World
Agile is development focused and encourages creating the ‘how’ before the ‘what’ has been pinned down sufficiently. It does not really facilitate interactive design. Requirements Prototyping, on the other hand, is very suited to the creation of effective interactive design, and excels in shaping the requirements early on, before expensive development effort begins.
ProtoSMART
ProtoSMART is one solution we are developing: a sprint-based Requirements Prototyping methodology which itself can form the initial phases of a larger Agile project, particularly those based around Scrum.
How it works is quite simple: during the early stages of any non-trivial development, detailed requirements are not always finalised. General objectives, however, are normally in place and provide a skeleton to begin an iterative process of prototype steps.
1. Kick Off
To begin with, a kick-off meeting is held which agrees on the foundation objectives and requirements of the project. These are categorised and rated according to priority, completeness and expected complexity. This sets the agenda for the project. This is similar to a Sprint Planning meeting but instead of being focused on a single sprint, covers general objectives for the entire project.
2. Early Requirements Gathering
The prototyping analyst will spend some time with each stakeholder extracting more information about each of the foundation objectives and will begin work on high level flow prototypes. These high level prototypes gloss over specific detail, instead acting as placeholders onto which the requirements prototyping process can pin its outputs.
3. The Requirements Prototyping Cycle
This involves taking the high-level prototypes from the second stage and beginning to work with the business stakeholders and end-users to build in detail and try typical user scenarios against the design. Sometimes multiple models of a particular slice of functionality will be created so as to choose between alternative approaches (perhaps in a workshop scenario). This phase is often split out into several sprint-like stages of its own, with deliverable milestone prototypes and reviews being performed at the end of each sprint. In essence, this is the ‘spirit of Agile’ applied to prototyping.
4. Design Finalisation
After a few iterations of requirements prototyping, a much clearer idea of the true shape of the project will have emerged, backed up by the existence of an ‘interactive requirements specification’ which doubles as a simulation of the proposed system. At this stage a workshop is help which involves all key stakeholders and user representatives, with the view to signing-off the design.
5. Development Initiation
This is the usual point at which the actual development phase begins, using the signed-off prototype as a requirements foundation and guide. The prototyping analyst generally remains involved in a gatekeeper capacity, helping to map tasks into sprints and ensuring that any refinements required of the design are managed appropriately. She may also take on the role of Product Owner, if required, or that role may go to another person.
6. Sprint-based Development
This phase is essentially the same as for a conventional Scrum development, but supported by proactive requirements prototyping which supports any changes which come through from the business. The prototyping analyst continues to play a part, either working directly with the business or with the Product Owner, and may optionally take on additional responsibilities as suits the resourcing of the project.
Benefits of ProtoSMART Agile Prototyping
- Takes advantage of the responsiveness and focus of a conventional Agile project, and is familiar with anyone who has experience of operating in that manner;
- Allows the benefits of requirements prototyping to shape the direction of an Agile project both during the early stages and as a way to co-ordinate and facilitate change during later sprints;
- Proactively engages stakeholders and users at all stages;
- Avoids the mismatch which is inevitable when development starts before the requirements are clear;
- Guides the optimal choice of tasks and user journeys in the Agile process.
This model for system development is still evolving; as we learn where the methodology’s strengths and weaknesses lie, we may adapt it or even skip certain stages. It will not fit every type of project, but for non-trivial modern software development projects lacking clear objectives from the start, it provides a flexible yet structured approach which combines two existing approaches in a sympathetic manner.
Visualise!
October 23, 2009People really aren’t that great at visualising written descriptions.
If I try to describe my home to you in words, after a while you’d have your own ‘internal’ image of my home. However, it would be almost certainly very flawed, as no matter how much detail I provide to you, it will miss something and you’ll have to join the dots, so to speak.
If I show you a picture, or perhaps a scale model, however, you’ll end up with a very good and accurate impression of my home in a fraction of the time that it would take by words alone.
So, bearing this in mind, why is it that many companies still don’t try to leverage the power of models in their design process? Prototypes of systems are relatively quick to create and modify, do not require enormous investments in time, technology or manpower, and deliver enormous benefits to the creation of workable, effective systems.
If you are looking to create an interactive system of any size, a prototype will help everyone involved visualise the end product and your project is far more likely to succeed. Try it. Or engage a specialist.
Don’t re-invent the wheel…
October 22, 2009If you’re working with a prototyping tool, you’ll likely find yourself developing ‘parts’ which might be re-usable.
In our experience, taking the time to build a standard library of ‘parts’ (or, making use of an existing library if a suitable one exists) is time well spent.
So, rather than continually having to create, say, an ‘About’ screen for each prototype, you can create or make use of something more generic as a starting point and customise it.
Over time you should end up with a good library of parts from which you can assemble the ‘skeletons’ of new prototypes more quickly.
Since one of the key benefits of prototyping is in minimising the time between being asked to create a model and actually producing that model, we should aim to find ways to increase efficiency and using a ‘parts’ library is a great way to start.
Forming Paths
October 19, 2009Have you ever been out walking somewhere and noticed that despite the presence of carefully constructed paths, there are worn trails on the grass? These are where people decide that they want to take control of their own journeys in the way that best suits them?
It’s a common phenomenon and planners could learn a lot from holding back on the creation of ‘official’ pathways and seeing what natural paths are worn by the feet of those crossing the ground.
Well, it’s the same in the development of effective user interfaces. Rather than dictate to users how they should interact with a piece of software, we can use rapid prototyping techniques to help evolve a user interface from the actual ‘natural’ way that users want to interact with a system.
This can’t easily be done using conventional waterfall development techniques
and is something which plays to the strengths of software prototyping.
Maybe your system could benefit from a bit of user-led path formation…
Wide versus Deep
October 8, 2009One of the beauties of software prototyping is the way that we can fine tune the level of ‘richness’ of the prototype to suit its audience.
We can create ‘wide and shallow’ prototypes, which are used to provide a broad impression of an entire system without implementing specific detail. These can be used to gauge the overall navigation, feel and ‘shape’ of a proposed system.
This approach is more common during the early stages of prototyping, where much of the fine detail has yet to be established. The ‘width’ refers to the scope of a system – for example, a ‘wide’ prototype of a payment system would generally include the full user interface, menus and such. However, being ‘shallow’ there would be very limited functionality built into the prototype. So, though htere might well be a full set of menus, they wouldn’t normally do very much, beyond perhaps opening placeholder forms or very simple navigation.
Contrast this with a ‘narrow but deep’ prototype, which is essentially a prototype with a far narrower scope but with increased functionality and detail.
This can be used to provide a very rich user experience of a particular slice of a system, with a very close approximation to that of a developed solution. This can include things like mock data, logic-based branching and all of the polish that one might expect in the end product.
Richer ‘deep’ prototyping tends to follow ‘wide and shallow’ prototyping. It needs a basic foundation to build in the richness of functionality, and that foundation is normally provided by an existing ‘wide and shallow’ prototype.
Of course, it’s not unusual to have ‘full feature’ prototypes, which incorporate both full scope (‘width’) and functionality (‘depth’) – but these are large and complex to create and are generally the preserve of high visibility, big budget developments.
More typically, creating a ‘wide/shallow’ prototype or two for basic requirements formulation and design, followed by some enhancements to key areas in terms of ‘depth’, provides enormous benefit to most projects.
