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.
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.
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 zurb.com the creators of Foundation (competitor to bootstrap), expressing their pov on the PRD being dead.
Causes of Rework = duplication + translation errors
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
- 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
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”.
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
This Video shows how you can modify the color of ICONS you have dragged and dropped onto your slides from the powerWIREFRAME UI Controls Library
See on Scoop.it – Wireframes and UI, UX
The future of digital
A very interesting and informative look into key metrics describing current and future trends related to digital marketing.
See on www.slideshare.net
See on Scoop.it – Wireframes and UI, UX
Too often when we think of a customer, our view is filtered through the lens of our job, profession, department, or specialty. Think of how patients are treated in most hospitals.
See on www.joycehostyn.com