For Dynamic Yield to build the use case you want, in the shortest amount of time, it’s important to fully scope out the requirements before development begins.
When compiling a scoping form, it is important to share the objective of the use case with the technical team that is building it.
Work with your CSM
- Define details regarding the use case description and hypothesis.
- The business context which allows the tech team to understand the idea and the goal behind the use case and optimize the technical decisions.
- How will you define success for the use case and which KPI you want to track: how many users engaged (ex. clicks, started a form, visited a PDP), how many converted (ex. revenue per user, conversion rate, AOV) or where users stopped in the flow (ex. users dropped after the second click) and on which device the use case will be experienced by your users
- Think of audiences: which groups will you want to analyze this test by to understand the performance?
What to include in an SOW
Designs: Proper use case designs should include specific details including measurements, colors, fonts, etc.
- Preferred design platforms: Zeplin, Figma, InVision, raw HTML, link to a component already on site
- Designs must include layout for all relevant device types (Mobile/Tablet/Desktop) and contain sizing in web format (px)
- Designs can be uploaded or shared via URL. Be sure files are shared with cs@dynamicyield.com so all team members can access them.
Variables: Components that you want your business team to be able to change without using any technical resources. Don’t forget to think about the next iteration of the campaign, what will you want to test next?
- Variables can be HTML, CSS, or JS
- For example, consider a CTA button. You may want the following variables to change on your own: background color, text color, text size, font, letter spacing, padding, text alignment, border radius, and hide/show.
Functionality: Outline any functionality information needed for the use case. Be as specific as possible, and include anything that may not be completely clear in the design mockup. Here are some examples of details needed:
-
Insertion Selector: If you’re unsure, be as specific as possible with the description.
- Is the selector the same on desktop and mobile?
- Page Types (Homepage, PDP, Cart) or URL(s) to place the campaign
- Specifications for each device type (Mobile, Tablet, and Desktop)
- If screen-specific, add Minimum and Maximum Breakpoints to Show
Testing:
-
URL(s) for testing: List which sites DY should be developing the use cases for
- Staging / production
- Specific locales or regions
- Specific ESPs, devices, and/or browsers if you have a preference
- Credentials for Test Environment (if applicable): If site credentials are needed, list them here.
- Additional Testing Guidance: If there are considerations for the environment, mention them here. For example, the staging section product feed has a limited number of products.
Evaluator or Feed Parser Use Case:
- Include as much detail as possible about the functionality needed within the Description. If unsure, thoroughly describe the solution desired and your Technical Account Manager will follow up with additional questions.
Submitting a Use Case
When you're ready to submit a scoping form, you can do so via the same screen you submit Support tickets, by selecting Use Case Scoping Form from the dropdown:
Additional team members needing visibility to ongoing communication can be added to the CC field.
Next, select the type of use case under Request Type and fill in the appropriate detail, with the above considerations in mind:
Upon submission, your CSM and TAM will review the request and may reach out with questions or need for additional detail via the Zendesk ticketing system. Please keep responses within the ticket and not via email.
Sprint Submission Process
Once the TAM has all detail and functionality of the use case outlined, they will submit it to the DY development team for a time estimate. The TAM will communicate the time estimate and all detail of the SOW for your review and approval. Please take the time to assure all stakeholders have reviewed the scope in full.
- Dynamic Yield’s front-end developers (CSE) work in 2 weeks sprints, starting every other Monday.
- Use cases are assigned to a sprint the Wednesday before a new sprint begins (the Sprint Assignment Date).
- SOWs must be approved by DY and the client before the Sprint Assignment Date.
- Any technical details omitted from the SOW will be considered out of scope
- No changes can be made after final approval without possible forfeiture of a slot in an upcoming sprint
- If multiple use cases are submitted in time for a sprint, DY may ask for prioritization when the sprint is near capacity. Our rule of thumb is two use cases per client per sprint.
- If a use case does not make it into an upcoming sprint it will receive priority in the following sprint.
Use Case Delivery and Review
All use cases go through testing and QA by Dynamic Yield before handover, but should also be tested by the client.
Upon completion of the use case, you will receive an update from your Technical Account Manager including testing instructions and specifics on providing feedback.
- Bugs (items that aren't working or correct per the SOW) can be added to the original use case ticket as a comment and will be worked on immediately. Bugs must be communicated within 1-2 weeks for resolution.
- Change Requests (requests outside of the finalized SOW) will require a new ticket filed as a , and will be added to the next sprint.