Note on legacy behavior: 'Service' renamed to 'Application'
What previously was called Services within the BRYTER platform is now renamed to Applications making it more self-explanatory and convenient for our customers.
Further, Service Frontends are now referred to as Publish Applications.
The design process is about designing and prototyping and making. When you separate those, I think the final result suffers. – Jonathan Ive (former Head of Design at Apple)
In our best practice article Building better modules in BRYTER by using the MVP Approach, we have introduced our approach when building modules and Applications with BRYTER. We employ the Minimum Viable Product (MVP) approach for our demo modules and recommend it to customers - especially, for larger projects that involve several stakeholders like a Legal Engineer or Innovation Manager acting as the BRYTER author of a module and a Partner or General Counsel providing the idea and content of a digital solution to be built with BRYTER. With the introduction of Applications in BRYTER, most automation ideas tend to comprise several modules and databases and are sometimes targeting different user audiences.
Great BRYTER Applications are providing value, offer a comprehensive solutions and create memorable experiences and allow service professional, experts and lawyers to tap into the digital Applications market:
“Services have come to dominate our economies. Whether you manage a traditional service firm or a manufacturing company, adding value through services has become an essential way to compete. […] Today customers are looking for service value, comprehensive solutions, and memorable experiences."– Gustafsson and Johnson, 2003
Great BRYTER Applications, however, tend to be more complex and require more planning or even full-blown project management effort. When planning a BRYTER Application, our typical process follows the tenets of the Software Development Cycle (SFDC) . In this guide, we will draw on several scientifically proven frameworks to outline the best way from idea to prototype (and implemented Application).
Each phase of the seven phases outlined in the Software Development Cycle is presented in a recorded webinar and complimented by additional helpful material and resources to help you build successful Applications successfully.
ℹ Note: The phases below will be accompanied by a webinar series and additional helpful resources after each webinar has been recorded and uploaded.
Phase 1: Ideation and Planning
View our complimentary webinar here or below:
This first phase is dedicated to fully understand the scope of the problem you want to solve and how the anticipated solution could look like. After the problem has fully been scoped, you can also start estimating the required resources, costs, time spent, and the expected benefits for the next phase. This phase is a crucial requirement for all following phases as it helps understanding who should be involved, when they should be involved, and how they can contribute.
During ideation, authors should also critically assess whether the idea is suitable for automation, to be offered as self-service Application, and if BRYTER is the right tool for all steps of the process or if additional integrations and tools should be part of the Application.
When planning the Application authors should structure their idea and create a rough overview of the process steps and which stakeholders are involved (process mapping).
Phase 2: Requirement Analysis
View our complimentary webinar here or below:
During this second phase, you would work with the subject matter experts or the people reporting the problem that they would like to solve with a digital Application. It always helps to create a list of the requirements and to define the delivery dates or milestones for a prototype and the final solution.
Sketch a plan with milestones and your 'deliverables' for all involved stakeholders and regularly compare the status quo against the defined plan.
Phase 3: Design and Prototyping
In the third phase, you are starting to define how the finished product should look like, especially how the results should be displayed and what they contain. It's important to create a minimum viable product (MVP) or prototype of your solution and discuss with the subject matter experts. The feedback gathered during these discussions will inform the next development stages and help re-adjusting requirements early on. With an MVP approach, you easily avoid spending too much time 'going the wrong direction' and adjust requirements or redefine and sharpen the original problem statement as you go.
Phase 4: Development/Building
This fourth phase is dedicated entirely to building out the module(s) and incorporating the feedback you received in the previous phase. If necessary, think about and decide how to split building separate modules and when to combine them.
💡 Tip: Have a look at our 📺 Best Practice Webinar for BRYTER Authors: Work collaboratively on Modules)
During this stage, you should ideally only publish your modules to TEST in order to keep TEST and LIVE data and sessions stats separated.
Phase 5: Integration and Testing
If you identified the need for integrations or databases, you should set these up once your module structure has proven to be successful and will not be changed too much. In this fifth phase, you are performing tests amongst the team of BRYTER authors and you are ironing out the last inconsistencies and choose or adapt the theme to ensure good UX.
💡 Tip: Have a look at our recorded 📺 Best Practice Webinar for BRYTER Authors: Good UX and our short guide on Building user-friendly modules.
It's critical to provide your subject matter experts with a link to the module(s) and/or data views while they are still in the TEST environment so they can test the content, and its logic and approve the chosen visuals and theme decisions.
Phase 6: Implementation and Deployment
Once testing is completed, it's time to kick off the sixth phase dedicated to publishing your module and sharing it with selected beta-testers who haven't been involved during the development process. During this phase, you should decide on how to deploy or embed your solution. Decide and test where users would access your solution. Your website developer or MS Sharepoint team can assist you during the iFrame-embedding process.
You should also ensure that your access settings are set correctly in your LIVE module(s) to ensure that only users who should have access to the solution, can use your modules.
Phase 7: Delivery and Maintenance
The seventh and last phase is an ongoing task. You are now rolling-out the module(s) to all users and should keep track of responses and drop-out rates via the module session stats or with case databases and data views.
To ensure that any support requests or queries and potential changes in the legislation or regulation are reflected in your published module(s), you should define regular audit and maintenance dates to ensure module is up-to-date.