Editor’s note: For posterity’s sake, I’m reposting some content that we created during our time at Oracle. These statements and views are those of the author and do not reflect those of Oracle’s current user experience organization.
Developing concept products that embrace emerging technologies
Working with emerging technologies brings unique challenges for developers. There are few to no users out there one can ask about requirements.
The AppsLab, the Oracle Applications User Experience (OAUX) emerging technologies team, is a relatively small team of developers, yet the breadth of technologies we investigate is virtually infinite. We must respond quickly to accelerating technological changes.
We also walk the line between what is technically feasible and what is practical for our organization; we have to produce solutions that can be implemented in a reasonable time frame by Oracle’s product development.
Since a traditional development process doesn’t address these challenges, we apply certain techniques to our development process to help us move forward.
Hackathons as a Training Tool
Hackathons spawn lots of ideas, but for us they have an additional benefit. Their frantic pace closely resembles our development process, so we also use hackathons as a training tool. Hackathons are to developers what gyms are to athletes. We participate in them to improve our skills, we serve as mentors to hone our proficiency, and we judge the results to validate our expertise.
They are also a great networking tool for meeting likeminded developers who thrive on the same challenges that we do. We can then share tools and techniques.
Research-Driven Development Process
Research also plays a big part in our development process. We use it to test our own theories, determine trends, plan our strategic direction, and identify key initiatives to help product development see into the future.
But research doesn’t just drive what we build, it also influences how and when we build. The results of this research identify our requirements and prioritize them but also change them and make us adapt and pivot regularly.
Throughout our build process, we constantly validate our prototypes and products. Whenever we show our evolving prototypes to our research participants, they get new ideas.
As we refine our prototypes and repeatedly present them, study participants may get a clearer picture of possible use cases, which can invalidate previous ones. We actually encourage this behavior; our whole development process is built around constant iteration.
The idea is to iterate and improve the concept quickly or fail quickly.
Although a lot of what we develop may get thrown out at this stage, this is not “throwaway development.” At the very minimum, we learn something, even if it is how not to do something. All of the work gets shelved rather than trashed. It may be reused on other projects or even lead to completely new ideas, so the term “recycled development” is more accurate.
Because we’re focused on emerging technologies, some projects are just too early in the adoption cycle. So the code we write simply waits for the right time.
This is one of the reasons why we are so nimble. We try to reuse as much as we can — and not just our own code.
APIs as the Building Blocks of Rapid Development
Foremost, we focus on the users, not the technologies. Direct, primary research with end users is invaluable and indispensable in producing good user experiences.
We have become adept at using off-the-shelf solutions and combining them with new code to produce prototypes, which often means using other people’s work to launch our own projects.
In software, the most granular off-the-shelf components are APIs. An API is a neatly wrapped functionality that is available to a developer. Instead of having to build something yourself, you can leverage what is already out there for a fee and assemble it any way you see fit. This is analogous to how car manufacturers create cars. They don’t mill steel or build engines, tires, or windscreens; others produce these. The car manufacturer assembles the pieces into a working car. APIs allow you to do the same when building applications.
For example, our team did this type of project with the “Oracle Voice” prototype, a voice-driven virtual assistant for the Oracle Sales Cloud. Its features include speech-to-text, text-to-speech, natural language processing (NLP) and various Oracle Sales Cloud functionalities. Despite the complexity of all of these components, we built a fully working application and put it in front of test subjects for feedback in less than a week.
Email, payments, phone, texts, authentication, and authorization are all available as a service and easily accessible using REST APIs, and more complex APIs are being added, such as facial recognition, image understanding, and machine learning. These allow us to build intelligence into our prototypes quickly and without much effort.
Show and Tell
Our work is permanently on display in the Cloud UX Lab at Oracle headquarters in Redwood Shores, Calif., and customers pass through almost every day. We also show our products at events across the world, we speak at conferences, we organize and participate in hackathons, we discuss strategy with industry analysts, we host workshops at universities, and we educate Oracle partners.
All these activities provide us with immediate feedback, which is an integral part of our development process. That allows us to continually iterate and adjust the development of our concept products, adding in new emerging technologies and dropping less relevant ideas as they fade on the spectrum of our interests.