Watson is IBM’s answer to the AI race that has been taking place in the tech industry in the last couple of years. First introduced in 2011 as a participant in the American gameshow Jeopardy, Watson quickly became a core focus and investment of IBM and its cognitive capabilities have been integrated into language translation, healthcare, banking and others.
This project was created during the first half of IBM's 2015 Fall Design Bootcamp. The team was asked to look into the current Watson Development Cloud website and improve the developer's experience of testing and understanding the APIs, with a focus on three primary ones – Speech to Text, Text to Speech, and Language Translation.
As one of the two visual designers on the team, together with Patrick Lowden, we worked on crafting the information hierarchy and emotional impact of the interface. Apart from that, we were also tightly integrated into the initial process of the design research involving competitors’ analysis, design thinking process, and user interviews.
In the course of four weeks we conducted research into the capabilities of the APIs and how they integrated with the workflow of our core front-end developer user persona Jeff. Through number of interviews and alterations, we managed to come up with a solution, which provides Jeff a more seamless way of getting access to the APIs and the way they interconnect.
Previously, the website didn't provide many points of access to the various Watson APIs that can be used and combined. We fixed this by simply linking the rest of the services from the sidebar of the sandbox with the opportunity for other Watson services to be added. This, combined with the history of results that the user has called in the “Response” panel, aimed to enhance a more holistic understanding of the opportunities that devs have.
Information inputs were integrated in the “Request” panel, thus giving the users’ the opportunity to tinker with the code and test results. Our research highlighted that developers need to experiment with code as a main method of understanding the capabilities of the framework, in contrast to purely gaining knowledge from documentation, which is used for mostly for referencing.