[pt] APIs (do inglês - application programming interfaces) desempenham um papel crucial no desenvolvimento de software. Quase todos os programadores estão frequentemente na posição de utilizar APIs de terceiros. Atualmente, encontramos várias pesquisas que procuram explorar e compreender as interações dos usuários com a API do ponto de vista da usabilidade. No entanto, tais estudos deixam de fora um aspecto importante da qualidade de uso de uma API, a comunicabilidade. Ao contrário da usabilidade, cuja definição está associada à facilidade de uso e aprendizagem, a comunicabilidade está associada à capacidade de um artefato de comunicar sua lógica de projeto. Uma API que carece de comunicabilidade pode levar os usuários ao uso indevido e produzir bugs em seu código. Esta tese de doutorado aborda este problema a partir de uma perspectiva de Engenharia Semiótica. Ao caracterizar uma API como um artefato mediador da comunicabilidade, começamos nossa tese com a proposta de que as APIs deveriam ser coloquiais. Diagnosticamos em nosso primeiro estudo que os usuários, em certos casos, têm dificuldade em compreender a lógica interna de funcionamento de um API apenas olhando para suas interfaces. Neste estudo, descobrimos que as APIs muitas vezes carecem de comunicabilidade. Enquanto a usabilidade é sobre a capacidade do usuário de aprender e usar uma API, a comunicabilidade é sobre a capacidade da API de transferir a comunicação do projetista para o usuário, expondo assim sua lógica de projeto. Uma API conversacional é aquela que pode expor sua lógica interna através de suas interfaces, atendendo aos contextos pragmáticos de seus usuários. A partir deste estudo, nós nos propusemos então a definir o que é uma API conversacional na prática e a investigar quais métodos ou tecnologias seriam necessários para auxiliar os projetistas na criação de tais APIs. Nesta tese, propomos uma estrutura conceitual e um método para apoiar o projeto de APIs de conversação. Ao projetar uma API, o projetista tem em mãos três maneiras diferentes de enviar sua mensagem ao seu usuário: o código fonte, a documentação e o comportamento da API. Nossa estrutura conceitual explora como caracterizar e classificar uma API de conversação de acordo com os três tipos de mensagens da perspectiva do projetista. Nosso método de apoio ao projeto da API de conversação, que foi inspirado nos resultados e lições aprendidas de uma pesquisa-ação que realizamos, consiste em três etapas. O primeiro passo é ajudar o projetista a identificar quem são os usuários da API e suas necessidades de conversação específicas. Na segunda etapa, o método ajuda o projetista na modelagem de possíveis conversas de API com os diferentes usuários mapeados para atingir seus objetivos. Finalmente, o método fornece um conjunto de diretrizes para guiar o projetista na definição das interfaces API, incluindo sua parametrização. Usando este método, realizamos um estudo de caso com um projeto de API, que visa apoiar a refatoração de programas Java. Do ponto de vista do projetista da API, o método o ajudou a criar empatia com seus usuários e a melhor derivar e refletir sobre os requisitos e conversas que a API deve fornecer aos diferentes perfis de usuários. / [en] 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.

[pt] O Lean Communication-Centered Design (LeanCCD) é um processo de design de Interação Humano-Computador (IHC) centrado na comunicação, que consiste na realização de um workshop, detalhamento de metas de usuários, combinação de modelos de interação com esboços em papel simulados com usuários, apoiados por guias e quadros. A IHC é uma área que estuda o projeto e uso de tecnologia computacional, em especial a interação entre computadores e pessoas. Este estudo adaptou o Communication-Centered Design (CCD) e o eXtreme Communication-Centered Design (eXCeeD), outros processos de design centrados na comunicação fundamentados na Engenharia Semiótica (EngSem). A EngSem é uma teoria de IHC que define a interação como um processo comunicativo entre designers e usuários mediado por computadores. Abordagens e processos fundamentados nessa teoria buscam favorecer a reflexão através da adoção de modelos, questões e métodos que não gerem diretamente uma resposta ou solução para o problema, mas apoiem o designer na exploração do espaço e da natureza do problema, bem como das restrições sobre soluções candidatas. A avaliação do LeanCCD em um estudo de caso na indústria observou dificuldade na condução das atividades e na aplicação correta de algumas técnicas e conceitos. Porém, diferentemente do eXCeeD, percebemos o uso sistemático das questões que favoreciam a reflexão devido ao auxílio dos quadros e guias propostos. / [en] Lean Communication-Centered Design (LeanCCD) is a Human-Computer Interaction (HCI) design process, which consists of conducting a workshop, detailing user goals, combining interaction models with paper sketches, and testing them with users, supported by guides and templates. This study adapted the Communication-Centered Design (CCD) and the eXtreme Communication-Centered Design (eXCeeD), other communication-centered design processes grounded on Semiotic Engineering (SemEng). SemEng defines the interaction as a computer-mediated communication process between designers and users. Approaches and processes based on SemEng are not used to directly yield the answer to a problem, but to increase the problem-solver s understanding of the problem itself and the implication it brings about. Process evaluation in a case study, in the industry, proved itself difficult, both in carrying out LeanCCD activities and in the correct application of some techniques and concepts. However, unlike eXCeeD, we were able to observe a systematic use of questions that contributed to designers reflection, aided by the proposed templates and guides.