Ideas like vectors
Building for scale, a Colab and Figma Africa story
One of the things I have come to learn since I got to Colab is looking at ideas from a new perspective, Sanusi basically has ingrained a doctrine of problem-solving into us. Simply put “what problem are you trying to solve.. what need is being met with this product”.
Hang around him a few munites after he has said those words and he is sure to talk about scaling. Great products scale. There is really no argument there, only scalable products and business have the ability to become fortune 500 companies, and to be honest for Africa to get out of this unholy economic mess, we need a lot of those here.
So on the 23rd of March 2019, Colab and Figma Africa put something together, we decided to go beyond design and talk about what it means to build for scale. We kicked off with talking about basic principles for business and how the right foundations should be laid to allow scaling happen seamlessly.
Robert John talked about software architecture and how it should be taken into consideration when building. A product that serves just 100 people has to be built differently from a product that is to serve 1000000 people simultaneously, yet they might be solving the same problem, just at different scales.
I should also add at this point that pixels pushed and created can also affect the software architecture that would be implemented. For instance, something as simple as a profile picture and profile ranking system might take you as a designer 5 mins to implement but might take the engineering team a few days to implement especially if it was not in the initial prototype that was given to the engineers.
Well, you cannot talk about building software products at scale without design systems. Design systems go beyond style guides, components and pattern libraries, they play a great role in erasing the communication gap between Designers and Software Engineers, by speaking a common language, both teams have the ability to work without friction and to build rapidly.
The difference between a style guide and a design system is in the standards and documentation that accompanies the assets. With a guide on why and how to use them, design components because easier to use and clearer to discern.
Another amazing thing about design systems is how it enforces design consistency, which is great. When the designers are not in the room, and other teams are trying to brainstorm ideas on new features, they can put components together from the design system and simply create something amazing and of high fidelity without breaking away from the brand identity or creating something that appears inconsistent. This greatly reduces the bottleneck that comes with product development.
So yeah, I spoke about design systems extensively. You can also read a quick intro to design systems below.
This story really won’t do enough justice to the topic, so you can take a look at my slides on design systems here.
Well, you have gone through the process of identifying the problem you want to solve, the software architecture you plan to implement and also created a kickass design system, but how then do you get this product into the real world? If you do ship, you cannot have users and without users, you can never scale.
Kabir Shittu, the co-founder of Payant technologies, an active player in the FinTech space spoke on startup operations. It was an extensive conversation on how operations transform resource or data inputs into desired goods, services, or results, and create and deliver value to the user(s). Follow the link below to fully grasp what he spoke about.
Going past design, it is important that we understand the process involved in building products that scale, this would greatly optimize our individual and collective roles when building.
Find more images from the meetup below.
