Our day-to-day dependency on digital applications to get a variety of work done, ranging from hailing a ride and ordering food to getting things done at work, is a living proof of the diffused presence of technology in our lives. Today, there are nearly 1.5 billion websites online, and 2016 alone marked the most dramatic increase(of about 0.5 billion) in the number. This provides us a clear picture of the increasing consumption of app-based products and services across various domains and therefore a higher demand for people who could develop them.
Since the last few years we are seeing exponential technological advances. And the community that is directly affected by the pressure of keeping up with these advances are the software developers. Owing to this intense competition to perform and deliver and at the same time stressing about keeping up with the new advances in tech to ensure a job security, developers are finding themselves at a very tough spot. More and more tracks related to ‘burn-out’ and ‘slowing-down’ have started to sprout at various software development related conferences.
Software developers have emerged as one of the biggest assets to a company’s success. Every business needs a team of software developers to work for them, and they all want the best. To be able to retain the best, it has become important for those companies to offer the most suitable working environment and developer centric practices at the workplace. Statistics show that by adopting DevOps practices, businesses have managed to reduce the overhead for their development teams, and thereby empowering developers to focus better and release good quality code at a faster speed. According to the The 2019 Accelerate State of DevOps report, adoption of DevOps practises emerged as a clear differentiator between more and less successful companies.
Heavyweight process and controls, as well as tightly coupled architectures, are some of the reasons that result in slower speed and the associated instability.
🧗🏻♀️ Where to go from here?
We have far graduated from the nascent concerns when designing for developers and goal has shifted from making developer’s job easier to enabling any one to become a maker. GitLab, a company that offer a DevOps platform for application development, has it’s strategy framed around a position — ‘Everyone can contribute’.
We believe that all digital products should be open to contributions; from legal documents to movie scripts, and from websites to chip designs.
A strategic direction such as this puts a sizeable responsibility on the product teams responsible for creating the toolchain to be mindful of making even the smallest of interaction accessible and non-demanding of any domain specific expertise, and at the same time provide enough power to advanced users. There are many different factors that play a big role in the design process for achieving this objective, let’s look at a few of them here:
👩🏻💻 Design for inclusivity
For a platform or tool to make contributors from varied walks of life feel welcome, a bare minimum is to break down any set of abstract or instructional information into an easy to understand format, and a proven way of doing that is to visualise it. If you are a part of the web or application development or design industry in any capacity, chances are you have already googled the term No code at least once, owing to the buzz it is creating around you. In a nutshell, No code is a GUI led application development approach that makes it easier for non-coders to contribute to the process. It allows for visualising the abstract entities such as development environment, languages, frameworks, APIs, services, etc., and present to the users as one comprehensive stage, creatively illustrating the relationships between the said components and highlighting their semantic function in the larger system. This approach takes a lot of cognitive load off a developer’s brain and allows them to make more creative decisions.
However, besides providing the ease of use, convenience and reduced complexity, there’s a much greater depth to this practice. By allowing people of varied expertise, demographies, capabilities and leanings to become creators of digital products, No code approach can bring in the long sought diversity and richness in the industry that has been lacking all along. This approach is a budding solution to smashing the tyranny of the manipulative algorithms present all around us and create a safer web space for communities of all sizes of representation.
👩🏻🏫 Design for learnability and discoverability
In my career as a product designer, spanning a little over five years now, I’m sure of having used about 30+ tools for different requirements such as research, designing and prototyping, presentation, data visualization, etc. at different times. I am fairly convinced that in the software development field, the dispersion of tools, languages, frameworks, libraries, practices, etc., is even more vast. This certainly implies that one couldn’t dedicate a lot of time and energy in educating themselves about a particular tool, and that’s where comes in the need to facilitate Autodidacticism in developer tools. In simpler words this means persuading developers to self educate themselves about the depth and vastness of the product by thoughtfully designing the user flow by progressively surfacing the advanced features as they get deeper into their workflow. In his essay Taste For Makers, Paul Graham writes Good design is suggestive. In the context of software application, this could be interpreted as — rather than providing all the information to users in one instance, provide only what’s needed to get started with and help them build upon it from there on.
The barrier to entry for a tool could be lowered by providing guided first steps to the user. This is however a very tricky part especially if the tool is being used by a wide range of users and not necessarily just developers. The learning curve for each kind of user might vary and all the effort of adding guidances and cues to the interface might not necessarily result in increased likability for the product. In such situations, it is recommended to align with the product direction and business values for designing a more focused solution.
👩🏽🎤 Design for humans
Let’s assume you are responsible for taking the design decisions for a highly complex tool for software development with hundreds of capabilities built into it. If you present this tool to your targeted user in its unfiltered form, they are very likely to be so intimidated by the looks of it that they would never care to explore to the next level. Every capability built into the product should not be presented to user at the same level. The key to designing the right solution is to make sure that the right problem is identified. An efficient way of arriving at the right problem statement is to approach it through JTBD(Jobs to be done). Looking at the user stories through the lens of JTBD provides the answer to a very crucial question — What is the user looking to accomplish with this product?
Following the identification of the problem statement, even if we start to design a concept by basing it on the insights received from the problem validation researches, there’s still a good chance that the research data is biased since a most part of human behaviour is unconscious and is not communicated well in the absence of a prototype. Iterative testing, that lies at the core of human centered design practices can helps us get rid of those biases in our designs in a progressive manner.
The importance of developers in an organization is not debatable anymore. Since developer tools is where software developers are likely to spend majority of their time on, enhancing their productivity should not be the end goal while designing them. These tools should be made available to developers in the form of a play space — allowing them to experiment, learn and grown besides accomplishing their everyday tasks, all without risking breaking the build or harming the infrastructure.
