Results for category "Storyboards"

How To Sync Step content with Slide Title

Objective :

To sync the content typed into a step with the slide title.

How to accomplish:

  1. Click on the PowerStoryboard Ribbon
  2. Click on the “View Options” button near the left side of the ribbon
  3. The system will open up a view options dialog
  4. Ensure that the “sync slide title with step text” option is selected.

Closed

How to add Storyboard Navigation Links to Slides

Objective :

To have PowerStoryboard automatically insert Hyperlinks onto slides that allow the viewer to navigate to alternate flows and also following links to specific slides, based on what was defined in the Steps Editor.

How to accomplish:

  1. Click on the PowerStoryboard Ribbon
  2. Click on the “View Options” button near the left side of the ribbon
  3. The system will open up a view options dialog
  4. Ensure that the “Add Alternate flow hyperlink onto branching step slide” option is selected.
    1. Note: this will create links from the branching step to the alternate flow step as well as a return link.
    2. In addition if you have setup direct links between slides using the “link to step”  option in the step context menu or the steps editor panel menu, then these links will also be added to the slide that is the source of the link.
 

 

Closed

Setting up your Storyboards for best results when Generating Test Cases

When using PowerStory to generate test cases it is important how you use “keywords” within your steps to indicate if the step is a user action or an expected result.  

When you first try to generate test cases from your storyboard the default keywords are <user> and <system>.

If a storyboard step has the keyword <user> within it,  then it will be translated to a “user action” within the test case step generated.

if a storyboard step has the keyword <system>  within it, then that step will be translated to an “expected result” within the test cases step.

For example if you have a storyboard such as this…

  1. <user> types a url into the browser
  2. <system> loads the page associated with the url into the browser window
  3. <user> clicks on the login button
  4. <system> presents the login dialog
  5. <user> provides valid credentials and clicks on the login button
  6. <system> logs the user in and presents the home page

Then the resulting test cases would be as follows

User Action  -> Expected Result

1. types a url into the browser

-> Loads the page associated with the url into the browser

2. clicks on the login dialog

-> presents the login dialog

3. provides valid credentials an clicks on the login button

-> logs the user in and presents the home page

Closed

Moving Steps

Moving steps can be accomplished by selecting the step so that it is not in edit mode and then dragging it to its desired location.  Alternatively you can use the arrow keys in the steps editor panel menu to move the step up and down or convert to/from an alternate flow. 

Closed

Deleting Steps

To delete the selected step, simply hit the DEL key on your keyboard or click on the “X” in the steps editor panel menu.

Closed

Deleting an Entire Alternate Flow

If you want to delete an entire alternate flow select the alternate flow condition step, which is the step defining the condition that causes the alternate flow and hit the DEL key or the “X” key in the steps editor panel menu.  NOTE: THIS WILL DELETE THE ENTIRE ALTERNATE FLOW SO USE WITH CAUTION.

Closed

Copying and Pasting Steps

To copy and paste a step, you can use the context menu by right clicking or use the keyboard shortcut of CTL+C to copy and CTL+V to paste

Closed

Quick Editing Tips for Storyboard Steps Editor

PowerStoryboard  has some built in features that will make it very easy for you to add your steps within the Steps Editor.  These features were built with quick data entry in mind.

Use the ENTER key  to quickly add a new step:

When you are editing an existing step, if you hit the ENTER key this will create a new step below the current step.

If the current step is an alternate flow condition then the step will be added as the first step of the alternate flow.

Use the TAB key to quickly make an alternate flow:

Hitting the TAB key will make the currenlty selected step an alternate flow to the step just before the currenlty selected step.

Use the SHIFT + TAB to move an alternate flow to it’s parent flow.

Hitting the SHIFT+TAB key combination will change the currently selected step from being an alternate flow (if it is an alternate flow) to become a sibling of the stp just before it.

Closed

Are you tired of REWORK caused by software requirements changes & misunderstandings?

Causes of Rework = duplication + translation errors

sources of rework

Too many hand-offs,  Translation Errors & Duplication

Many organizations approach to defining software requirements involve too many hand-offs and deliverables.  This can lead to requirements translations errors between the different hand-offs and deliverables.  In addition, the collective details of the requirements are spread across so many different deliverables it makes it harder for the developers and testers to properly interpret and understand the requirements.

For example, many organizations will take this approach…

BA / Product Manager

  • The BA or Product owner elicits requirements from a customer…
  • …and writes them down perhaps as a high level feature list…
  • …then further elicits and documents requirements details using use cases and/or user stories and perhaps

UI / UX Team

  • These use cases or stories are then interpreted by the UI/UX team…
  • …to develop UI Mockups
  • …and perhaps UI Storyboards
  • …or even full blow interactive UI Prototypes to bring these use cases to life.

QA and Development

  • Then the development team and the testing team need to interpret these UI Storyboards, UI Mockups and Use Cases to develop the code and Test Cases.

When Requirements Change => You have to update too many documents with often duplicate information

For example…

  • Updating the user interaction flow and step details that are duplicated across your Use Cases and Storyboards and Test Cases
  • Updating your Wireframes, which are duplicated across multiple storyboards and test cases
  • etc

How do “Use Case Storyboards” eliminate this REWORK

“Use Case Storyboards” COMBINE your “use cases”, “wireframes” and “storyboards” into one integrated deliverable

A “Use Case Storyboard” as shown below, is simply a “Use Case” where each step in the use case is associated with a UI Wireframe/Mockup. This of course includes the main flow and alternate flow steps of the use case which is very different than traditional “Storyboards”, which are only a series of linear steps. This sounds simple, but the benefits are profound.

This approach allows you to walk through, or essentially simulate your “use case”.

Sample Use Case Storyboard where you associate Wireframes with each step  in a use case.

So what are the benefits of this approach and how does it reduce REWORK

    • Communicates Requirements more clearly resulting in less software development iterations
      • No longer does the reader have to review a use case and then manually correlate the steps in the use case to a storyboard or even worse just a collection of wireframes not put into a storyboard.
      • Instead the reader has the context of the details outlined in the use case step right beside and in context of the Wireframe associated with that step.
      • In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.
    • The “user interaction flow” is shared between the use case and the storyboard eliminating duplication
      • As the flow changes you no longer have to update the flow definition in multiple places (ie. Use Case, Storyboard, Test Cases), reducing rework.
      • It also ensures your storyboards cover all of the alternate flows defined within the use case helping ensure requirements are not overlooked
      • Your storyboards will have less duplicate UI Wireframes, because common wireframes that used to be duplicated across multiple storyboards are now defined in the mainflow or parent flows of nested alternate flows.
    • You could even generate your test cases from your Use Case Storyboards
      • The interaction flow and wireframes defined in the Use Case Storybaord are identical to what you will want for functional test cases. So using some creative algorithms you can actually automatically generate your functional test cases and they will be 100% in sync with your requirements.

powerSTORYBOARD allows you to create Use Case Storyboards in something you are already familiar with -> PowerPoint

Create “Use Case Storyboards” in PowerPoint with powerSTORYBOARD

Learn More…

Closed

UI Prototypes V.S UI Storyboards – choose carefully

In this post I will share my experience with using UI Prototyping versus using UI Storyboarding. Fist let me start off by saying I think that both types of deliverables have their place.

UI Prototypes: Take longer to create, resulting in less options created and reviewed.

UI Prototypes are great at visualizing more clearly any unique and complex user interactions. In past projects I have used them for this purpose, but I have to say the need for this has been rare. Creating UI Prototypes in my experience always takes longer than UI Mockups or Wireframes put together into a UI Storyboard, allowing more time for creative changes. Also there seemed to be a greater resistance to change the user experience in the prototype because it just took longer which lead to more emotional attachment and less willingness to spend additional effort to explore other options.

UI Storyboards: Can convey more requirements than UI Prototypes

One problem I have always had with UI Prototypes is that it does not walk the reviewer through the user interaction flow. Instead the reviewer must explore and “find” the requirements by hovering, clicking, swiping etc. This can lead to some of the user interaction requirements being missed by the review. The second problem I have with UI Prototyping is that most tools used to create these interactive prototypes are not good at capturing and communicating additional information such as field size, validation rules, security requirements etc, that can easily be added to a UI Storyboard created in tools like PowerPoint. This means you typically need to create a supplemental document that references screen shots from the prototype, which creates additional work keeping the document and the prototype in sync.

UI Prototypes: If you are going to do them, use the dev tools!

I guarantee there are other valid views on this, but my view is that if you are going to go to the effort of creating UI Prototypes, it should be done using the dev tools you will eventually use to create the product. If you are building a web based product then this would be HTML5, CSS3, JS for example. You can create prototypes very quickly in most development tools with visual editors or even if you need to hand-code all of the UI, a good front end developer can create prototypes very quickly. This has the added benefit of kick starting the actual development work, and also positions you well for making changes to the prototype and integrate that with the on-going development work.
Summary

UI Prototyping is a very popular trend, but you should think carefully about the investment it requires and its true value compared to the more flexible, less time consuming approach of using UI Storyboards in common products like PowerPoint, which can convey more details about the requirements and not rely on reviewers discovering features hidden within UI Prototypes.

Closed