Now that you understand what UPK can do for you, you need to think about exactly what you want it to do for you.
You need to decide whether you are going to use your simulations as an integral part of classroom training conducts, or will be providing your training as stand-alone deliverables suitable for self-paced learning. Or both.
If you only plan on using your exercises within a classroom environment, then you may be able to get by with providing less business context in your simulations because the trainer will be able to provide this context during the classroom conduct. However, if you do this you will be selling yourself short. There will undoubtedly come a time when your UPK exercises will be used for self-paced training, even if this is not the initial intention. Providing this capability up-front will save re-work in the long run.
If you will publish to any of the true interactive formats (Player, LMS, Standalone Topic Files), you need to decide which of the playback modes you will use. Editing Topics so that they will make sense in several different modes takes time—especially if you are using Custom Text extensively (which you should, if you want to provide quality training). If there are certain modes that you know you will never use, then you can save yourself some development time. However, bear in mind that the printed output formats can also make use of these playback modes, so you need to make sure that you develop your online content with these modes in mind, as well.
Consider which (if any) of the printed document formats you will use. As explained above, training is not the same as documentation. You can have high-quality, effective training simulations, but this does not necessarily mean that the documents generated from them will be as good.
Examine the available document formats and decide if you have a use for them. If you do not have a proven need for a document type, then do not generate it "just because you can". If you decide to use one of the document formats, then think about how these documents will be made available to the trainees or users. If you use only one document format, then you can provide access to this via the Print It! mode. If you provide more than one document format (which I'd question the need for, as they all provide basically the same information), decide how you will deliver these. If they are not immediately accessible to the people who need them, re-examine the wisdom of providing them at all.
UPK allows you to tag the text that is displayed to the users so that it appears only in specific modes. When you generate one of the document output formats, you need to tell UPK from which one of these (three) modes the text for the document should be taken. You should, therefore, make sure that text is tagged for the appropriate mode in the Topic so that when the document is generated from this mode, it includes the required text. Tagging text for different modes is described in Chapter 4, Editing a Topic.
UPK does a very good job of ensuring consistency and adherence to styles and standards, via its built-in templates, which define the default texts shown in the yellow bubbles that are overlaid on the screenshots. One of the templates that it provides is even designed to be compatible with the terminology and formatting standards espoused by Microsoft's Manual of Style for Technical Publications.
You should check these default templates (Standard and Microsoft) to determine if they meet your in-house standards. If neither of them seems suitable, then you may want to consider creating your own template—or at least customizing one of the two provided templates to meet your requirements.
Over and above the Bubble Texts that are controlled by the template, you should develop your own style guide to specify the following things:
The overall structure and content of your Outlines
The information that should be provided in the Concepts pane
The type of information that should be provided via Custom Text
Whether icons should be used, and which ones should be used in which types of Frames and/or Bubbles
Fonts for Bubble Text and fills for Bubbles
Word choice for Custom Text
Whether external documents should be incorporated into your output, and how
Whether you want to use images, and the allowed size and formats of these
Don't worry if most of these terms do not mean anything to you yet; you will be intimately familiar with them by the end of this book.
Developing an unequivocal style guide, and then ensuring that all developers adhere to this for all simulations, will ensure that your training deliverables are seen as parts of a cohesive whole rather than "a bunch of stuff done by different people at different times".
You need to decide on the stage during the application development cycle at which you will capture your simulations. Ideally, your simulations should be captured in the final version of the system.
The whole point of simulations is that they should have the "look and feel" of the actual system. Specifically, they should match reality as closely as possible—there should be a willing suspension of disbelief on the part of the trainee that they are actually looking at static screenshots. This is a common fault with poor-quality UPK exercises: they do not allow for this suspension of disbelief because it is glaringly obvious that the trainee is not using an actual system. With a high-quality exercise, however, the trainee has the impression that they are using a "live" system. One of the common complaints that trainees have with training conducted using UPK simulations is that they would rather have a "real" system to play with. The easiest way to avoid such comments is by providing simulations that are as close to reality as possible.
That said, it is often impractical to wait until development for the entire application is complete before developing your training. Often, training development and application development will run in parallel. Fortunately, development is often gradual, with different parts of the application being completed over time (as opposed to nothing being ready until the whole thing is ready). You should therefore work closely with your development team to ensure that the training developers are informed as and when different pieces of the functionality are finalized, so that you can start developing training for these pieces, while the development teams work on the next piece of functionality.
Although you might think that what to record is obvious—just whatever the user will actually do—this is not necessarily the case. You need to think about whether you will demonstrate a specific scenario, or provide general instructions, or show everything that the user can do in the application (or transaction), regardless of whether they actually will do this.
You should also decide whether you want to teach only one way to do something, or will provide alternative actions and alternative paths (both of which are covered later in this book).
A useful technique when making these decisions is to produce a 'storyboard', or a simple flowchart of what screens you will go through in the application, what you will do on each screen, and how you will get from one screen to the next. Having this information available beforehand will save you from having to decide these things during the recording itself, and potentially missing things. Storyboards are also useful if you have less-experienced developers who perhaps need some more guidance for their recordings.