The kick-off meeting was our first introduction to the client and project. We presented our initial understanding of the project to share our expectations and reach a common ground with the client. The team and the client made an affinity diagram that helped us visualize the areas of interest for the project focus.


Competitive Analysis

To gain an initial understanding of the domain space, we analyzed other companies' telecom portals to quickly learn what features were standard and prioritized. The most advanced portals included customizable permissions for employee logins, real-time bill credits for incorrect charges, and invoice memos that can be distributed to multiple departments.

Other basic features that PT competitors' portals boasted were online ticket tracking of repairs and orders, viewing contract details, disputing bills, and generating reports of company usage and costs. In later user research and testing, enterprise clients validated the usefulness of these features.

User Research

With the assistance of a client manager in Madeira, we were able to interview 21 people. We interviewed 6 PT employees and 15 telecom clients with various providers, in both Lisbon and Madeira. Below is a graphic showing a breakdown of our user research participants.



In order to gather data, the team used a variety of methods. Though Contextual Inquiry, Retrospective Walkthroughs and Interviews were the most frequently used methods, we also used MakeTools and Cultural Probes.

In a contextual inquiry, the interviewers observe the participants while the participant works in context — that is, in the environment where the work naturally occurs. Contextual inquiries give rich data about participants' daily routines and the problems participants encounter in doing their daily work.

A retrospective walkthrough is when an interviewer asks a participant to recall a specific task in the past. Retrospective walkthroughs are useful when direct observation of a task is difficult or impossible. We used retrospective walkthrough because it was hard to arrange contextual inquiries in synch with when participants would manage telecom services.


Together we interpreted the data from our user research. We quickly realized that data from client managers and data from clients should not be merged. We would lose valuable details. And so we decided to consolidate our data into two user groups: Client managers and clients.

With the client manager data, we taped up all the work models of the 6 PT employees. We carried a pad of Post-It notes and wrote down important insights, data, and notes and posted them next to each user. Then, with all the Post-Its, we made an affinity diagram and sorted them into 25 categories.

With the client data, we made 350 Post-It notes of observations, issues, and insights of our 15 client users. We grouped the notes into over 100 categories and then grouped those categories into 35 broader categories.

We also combined our individual work models for each contextual inquiry into one consolidated model. After condensing our data, we saw patterns that helped us arrive at important insights about participants' telecom management.



From consolidation of our user research data, we derived the following insights (written in the voice of the user):

  • 1. My client manager is my hero.
  • 2. Why is my client manager so busy?
  • 3. No more surprise charges! I want to check my usage.
  • 4. I feel neglected because I'm a small client.
  • 5. We are small. Keep it simple.
  • 6. I need solutions designed just for me.

These insights helped guide our design process.


In order to help ourselves and our client put a human face on our research insights, we created personas. A persona is a representation of a possible user of a system. Personas are composites from patterns in research data; they do not represent real people. Each of these personas had an accompanying scenario that was related to one or more of our main insights. These personas helped us remember our target users in the design process.