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.
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.
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.
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.
What are some sources of “REWORK”
- Misunderstanding of Requirements => Translation Errors
- Test Cases that are inconsistent with the Requirements
Changes to Requirements
- 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.
STORYBOARD 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 about powerSTORYBOARD
Current approach – too many hand-offs and deliverables
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.
The result of this approach includes a lot of re-work and project costs due combinations of the following. Perhaps some of this sounds familiar to you.
Use Cases, UI Mockups, UI Storyboards and test cases often get out of sync with each other, which makes it difficult for the developers and testers to know what real requirements are.
- For example the use case steps may now communicate something different than steps outlined in the ui storyboard or test cases.
- UI Storyboards and/or prototypes forget to implement all of the flows outlined in the use cases, leading to a scenario where features get missed.
- Test cases are incorrect, causing false bugs to be found, wasting further time and budget.
- Missed test cases, causing bugs not to be uncovered, leading to costly production issues.
- Developers building features that are different than what the customer is looking for, leading to unsatisfied customers or additional rework.
- Another related issue is that often during the UI Storyboarding phase new requirements come up that are added to the UI Storyboard but also should be in the original use case. A lot of good intentioned teams will not spend the time to update the use cases and feature lists, furthering the confusion for the developers and testers.
What can we do to reduce this confusion and rework
The good news is that there are some reasonably simple changes we can make in our processes and deliverables that will decrease the “broken telephone effect”. The theme shared by these ideas is to reduce the hand-offs and translations.
Get the Entire Team Involved in the Requirements Early
One technique is to involve the BA, UI/UX and QA resources directly in the elicitation process with the customer. Some may even argue to include the lead developer for that domain as well. By having all disciplines represented during the interviewing process, they will all hear requirements directly from the customer, helping reduce the reliance on just what the BA documents. Another equally important side benefit is that each discipline brings a different perspective which can lead the interview process down different paths of conversation and requirements gathering.
For example the QA resource may tend to ask more questions about the requirements that related to edge conditions, or error conditions, than perhaps the BA or UI/UX resource would. In addition putting the UI/UX resource in front of the customer, will give them a chance to better understand what kinds of features are more frequently used, which is important when trying to manage the cognitive load of the end user, by ensuring the more frequently used functionality is more easily found through good UI/UX design.
This may seem like a waste of time and budget, but at least considering the benefits of doing this on the more complex portions of your application could be a good start.
My personal approach is to include the developers and QA team during the requirements walkthroughs early and well before they are done, so that they have the opportunity to provide feedback and also gain a deeper semantic understanding of the requirements and what is driving them.
Combine and evolve your Use Cases, UI Mockups and UI Storyboards into the same physical deliverable
One approach to addressing this is to combine your Use Cases, UI mockups and UI storyboards into one integrated deliverable called a “Use Case Storyboard”. A “Use Case Storyboard” is simply a use case where each step in the use case is associated with a UI Mockup.
This approach has the benefit of automatically keeping what you traditionally would have documented as a separate use case, UI mockups and UI storyboards in sync. In addition to keeping everything in sync, it turns out to be far easier to communicate the requirements during walkthroughs of “use case storyboards”, because they combine the details of a use case text along with the informative UI Mockups into one deliverable that is easy to walk through from the end user point of view. This not only helps your end customer confirm the requirements are correct, but also importantly helps reduce confusion with the developers and testers
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.
Adopting this approach would involve starting as we normally do by having the BA define the use case without any mention of UI specific requirements, just to capture the objective of the user in the use case and any key steps and alternate flows (or exception flows, depending on which terminology you use). Then the UI/UX team would start to attach UI Mockups to each of the steps in the Use Case to start to bring to life the UI/UX design.
Since the “Use Case Storyboard” is expressed in terms of a main flow and alternate it has the additional benefit of reducing the number of traditional storyboards, which are linear and don’t include alternate flows. For example if we took the sample “use case storyboard” above and represented it as two separate linear storyboards, the first and last steps and their UI mockups would be duplicated, leading to requirements maintenance and rework costs.
So to summarize, the “use case storyboard” reduces rework by helping you communicate requirements more clearly. In addition this approach also reduces requirements translation errors typically caused by hand-offs between deliverables and teams.
Generate Your Test Cases Automatically from Use Case Storyboards.
Instead of having your QA team manually create test cases, why not Generating test cases directly from your “Use Case Storyboards”. This has the following major benefits.
- Dramatically reduce the time it takes to create your functional test case set.
- Your test cases are 100% consistent with your requirements
- You have complete functional test case coverage
- As requirements change, you can update your test case set quickly
For example if we were to take the “Use Case Storyboard” outlined above, it would generate the following two test cases, including the UI Mockups.
Test Cases are typically written in a format of a “user action” followed by an “expected” result. If you spend a little more time up front when creating “Use Case Storyboards”, defining which steps are “user actions” and which steps are “expected results” this can used in the test case generation engine to determine which steps should be assembled into test cases as “user actions” or “expected results”.
As an industry we are always evolving how we do things. In this article I present an approach that helps reduce project costs and increase the likelihood that you will develop what your customers need. I talked about how to get your collective team involved earlier in the requirements definition process which is not really a new idea, but certainly a valuable one. However I do present the concept of a “Use Case Storyboard” that combines Use Cases, UI Mockups and UI Storyboards, into one integrated deliverable that promotes collaboration and also makes it easier to communicate requirements to your customer, developers and testers. Lastly I talked about the idea of generating your functional test cases directly from these “Use Case Storyboards” which generates some significant project savings.