Winning at wireframing
Requirement gathering is one of the most important aspects of an Anaplan build. If done thoroughly, it will give stakeholders a quality product with a quick time to deployment. If done poorly, it can result in many additional hours spent in rework and a negative experience with stakeholders and testers. We’ve all heard the adage “a picture is worth a thousand words.” For model builders, a wireframe is worth a thousand words.
Nothing left in the grey
While ultimately one of Anaplan's greatest strengths, the customizability of the platform can make requirement gathering challenging. It’s common for busy stakeholders to quickly submit a development request with a vague, one-sentence description, leaving you to figure out the rest. While a one-sentencer can be a good starting point for writing user stories, it just doesn’t cut it in the implementation phase.
Tasking stakeholders with creating a wireframe of their request is an effective tool not just for the model builder, but also for the stakeholder. Generating a wireframe forces the stakeholder to think about the nuances and complexities of their overall request. What is our desired formula logic? Which conditional formatting should we use? How should dropdowns be filtered? These questions shouldn’t wait until midway through the implementation phase — or worse — during the testing phase.
Enforcing wireframes as a mandatory part of a development request is a useful policy that model builders and their CoE can adopt. Having trouble getting buy-in? Set up time with subject matter experts to work through a few wireframes together. Having these under their belt will spur engagement and give your policy a better chance of success in the long run. If your company has a business process management team, see if they’re willing to assist! Teams like these often have vast experience with requirement gathering and can teach you a thing or two about best practices.
Wireframing in Excel
Excel is sometimes viewed as a bad word in the Anaplan community, but it can be extremely valuable in quickly developing a wireframe. Almost everyone in the business world is familiar with Excel, so using it as a tool for wireframing increases the odds of receiving a quality mockup from your stakeholders.
The above image is a fantastic example that I received from our pricing SME. The SME clearly provided the pivot structure of page selectors, Rows, and Columns. The desired filter and synchronization on the columns are outlined in Note #1 and Note #2. Example data is provided in the wireframe along with formula logic as shown in cell B11. Cells requiring manual input are highlighted in blue, which mirrors Anaplan’s cell display. A conditional formatting rule is indicated in Note #3. The SME explains in Note #4 that the Promo Description line item should be a dropdown that only allows the user to select promotional descriptions available for the given account and item. Dependent dropdowns will work perfectly for this request. Finally, the SME wants four line items to be manual inputs if a Custom Price is selected in the dropdown, but otherwise wants these line items to be formula-based as outlined in Note #5. Not every request in a wireframe may work with Anaplan’s functionality, but what matters is that the SME documented their ideal state!
Translating wireframes: compromise & creativity
After receiving the wireframe from our pricing SME, the first step is to evaluate the feasibility of the individual requests within the wireframe. In this case, the SME seems experienced as an Anaplan end user; the grid structure matches Anaplan dimensionality and they have outlined specific filters and synchronization functionality. Almost everything can be achieved within Anaplan excluding the functionality in Note #5. The SME would like the line items Suggested Retail Price, Discount (per case), TR Share of Discount, and Scan Back $ (per case) to switch between manual input and formula based on the selections in the Promo Description dropdown. This just isn’t possible on the Anaplan platform, but we can come close.
As shown in the new UX grid image, these line items were split out into manual input and formula-based logic. Using dynamic cell access, we can toggle between these line items based on the dropdown selection. The end user selected Price 1 to be a pre-defined promotion, so the formula-based line items are made active. The end user selected Price 2 to be a custom promotion, so the alternate line items are opened up for manual entry. While this solution isn’t quite as elegant as the request from the SME, the core functionality is fulfilled.
The second step is to double-check the formulas and example data that is provided in the wireframe. Using your own knowledge of the business and the model, ask yourself if these specifications make sense and complement the workflow of the page.
The third step is going back to the SME with your proposed solutions to any functionality shortfalls and clarifying any questionable logic. If you can think of multiple solutions to work around a functionality shortfall, present all of them to the SME and have them pick their favorite.
After receiving sign-off from the SME, steps four and five are translating the wireframe into an Anaplan build and testing your build. These steps should go smoothly after taking the time to solidify the development request.
Once the build is complete, go one step further. Ask yourself how this data could be synthesized in a useful format for other user roles. Brainstorm with other users to explore new build opportunities. Keep that connected planning train going with stress-free development cycles!
What tips would you add as a wireframing best practice? Leave a comment!
Check out recent blog posts in Community:
- Anaplan Live! Recap for model builders and technical teams
- Custom views versus module views
- The three most useful applications of the data write action