Results for category "Wireframes"

Simulating different Device types – phones, tablets, desktop, webpages, using PowerWireframe

Often you will want to change the slide size to accommodate a different device such as a mobile device, tablet, browser based app, desktop based app etc.

You can do this by setting the slide master size, using normal PowerPoint functionality or you can click on the “Device Type” menu in the PowerWireframe ribbon and select one of the available options which are currently as follows.

  • Phone
  • Tablet
  • Webpage
  • Desktop

We have pre-set the page sizes to be appropriate for those device types, but you can override those page sizes  by changing the page size of the PowerPoint Master Slide.


Is the PRD Dead??

Although I don’t agree that a PRD is dead, I do agree that wireframes/prototypes are essential. Even in the article they state that a PRD has its place. However I do agree that fast and rapid wireframe prototypes are the way to go to allow you to express and iterate on many designs. Don’t go straight to high fidelity working html prototypes as they will take longer and you won’t be able to explore as many UX ideas.

Here is an article on the creators of Foundation (competitor to bootstrap), expressing their pov on the PRD being dead.


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…