Online Test Banks
Score higher
See Online Test Banks
eLearning
Learning anything is easy
Browse Online Courses
Mobile Apps
Learning on the go
Explore Mobile Apps
Dummies Store
Shop for books and more
Start Shopping

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:

  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 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)
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 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)
  • Add a Comment
  • Print
  • Share
blog comments powered by Disqus
Advertisement

Inside Dummies.com

Dummies.com Sweepstakes

Win $500. Easy.