How to Create a Mockup of a Prototype for Your Business Analysis Report - dummies

How to Create a Mockup of a Prototype for Your Business Analysis Report

By Kupe Kupersmith, Paul Mulvey, Kate McGoey

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Screen Detail Description
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
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)
Screen Detail Description
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
Enable/disable When the button is enabled (whether it’s always available
to be clicked on or only enables after certain fields are filled
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)