Agosto 2018

Aplicar ‘Product Thinking’ a UX

A vida é curta demais para construir algo que ninguém quer.

- Ash Maurya in “Running Lean: Iterate from Plan A to a Plan that Works”

UX/UI na Xpand IT

A Xpand IT tem investido nos últimos anos na oferta de serviços UX/UI, o que resultou num crescimento significativo do nosso portfólio HCI (Human Computer Interaction) em software aplicacional B2B e B2C e aplicações móveis em clientes portugueses e estrangeiros.

Os nossos interfaces e design de experiência de utilização, desde sempre baseados no conceito de Design Centrado no Utilizador, estão presentes em praticamente todos os setores de atividade: retalho, banca, telecomunicações, seguros, saúde, transportes, e-commerce, mobilidade, utilidade pública, entre outros.

Estamos preparados para os próximos desafios da experiência de utilização em produtos digitais – por exemplo, propomos e desenhamos cada vez mais CUI (Conversational User Interfaces) – mas deparamo-nos ainda com vestígios de uma mentalidade não totalmente alinhada para o pensamento de produto digital, mais preocupada em desfilar uma enorme quantidade de requisitos funcionais, por vezes totalmente desadequados das necessidades do utilizador final do produto.

A experiência de imediatismo oferecida, sobretudo, pelas aplicações de social media, está a transformar as nossas expetativas em relação à forma como queremos utilizar produtos e serviços digitais. Enquanto UX designers, sentimos necessidade de analisar o ecossistema completo que as marcas e os utilizadores compartilham, para definir como o negócio ainda pode ser relevante num mundo onde o imediatismo é rei.

O Design Centrado no Utilizador – com a sua mentalidade de trazer os utilizadores para o processo de design – existe para reduzir as lacunas entre quem cria um produto e quem o está a usar.

A equipa de UX da Xpand IT está focada em encontrar essas lacunas, preveni-las e eliminá-las.

Pensar o produto

Na sua abordagem tradicional, o design de UX/UI tem-se concentrado nas funcionalidades de um produto digital: qual o aspeto do interface (UI) e como os utilizadores interagem com ele (UX).

No entanto, um conjunto de funcionalidades é apenas uma pequena, frágil, parte de um produto: são algumas das muitas soluções possíveis para o problema que o produto tenta resolver.

Não é que as funcionalidades não sejam importantes, mas geralmente são secundárias em relação ao motivo pelo qual as pessoas usam um produto. Essa razão é simples: o utilizador usa o produto para resolver um problema específico do mundo real.

Na prática, isso significa que temos de compreender o produto primeiro. Uma funcionalidade pode (ou não) ser uma parte útil de um produto, mas sem o produto, essa funcionalidade poderá ser desperdiçada.

Por exemplo, a app da Uber é frequentemente usada como uma boa referência de design de experiência do utilizador: uma das funcionalidades que cria mais empatia é a contagem regressiva que informa o tempo que resta até à chegada do carro, o que certamente é conveniente e está relacionado com o objetivo da aplicação. Mas o que torna a Uber tão atraente é a capacidade de obter rápida e facilmente um transporte na sua área a qualquer hora. Mesmo que a funcionalidade de contagem regressiva não existisse, a aplicação ainda seria útil. Por outras palavras, a Uber foi pensada tendo em mente o objetivo do produto, não os recursos que o acompanham.

A aplicação de Product Thinking à experiência do utilizador tem tido uma adesão global pelos UX designers e ganhou dimensão quando profissionais de reputação internacional – como o alemão Nikkel Blaase – a trouxeram para uma esfera mais alargada de divulgação pública. A propósito, esta talk poderá ser um bom ponto de partida para aprofundar o tema.

Definir o produto

De um modo geral, as empresas tendem a assumir que quantas mais funcionalidades houver, mais utilidade terá o produto. Que quanto mais abrangente for o público-alvo, mais pessoas irão utilizá-lo. Que quanto mais cenários de uso forem mapeados, mais ele estará presente na vida das pessoas.

O que não é necessariamente verdade: o que não faltam por aí são produtos com toneladas de funcionalidades que não são usados por ninguém.

Um erro muito comum é começar imediatamente por desenhar algum tipo de interface.

Mas, se o problema do utilizador não está ainda identificado, porque é que se está já a pensar em funcionalidades e interfaces?

É justamente neste ponto que muitos produtos digitais falham: quando tentam resolver um problema que não existe.

Entender a fundo o problema, quem é o utilizador e de que forma o produto irá resolver esse problema, precisa de vir antes da solução que será encontrada para o resolver.

No entanto, o processo de criação de produtos digitais tem tendência a ser um pouco caótico: dentro de uma empresa são diversos os departamentos, áreas e negócios que têm opiniões diferentes sobre aquilo que o produto deve ser, para quem deve ser desenhado e, principalmente, que funcionalidades deve conter.

Deve-se, por isso, realizar uma reflexão profunda para definir com clareza o âmbito e os requisitos de um produto digital:

  • Porque estamos a investir neste produto? Qual a oportunidade de negócio em criar este produto? Que dados e estatísticas comprovam que o produto é viável?
  • O que é o produto? Qual a sua principal funcionalidade? Como se destaca da concorrência?
  • Para quem se vai criar o produto? Qual o perfil do utilizador típico? Que comportamentos ou necessidades específicas desse utilizador devem ser tidos em conta?
  • Onde e quando o produto será usado? A que horas e com que frequência? Em casa, no trânsito, no trabalho? É um produto de uso constante ou algo para usar uma vez só?
  • Como queremos que as pessoas usem o produto? O que queremos que as pessoas sintam ao utilizá-lo? Que problemas queremos resolver?

Encontrar a resposta correta a estas perguntas constitui a estratégia básica da definição de um produto e provoca alinhamento entre as várias áreas de negócio das empresas. Este processo, quando bem conduzido e auxiliado por designers UX, traz enormes vantagens:

  • Construir funcionalidades e interfaces corretas para o utilizador.
  • Entender a experiência como um todo, não apenas a camada visual e de interação que o utilizador verá.
  • Garantir que o produto resolve problemas reais dos utilizadores.
  • Mitigar o risco de construir algo que ninguém queira usar, ou que não dure por muito tempo.

Conclusão

Quando este tipo de pensamento sobre o produto faz parte do processo desde o início, os designers UX podem fazer as perguntas certas, comunicar com mais eficiência e sugerir as funcionalidades mais adequadas.

É fácil ficar atolado em funcionalidades infinitas e ignorar algumas das partes importantes do processo de design.

Evite as potenciais armadilhas de se concentrar apenas nas funcionalidades, em vez da usabilidade do produto, tornando o pensamento do produto parte do processo de design UX da aplicação móvel ou web. Não há nada de errado com as funcionalidades, mas elas não devem tornar-se mais importantes do que o objetivo real do produto.

Tenha isso em mente e o resultado final será um produto digital criado, testado e personalizado para o público-alvo definido, com maiores probabilidades de se tornar indispensável e tornar a vida dos utilizadores mais fácil.

Carlos Neves

Senior Ux & UI Consultant, Xpand IT

Carlos NevesAplicar ‘Product Thinking’ a UX
read more

Kotlin e um futuro (ainda mais) brilhante

Imaginem um mundo muito estranho chamado “A JVM”.

(A partir deste momento, o melhor é ler com a voz de David Attenborough).

No início, existia uma única criatura. O seu nome era Java. A Java era divertida, nova, simples, poderosa… mas a Java não era suficiente. Outras espécies surgiram, tais como: Ceylon, Groovy, Scala, Clojure, Frege, Kotlin. Até a Java evoluiu com o tempo! Mas porquê tantas espécies? – é uma questão que vos pode surgir. Será que o Criador falhou na sua própria criação? Estariam os outros deuses (os programadores) descontentes? Talvez não estivessem felizes o suficiente… Quem sabe?

Então… Este é o caso de Kotlin.

Mas chega de analogias a A Vida na Terra. Ainda assim, podem continuar a ler com a voz do David Attenborough, todos sabemos o quão incrível é.

Ainda assim, a questão que se coloca é: mas porquê outra linguagem de programação para JVM? A isso não posso responder, porque não sei. No entanto, acredito ter alguns argumentos que possam ajudar a explicar porque é que Kotlin é um espécimen muito forte.

A Evolução de Kotlin

Embora pareça, a linguagem Kotlin não é totalmente nova. A sua primeira aparição aconteceu no dia 8 de novembro de 2010 e, desde então, tem amadurecido com o tempo, tal como um bom Whiskey.

A adoção desta linguagem tem aumentado significativamente ao longo dos últimos meses, impulsionada pela referência em grandes eventos, como o Spring Framework 5.0 ou o Google I/O 2017, no qual a Google anunciou o seu apoio oficial a Kotlin para a plataforma de Android. 2017 foi também o ano da primeira KotlinConf, na qual ficou claro que as potencialidades de Kotlin vão muito para além do mundo Android.

É curioso ver o número de questões relacionadas com Kotlin a aumentar no StackOverflow, depois do anúncio feito pela Google e pelo facto de agora aparecer no TIOBE Index.

Quanto aos projetos open source no GitHub – segundo o GitHut 2.0 – num ranking de 50, Kotlin pontua da seguinte forma:

  • 16º lugar para project stars, num total de 0.480%;
  • 17º lugar para issues, com um total de 0.489%;
  • 23º lugar nos pull requests, perfazendo um total de 0.351%;
  • 19º lugar para pushes, totalizando 0.424%.

Verifica-se que o crescimento, no geral, é bastante positivo.

Interoperabilidade com Java

Kotlin destaca-se em relação a outras linguagens de programação principalmente pela sua abilidade de interoperar de forma simples com Java no runtime JVM.

Esta linguagem tem também possibilidade de compilação para Java Bytecode e adiciona praticamente zero overhead, sendo possível compilar para versões 6, 7, 8 e 9 de Java Bytecode e, ao mesmo tempo, tentar extrair vantagens das características de cada versão. Um bom exemplo do poder de Kotlin é o suporte que dá às expressões Lambda, mesmo quando compiladas para Java Bytecode 6.

Tooling

Kotlin foi desenvolvida pela empresa JetBrains, que acabou por torná-la numa linguagem first-class citizen no IntelliJ IDE, Android Studio e CLion. Inclui features como refactoring, geração de código, code completion, compilação para bytecode e sneak-peeking ao bytecode on the fly, e, até mesmo, um conversor de Java para Kotlin. Tudo ao vosso dispor.

O compilador (kotlinc) tem um modo REPL que pode ser utilizado para testar facilmente alguns snippets de Kotlin the forma interactiva.

Targets Multiplataforma

Utilizando Kotlin é possível compilar para JVM, Javascript e LLVM.

Vou reformular a frase para que percebam o meu ponto:

“Programar em Kotlin e obter o código server-side para distribuir em JBoss, partilhar código referente à camada de lógica aplicacional com a aplicação Android, e, ainda, com a webapp JS/HTML. Oh! E não vamos esquecer aquele device de IoT, vamos partilhar algum código com ele também. Como assim? Também partilhar a lógica com a aplicação iOS? Claro, porque não!”

Kotlin/ Native tiram partido de LLVM de forma a facilitar o suporte de forma nativa de um vasto número de plataformas como Windows, Linux, OSX, iOS, Android e WebAssembly.

Kotlin para JavaScript permite a transpilação de Kotlin para linguagem JavaScript, tornando possível, por exemplo, a criação de web apps de React.

Um ótimo showcase destas características é a aplicação da KotlinConf 2017, que foi inteiramente implementada com recurso a Kotlin, desde o backend, ao frontend e aplicações móveis.

Aceitar Kotlin como uma equipa

Começar a utilizar Kotlin não tem de ser uma decisão arriscada! Por natureza, Kotlin funciona incrivelmente bem com o código Java existente e é até possível ter código Kotlin e Java no mesmo projeto. Desenvolver novas características em Kotlin num projeto existente pode ser uma excelente abordagem para proceder à adoção com um risco mínimo, já que não existe a necessidade de começar tudo de novo por causa de uma nova linguagem ou tecnologia.

Utilizar Kotlin tornou-se numa realidade diária para os Android developers. A maioria dos GDEs (Google Developer Experts) defende e utiliza Kotlin diariamente e pode ser encontrada bastante informação sobre esta linguagem na documentação oficial de Android.

Para os developers fora do universo mobile, por exemplo, os backend developers, Kotlin apresenta-se, não só como uma forma de alcançar os padrões standard de atuais linguagens de programação na JVM, mas também como um substituto para a linguagem Java na sua totalidade. Projetos como o TornadoFX, Ktor, Spring, entre muitos outros, oferecem as bases necessáras para que a linguagem Kotlin possa triunfar fora do domínio mobile. E uma vez que Kotlin é praticamente 100% interoperável com Java, os programadores podem continuar a utilizar as mesmas frameworks às quais já estão habituados mas com a felicidade que a sintaxe de Kotlin oferece!

As abordagens mais comuns para a adoção de Kotlin são:

  • Reescrever os testes de unidade Java com Kotlin. Muitos concordam que esta é uma ótima abordagem para começar a mexer em Kotlin, sem colocar em risco o código que vai para produção. Kotlin oferece alguns truques que permitem tornar os unit-tests mais legíveis e compactos.
  • Quando projetar novas características, em vez de utilizar Java, recorra a Kotlin!
  • Se o projeto em que está a trabalhar se deve a um refactor, aplique Kotlin à nova versão reescrita do código base.
  • Entregue-se totalmente a Kotlin e deixe para trás os dias tristes dizendo adeus a Java!

Linguagem Kotlin

Esta linguagem, em si, é maravilhosa. Kotlin é uma linguagem fortemente tipada, e que tem como principais objetivos ser concisa e legível.

Esta tenta também resolver um dos principais objetivos no mundo Java: NullPointerException. Torna a nulabilidade parte do sistema e força os developers a pensarem explicitamente sobre os seus impactos.

Outro aspeto que torna Kotlin uma linguagem extraordinária é o facto de permitir que os autores possam transportar as melhores carateríticas de outras linguagens para Kotlin. Para nomear algumas:

  • Extension Functions
  • Destructuring declarations
  • High Order Functions
  • Type Inference
  • Functional Facilities (map, filter, flatmap, etc)
  • Custom DSLs
  • Named parameters
  • Pattern Matching
  • Operator Overload

Sintaxe de Kotlin

Aqui ficam alguns trechos de código Kotlin. Um pequeno sneak peek. Estes tentam mostrar quão simples é a linguagem Kotlin, quando comparada a Java.

Java Kotlin

// Class definition

class Person {

private String name;

private int age;

public String getName(){

return name;
}

public int getAge(){
return this.age;
}

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String greet(){
return “Hi ” + this.name + “, how are you doing?”;
}
}

// Class definition

class Person(val name:String, val age:Int) {

public fun greet():String {

return “Hi $name, how are you doing?”

}

}

// A Typical unsafe Java Singleton

public class Singleton {

private static Singleton instance = null;

private String someProperty = “SOME_SINGLETON”;

private Singleton() {

}

public static Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

public String getSomeProperty() {

return someProperty;

}

public String appendSomethingToProperty(String something) {

return someProperty + something;

}

}

// A simple Kotlin Singleton

object Singleton {

val someProperty:String = “SOME_SINGLETON”

fun appendSomethingToProperty(something:String) = someProperty + something

}

O que se segue?

Se, através deste texto, consegui influenciar-vos a testar Kotlin, aqui ficam alguns locais onde podem experimentar e que servem como apoio:

  • Kotlin koans são uma série de pequenos desafios online e são uma ótima forma de começar a explorar a superfície desta linguagem;
  • Kotlinlang.org;
  • Kotlin for Android Developers é um livro de Antonio Leiva, e é uma excelente fonte de informação tanto sobre Kotlin como sobre Android em geral;
  • Kotlin in Action é outro livro, de Dimitry Jemerov e Svetlana Isakova, muito bom para que os Java developers possam crescer na linguagem Kotlin;
  • Kotlin for Java Developers é uma webtalk de Venkat Subramanian, e é um ótimo primer para Kotlin;
  • Kotlin Puzzlers de Anton Keks é uma viagem aos aspetos não tão fáceis de Kotlin.

João Gonçalves

Mobile Consultant, Xpand IT

João GonçalvesKotlin e um futuro (ainda mais) brilhante
read more

eXperience Agile 2018: Saiba o que pode esperar deste evento totalmente dedicado a práticas Agile

O evento eXperience Agile 2018 – antigo Scrum Day – é um evento que tem como objetivo promover o debate sobre práticas Agile, bem como fomentar o networking e a partilha de insights entre profissionais da área das TI. Sob o mote Improving Through People, este ano o eXperience Agile pretende difundir a ideia de que as práticas Agile melhoram o ambiente de trabalho e ajudam as organizações a crescer através da confiança que depositam no talento dos seus colaboradores e na abertura que existe para que estes possam partilhar o seu feedback.

Ana PaneiroeXperience Agile 2018: Saiba o que pode esperar deste evento totalmente dedicado a práticas Agile
read more

Os 8 melhores livros sobre DevOps e Agile

DevOps é uma cultura. É a cultura cujo ADN é constituído pela colaboração, pela comunicação entre equipas e pela agilidade no desenvolvimento de software. É, portanto, a cultura que permite uma simbiose perfeita entre o trabalho dos Devs e o trabalho das equipas de Operações.

Ana PaneiroOs 8 melhores livros sobre DevOps e Agile
read more