DBS VOCUS Team Pain Points

• Time-Intensive Process: Extensive time required to manually analyze data prevents timely decision-making.

• Error-Prone: Manual handling increases the likelihood of errors, leading to potentially faulty conclusions.

• Data Overload: The vast amount of data from diverse sources makes it difficult to manage and interpret effectively.

• Lack of Standardization: Absence of standardized procedures for Product categorization and sentiment analysis complicates the process.

• Limited Sentiment Insights: Current methods do not adequately capture the nuances of customer sentiment, reducing the quality of insights.

Using the principles of the Double Diamond design process, we first diverged by independently developing our own design ideas. Each team member explored different concepts and approaches, allowing for a wide range of creative solutions. 

After this phase of exploration, we then converged by bringing our ideas together, discussing and refining them collaboratively. This approach ensured that we considered diverse perspectives before merging into a final, well-rounded design solution. 

Our Initial Problem Statements

💡As a member of the customer experience team, currently I have to desensitise and sift them out into different categories. 

"How might we classify and interpret Voice of Customer (VOC) data automatically from multiple sources to provide actionable insights that enhance the product team’s ability to improve customer experience"

However, we later realized that this problem statement did not address three key aspects or align with DBS’s needs. 

1. We needed to remove the term 'desensitise' from the problem statement

2. Shift the focus toward automation and accelerating the process

3. Emphasize that the solution should not require specialists; the key difference lies in automating the process.

Our Initial User Personas

Our Initial Lo-Fi Prototypes

Some of us even sketched it out on Paper, drawing from the knowledge in our previous Studio!

Our Initial Hi-Fi Prototype

We use React-Jest for comprehensive frontend application testing. Jest, a popular JavaScript testing framework by Facebook, provides test runners, assertion libraries, and code coverage reporting to ensure code correctness.

RSpec is employed for unit and integration testing in our Ruby-based environment 

Cucumber enhances our testing strategy with Behaviour Driven Testing (BDD) using the Gherkin syntax, which translates complex actions into clear, understandable language for the team.

Jest-Cucumber integrates Gherkin scenarios with Jest’s capabilities, converting high-level descriptions into executable tests.

The following is our final Cucumber report.

Behavior-Driven Development (BDD): We use BDD to ensure our features meet user expectations by defining clear, testable requirements.

Test-Driven Development (TDD): Our development process is driven by writing tests before implementing features, ensuring robust and reliable code.

Don’t Repeat Yourself (DRY): We adhere to the DRY principle to avoid code duplication and enhance maintainability.

Agile Methodology: Our project follows Agile practices, allowing for iterative development and continuous improvement.

Continuous Integration and Continuous Deployment (CI/CD): We use GitHub’s auto-deploy feature to streamline deployment and integrate changes seamlessly.

Fork and Pull Request Workflow: Each contribution is managed through a fork and pull request process to ensure code quality and facilitate individual contributions.