Topcoder Design Series
I created this series to help all developers and designers to understand the unique process for crowdsource development and the modifications to design language, thinking, and process it requires.
Part 1 is covering the Topcoder Design language: a minimalist and opinionated approach to build a design system for modern web (and mobile) apps.
Part 2 is dedicated to the Topcoder UI kit: embodiment of the Topcoder design language as a collection of React.js components and practical approach towards component break down.
Part 3 is going to be talking about the Topcoder design process, from product research, ideation, concept creation, to final delivery and standards.
Why I created the series
The Product Development team at Topcoder is relatively new; I joined last in August 2015. Since then we had to start rebuilding the system from scratch. There were discussions to employ UI libraries like Bootstrap or Foundation to speed up the development, but ultimately decided against it. Some of the cons against were lack of specific components, and the sheer volume of code options of which we needed very little. This steered the decision to build our own library. There was a bit of engineering hubris in building our own component library, as well, I have to admit.
Since then we transitioned from Angular 1.4 to React.js, and we are still updating our stack to use the latest and greatest technologies. This transition also helped to further develop our current library of components, and refine the design language.
These technological race and transitions, as well the size of the Product Development team force us to be extra smart in the system we had to create. We use the help of the Topcoder community to build all our products, which means we run a lot of design and development challenges.
In a traditional software environment a project is developed by a team, and the project context is preserved via its collective knowledge. People may come and go, but never at such rate as to the whole group to lose the knowledge of the system. Constant communication between product managers, designers, and developers, helps people to solve problems “in motion”. There’s no need to follow the rules too strictly, as there’s always a way to go back and fix things.
Running challenges is the unique way Topcoder uses the community to deliver solitons for our customers. This means that projects are usually broken down into very small chunks and people work on them independently. Many different people will have to work on the same design and code base, without ever talking to each other.
This difference requires us to create a set of strict and simple rules everyone can follow. The lack of standards leads to differences in code style, repetition, code duplication, different implementation of the same elements multiple times. Our team cannot afford this, and we have as a priority to create and maintain the central platform repository.
In writing these pieces I tried to stay as focused as possible, so if you have any further questions or inquiries, or just want to say hi, find me at vic@topcoder.com
Don’t forget to check what we are doing at www.topcoder.com! We revolutionize the world through crowdsourcing design, development, and data science.
