What
Redesign existing platform for building and evaluating voicesTo comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. 
Outdated platform with a lot of unnecessary functionalities. When users start using thisplatform they use their own documentation. People rather avoid using this platform (Program Managers). When it comes to build voices they have no idea which parameters they should use, usually they depend on their notes.
Problem statement
Iterative Prototype Testing
We’ve had a lot of testing design prototypes before rotting a code. At an early stage, we were engaging our users into new product and asking a lot of questions. We started with low-fidelity, black-white wireframes for content planning then shifted to high-fidelity prototypes before doing any customer testing.
Design Process
Research 🕵️♀️
Define the problem
Talk with users
Review Competition
Product Concept 👩🎨
Hand-draw ideas
Low&high-fi wireframes
Customer testing
Design 👩💻
Analyse current platform
Information Architecture
User flow
Research
During my interviews I've been speaking with people who work in different positions :
1. Audio Engineers - they are responsible for building voices. The current platform causes a lot of errors, loading time is long and there is a lack of a clear path for them.
2. Scientists -they evaluate voice, which means they need to check if the particular voice is natural and out of errors. They wrote their own documentation about how to use this platform.
3. Program Managers - the whole platform is too complex for non-technical users. They’re afraid to use the platform. All important information about voices for example data completion for customers they put in an internal tool and track the whole process of the project there.
1. Demonstrate credibility
2. Create an appealing and minimalistic product : enhancing the visual design, but only if visual design supports usability.
3. Maintain access to primary tasks.
Moreover : based on existing surveys platform doesn’t require basic accessibility for instance keyboard navigation.
Product Concept
Project - place where we store all information about Voice like relevant dates, owner, evaluations, amount of voice builds, etc. In order to build a Voice we need to a build technology tand choose evaluation. During a lot of brainstorming, we made a decision that a PROJECT it’s a main place for each group of users and within the project, there are voice builds and evaluations, which at the very beginning we divided into two tables (Voice Builds and Evaluations), but finally we came up with the new name - Workflows. After first testing with users I found out that it’s not clear for users where they can add “New Workflow and the current path it’s too long. I decided to add a button “New workflow on the project list - that’s the first view after logging - the user can choose a project and then add a new workflow for this project. I went with the same concept for Voices - a voice list with a table and buttons “New Project and“New Voice . Users can easily add a new voice for a chosen project or/and add a new project. After clicking new project there’s a wizard and option for choosing a voice for a project. The next problem I encountered during interviews - was parameters for build technology and evaluations. Users depend on previous parameters which worked well and they are careful with using new data for parameters. They don’t know exactly which parameter stands for. Based on this I decided to put this into the final step after adding a new workflow. There are expandable sections for editing build technology and evaluations. Users can either edit or not becauseparaders have default values. Advances users are welcomed to dig deeper into parameters :))
Design
While I was designing my concept I was using Amazon’s design system to ensure wide consistency. Below I present Architecture Information, which will help you visualize the solved problem.
