APIs (application programming interfaces) play a crucial role in software development. Almost any programmer is often at the position of using thirdparty APIs. Currently, we find several researches that seek to explore and understand users interactions with the API from an usability point of view. However, such studies leave out an important aspect of an API quality of use, the communicability. Unlike usability, whose definition is associated with ease of use and learning, communicability is associated with an artifact s ability to communicate its design logic. An API that lacks communicability can lead users to misuse and produce bugs in their code. This doctoral thesis addresses this problem from a Semiotic Engineering perspective. By characterizing an API as a mediating artifact for communicability, we started our thesis with the proposal that APIs should be conversational. We diagnosed in our first study that users, in certain cases, have difficulty in understanding the internal operating logic of an API just by looking at its interfaces. In this study, we found that APIs often lack in communicability. While usability is about the user s ability to learn and use an API, communicability is about the API s ability to transfer the designer communication to the user, thus exposing its design rationale. A conversational API is the one that can expose its internal logic through its interfaces, attending the pragmatic contexts of its users. From this study, we then set out to define what a conversational API is in practice and to investigate what methods or technologies would be needed to assist designers in creating such APIs. In this thesis, we propose a conceptual framework and a method to support the design of conversational APIs. When designing an API, the designer has in hands three different ways to send his message to his user: the source code, the documentation, and the behavior of the API. Our conceptual framework explores how to characterize and classify a conversational API according to the three types of messages from the designer s perspective. Our method of supporting conversational API design, which was inspired by the results and lessons learned from an action-research we conducted, consists of three steps. The first step is to help the designer on identifying who the API users are and their specific conversational needs. In the second step, the method helps the designer on modeling possible API conversations with the different mapped users to achieve their goals. Finally, the method provides a set of guidelines to guide the designer in defining the API interfaces, including their parameterization. Using this method, we perform a case study with an API design, which aims at supporting the refactoring of Java programs. From the API designer s point of view, the method helped him on creating empathy with his users and better deriving and reflecting upon the requirements and conversations that the API should provide to the different user profiles.