I worked as a Software Design Intern at IBM before my senior year of school. The work was for a yet to be released project, so I won’t be able to discuss too much here.

At a high level, I worked with a team of interns and designers to build a product from the ground up. I was actively involved in field research, interviews, user testing, prototyping and interaction design.

Thoughts on Design Systems

Design systems became quite trendy in 2016. A design system refers to the philosophy that a set of predefined instructions can be used to design multiple products.

IBM’s design system is the eponymous IBM Design Language. The benefits of working with such a system were clear. By adhering to the rules, I saved time that otherwise would have went towards repeated styling of the same elements. The language also ensured consistency throughout the products that were coming from different product teams.

Yet, I kept on running into corner-cases, in which sticking to the rules would have confounded the user. The choices were:

  1. Deviate from the system with an ad-hoc design. The gatekeepers of design purity will cry foul.
  2. Keep with the system. The entire experience is unified. Cross my fingers and hope the result won’t be problematic for anyone.

We love to systemize things. We don’t want to confuse our users by coming up with something different for every problem. Dictating a design system at the start however, can reveal local gaps that the system doesn’t cover.

Design systems should be instructive, not prescriptive. With the gradual move towards standardization of everything though, I believe it’s imperative that we keep our systems flexible, adaptable, and user-centric from the start.


2018 Kevin Ma