How to Create a Mockup of a Prototype for Your Business Analysis Report
Not all business analysts are screen designers, so you may find creating a mockup a bit challenging. In fact, a field of study called human factors engineering concentrates entirely on the interface between man and machine, which clues you in to how complex it can be.
If you can’t consult a human factors engineer, use the best-in-class applications as your base. For example, if you’re designing a music download application, look to Apple’s iTunes as a best-in-class application.
Here’s how you go about creating a mockup:
Ask why before you even start creating a mockup.
That the business requested a new screen or a new interface means that it is experiencing a problem that prevents it from doing the business or wants to be able to take advantage of an opportunity. You have to figure that purpose out.
Determine the number of mockups you have to create by identifying where you need interfaces.
Here are some guidelines:
Look at your use case diagram. Every association line that crosses the automation boundary in the diagram requires a user interface that you have to mockup.
Reference your workflow diagrams. Tasks that require a user to perform them within the system require a user interface.
Look at your storyboard. Each rectangle on the storyboard is a screen.
Reference your entity tables or workflow diagrams to find the data you need on the screen of the interface.
This info may be data displayed to the user or entered by the user when interacting with the system.
Draw a rough mockup on paper, in Visio, on a whiteboard, or with a specialized tool.
Talk with the application development team about screen interface standards, feasibility, and design ideas.
Revise the design based on feedback from the stakeholders.
At this point, you need to complete the UI specification, which is a set of two tables — field descriptions and screen controls — that explains the details of the appearance of the screen and how everything interacts and behaves with the user.
|Name||The name of the item as it appears on the screen|
|Type||The type of the on-screen item, such a label, selection box, or drop-down list|
|Source||Where the data comes from (info that may identify other interfaces)|
|Description||A description of the field|
|Length||How long the data field is (used to compare interfaces to see whether data is getting cut off or whether a piece of data can fit within the field)|
|Defaults||What the field defaults to if no information is given|
|Req./opt.||Whether the field is required or optional|
|Rules||The business rules that surround this field (may be an actual rule or a cross-reference to a rule table elsewhere in the requirements package)|
|Name||Name of the control as documented on the screen (enables a cross-reference to what is on the mockup)|
|Control type||What the control is (radio button, button, text box, hyperlink, and so on) and how it behaves|
|Function description||What happens when users interact (click on a hyperlink, hover over a button, or whatever) with this control (provides detail information about the experience users will have with the system)|
|Enable/disable||When the button is enabled (whether it’s always available to be clicked on or only enables after certain fields are filled in)|
|Rules||The business rules surrounding this field (may be an actual rule or a cross-reference to a rule table elsewhere in the requirements package)|