Bake-off 1 - Interface Gráfica para Serviço de Mobilidade

Disponível: 17 Fev. 2020
Entrega: exclusivamente no dia 27 de Março, até às 23h59, via Twitter.
Desafio: criação de uma interface gráfica para um serviço de mobilidade urbana que integra múltiplos modos de transporte.
Resultado esperado: um protótipo de média-fidelidade (implementado em figma.com) da interface para o serviço em aplicação móvel permitindo: i) integrar vários modos de transporte; ii) consultar o custo, tempo, pegada ecológica, segurança e calorias da viagem; iii) consultar e selecionar alternativas baseadas nos parâmetros anteriores.
Avaliação: 0-20 valores, 10 valores qualidade do processo de desenho, 5 valores atingir o limiar da escala SUS, 5 valores superar o limiar da escala SUS.


Desafio

O objetivo do primeiro bake-off é criar uma interface gráfica para uma aplicação móvel (app) de mobilidade urbana que integra múltiplos modos de transporte: caminhada, bicicleta, carro e com maior enfoque nos serviços de transporte público - Autocarro (Carris), Metro, Bicicleta (Gira, Jump), Ferry (Transtejo) e Automóvel (Uber, Bolt). Para vencer este bake-off têm de criar um protótipo de média fidelidade com uma interface fácil, rápida e apelativa.


(Apenas para alunos de IPM-LEIC): O vosso protótipo deverá integrar também os modos de transporte: Comboio (CP e Fertagus), Scooter (eCooltra), e Trotinete (Hive).


Funcionamento

O bake-off é um desafio de design em aberto. É crucial que iniciem um processo iterativo de ideação-prototipagem-teste desde o primeiro dia. A utilização de storyboards e protótipos em papel é fundamental para que consigam realizar várias iterações, rapidamente. É expectável que realizem pelo menos 3 iterações usando as técnicas descritas nas aulas teóricas e apenas na fase final implementem o protótipo de média fidelidade. 

O vosso protótipo tem de suportar as seguintes funcionalidades:

  • Integração de vários modos de transporte;
  • Aquisição de uma viagem para um dado destino através de qualquer um dos modos de transporte disponíveis;
  • Consultar o custo, tempo de viagem, pegada ecológica, classificação de segurança e calorias (se aplicável) para cada um serviços de transporte disponíveis;
  • Consultar a localização e horários de cada um dos serviços de transporte.

Recomendações

Não comecem o processo de desenho com ferramentas de média fidelidade. Correm o risco de demorarem mais tempo, não conseguirem fazer iterações suficientes, e terminarem com uma solução menos criativa e adequada.

Um protótipo de média fidelidade não tem de implementar a funcionalidade do sistema. O vosso foco deverá ser na organização da informação, fluxo de utilização, e desenho de ecrãs. Apesar do protótipo funcionar para um número restrito de tarefas (ver Tarefas a Suportar), a interface deve demonstrar que poderia ser estendida para qualquer parametrização (ex. comprar uma viagem para qualquer morada válida).


Tarefas a Suportar

Assumam que a localização actual do utilizador é o Instituto Superior Técnico - Campus Alameda. Podem simular escrita de texto usando apenas os destinos necessários para executar as tarefas descritas abaixo:

  1. Comprar uma viagem até ao Cais do Sodré usando o serviço mais rápido (possibilidade de escolher entre a mais rápida, mais económica, mais ecológica ou mais segura)

  2. Comprar uma viagem através do serviço Uber para o Campo Pequeno;

  3. Consultar quantas calorias serão usadas numa viagem até ao Campo Grande usando o serviço Gira;

  4. Consultar a diferença de preço e tempo entre os serviços Uber e Gira até ao Rossio;


Recursos e Ferramentas

O protótipo de média fidelidade será construído com a ferramenta Figma.

Figma: www.figma.com

Registem a vossa conta como estudante (usando o email oficial do IST - user@tecnico.ulisboa.pt), usando este link, através do ponteiro 'Verify Student Status'.

Quando criarem a app, usar a frame 'Android'


Tutorial e configurações:


Prototipagem em papel:


Desenho para dispositivos móveis:


Competição

O bake-off termina com uma competição que será realizada na aula de laboratório da semana de 23 de Março. Cada grupo irá realizar testes obrigatoriamente com 7 participantes, utilizando um computador com rato.


Na sessão de bake-off, cada elemento do grupo tem uma responsabilidade:

  • Facilitador - Será responsável por preparar o computador e conduzir o estudo; Devem imprimir o System Usability Scale para 7 participantes.

  • Observador - Responsável por recolher comentários ou utilizações inesperadas do protótipo; 

  • Participante - Cada grupo terá de 'doar', pelo menos, um elemento para testar todas as soluções dos restantes grupos na sala. 


Todos os grupos têm de usar um computador com rato por uma questão de consistência e justiça dos resultados. As frames no Figma deverão ser 'Android' e o 'zoom' do protótipo deverá estar configurado para 100%. 


É da responsabilidade de cada grupo preparar a solução, receber os utilizadores e conduzir os testes. No final de cada teste será aplicado o questionário System Usability Scale ao participante. Os resultados serão recolhidos pelo Arquivista e inseridos no computador do docente.  Estes serão usados para calcular o score (ver aqui) e criar o leaderboard (da turma e da cadeira). No final da aula será anunciado o vencedor do laboratório e na aula teórica da semana seguinte será anunciado o top 3 da cadeira.

A ordem de execução das tarefas durante o bake-off será aleatória e dada pelo docente do laboratório.


Submissão

A submissão tem de ser feita exclusivamente no dia 27 de Março, até às 23h59.  Tem de conter os seguintes elementos:

  1. Link para ficheiro .fig do protótipo (no Figma ir a File > Save as .fig);

  2. Link para vídeo descritivo do processo de desenho e solução final (com descrição verbal). A captação de vídeo com o telemóvel é suficiente, não é necessário editar o vídeo original. O docente quer avaliar a(s) ideia(s) e o seu desenvolvimento; as vossas competências cinematográficas não são relevantes. Tem apenas de ser claro o que fizeram e como o fizeram. O vídeo deverá incluir:

  • Ideias iniciais: quais foram? Descrição rápida ou demonstração de esboços é suficiente;

  • Refinamento: como evoluíram as ideias através das várias rondas de refinamento? Foram desenvolvidos protótipos intermédios? Como foram testados? Com quantos utilizadores? O que aprenderam?  Etc.

  • Solução final: demonstrem a solução final e expliquem todas as vossas opções de desenho;

  • O vídeo tem no máximo 3 minutos.


Para promover transparência na competição, a submissão é feita via Twitter no seguinte formato:


Avaliação

--------------Adenda - a formula de avaliação foi ajustada para:

  • Eliminar o conflito de interesse entre a avaliação SUS e a nota do próprio grupo. Ou seja, não existe qualquer vantagem em atribuir um valor SUS mais alto/baixo aos restantes grupos.

  • Reduzir a componente subjetiva da avaliação através da inclusão da métrica objetiva de usabilidade (taxa de sucesso). É esperado que o vosso protótipo  permita aos utilizadores realizar as tarefas propostas.

  • Reduzir a dependência da variabilidade na avaliação da experiência de utilização. A componente da experiência do utilizador é parte fundamental na avaliação de sistemas interativos. No entanto, esta é inerentemente subjetiva. Para minimizar o impacto de pequenas flutuações na média do SUS e respectiva nota, vamos: (1) usar oito participantes (suficiente para identificar 75% das diferenças significativas entre protótipos1), em que um dos participantes é o docente; (2) descartar valores outliers (diferença com média superior a dois desvios padrão); (3) comparar média do SUS com 4 níveis de usabilidade;

A chave para o sucesso está no processo de desenho: idear-prototipar-iterar. Lembrem-se dos dois mantras de IPM: (1) vocês não são os utilizadores, (2) conheçam os vossos utilizadores.

Alunos em que se verifiquem comportamentos desonestos (menos éticos) para com os seus colegas resultam na desqualificação da competição (i.e. cotação de 0.0v).

--------------------




  • 10.0v, qualidade do processo de desenho. O docente está à espera de um vídeo que ilustre um processo estruturado de ideação-prototipagem-iteração e demonstração da solução final. Devem mostrar/descrever os materiais usados em cada iteração, quais os métodos que usaram para realizar os testes e como a solução foi refinada. Devem também demonstrar o protótipo final que será avaliado na sua adequação a regras de desenho de gráfico (alinhamentos, contraste, utilização de espaço, etc.) e adequação ao problema proposto.

  • 5.0v, taxa de sucesso / percentagem de tarefas completadas com sucesso. Cada tarefa terminada com sucesso durante o bake-off corresponde a: 5.0v / (7 participantes * 4 tarefas);

  • 5.0v, experiência de utilização. Esta componente será calculada através do System Usability Scale (SUS). A média do SUS será mapeada numa nota: 2.0v para resultados entre 68 e 77.1 (nível C do SUS, protótipo OK); 4.0v para resultados entre 77.2 e 80.2 (nível B do SUS, protótipo BOM); 5.0v para resultados entre 80.3 e 100 (nível A do SUS, os utilizadores vão RECOMENDAR o protótipo). A média será calculada com oito participantes1 (7 alunos + 1 docente). Valores outliers serão descartados (diferença com média superior a dois desvios padrão).

  • 5.0v, atingir o limiar do SUS. Os resultados da competição serão calculados através do System Usability Scale (SUS). A nota é um mapeamento linear entre [0.0v, 5.0v] e a média dos resultados obtidos com o questionário SUS [0, 68]. A pontuação 68 é o limiar usado para identificar graves problemas de usabilidade; Se passarem o limitar, têm automaticamente 5.0v.

  • 5.0v, ultrapassar o limiar do SUS. A nota é um mapeamento linear entre os [0.0v, 5.0v] e a média dos resultados dos questionários [68, max_obtido_na_UC]. Isto é, devem tentar distanciar-se positivamente do limiar.


Submissão de vídeo e protótipo obrigatória: a não submissão do trabalho ou submissão que não respeite as regras acima, resultará na desqualificação da competição e cotação de 0.0v. Por favor, sigam ao detalhe as instruções de submissão. Submissões após a data/hora limite terão uma penalização de 10% no primeiro dia (durante o dia de 28/03), 20% no segundo dia (durante o dia 29/03) e cotação de 0.0v após dois dias de atraso. Por recomendação da coordenação do curso, não serão aceites submissões após a data limite: exclusivamente, dia 27 de Março!

Caso não seja submetido o vídeo terão 0.0v na entrega. Caso não submetam o protótipo serão apenas avaliados na componente do Processo do Desenho (máximo 10.0v).

Comparência obrigatória: grupos ou elementos que não compareçam na sessão de bake-off terão cotação de 0.0v na componente da competição (exceção em casos de falta justificada, por ex. declaração médica) - combinar método de avaliação alternativo com o docente); 

Pontualidade: alunos que cheguem atrasados à sessão de bake-off serão penalizados na sua nota individual em 2.0v (exceção em casos de atrasos justificados, por ex. declaração médica).


[1] Tullis, T.S. and Stetson, J.N., 2004, June. A Comparison of Questionnaires for Assessing Website Usability. In Usability Professional Association Conference (Vol. 1).