AUTHORS
Andersson, J. Lindh, B, Tham, B.
THE COMPANY
TietoEVRY CX stands for customer experience and is located around Sweden and is part of the Tieto Group under the branch Digital consulting. At the office in Kalmar, they are about 30 consultants and work in small teams of both interaction designers, project managers and developers.
OUR ROLE
Our role as interaction designers has been to improve the serviceportal's user experience and usability. To do that, we worked user-centered, exploratorily, and iterated insights, intentions, ideas, and values to develop the new serviceportal. Our tasks were to examine the system's characteristics, identify the target group, the use situation and the need users had to create a new serviceportal that provides value for them. We benefited from the skills and knowledge we gain during many of the program's courses. We became our own team but we had regular reconciliations twice a week with our two mentors. Once a week we held demos for them where we presented our insights or results and potential further development.
THE PROJECT
Our mission was to improve their serviceportal, which had not undergone any major development since it was created in 2008. We entered the mission with neither restrictions nor requirements and the goal was to develop the entire portal for both internal users and customers, everything from case management to the administrative pages.
Duration: 5 months
Course: Internship
Tools: Adobe XD, Miro, Drive, Teams, Trello & Slack.
KEYWORDS
Iteratively, Requirements, Case study, Research, Participatory design, User centered design, Co-design, Design workshop, Semistructured interviews, User test, Low fidelity, Sketches, Wireframes.
METHODOLOGY
METHODS
Sitemaps, Taskflow, User study, competitive analysis, Semistructured interviews, User testing, Observations, Transcription of interviews, Affinity diagram, Researchers triangulation, Needs list, Requirements (Must, Should & Nice to have), Wireframes, Love & Hate, Design workshop.
THE PROCESS
Our process has been anything but as straightforward line as it looks in the figure below. A design process is not often simple and clear and it can be a ball of yarn with different iterations. But to make the process understandable, it has been broken it down into different parts.
MAPPING THE SYSTEM
In the first stage, our focus was to get to know the portal and understand the data flows that we may need to take into account. In the preliminary investigation, we therefore started by examining the system's properties, we mapped the serviceportal through sitemaps and a task flow and to explore other systems on the market, we also conducted competition analyzes.
CASE STUDY
When we then had an understanding of the system, it was time to do user studies. We then conducted a large number of interviews and user tests on the existing portal, which we also observed to investigate who the users were, their needs and potential shortcomings in the system. We did this with participants who have different professional roles at TietoEVRY CX in Kalmar.
DATA ANALYSIS
After the user surveys, we had collected a fairly large amount of data that needed to be analyzed. And to concretize the users' needs, we transcribed all the interviews, we analyzed the data and sorted out the expressed and perceived user needs.
FOCUS AREA
Through the analysis of the large amount of qualitative data, we then limited the design process to one of the primary target groups, which were the employees at TE, we also limited ourselves to the part of the system that specifically concerns case management and its critical functions.
Through the analysis of the large amount of qualitative data, we then limited the design process to one of the primary target groups, which were the employees at TE, we also limited ourselves to the part of the system that specifically concerns case management and its critical functions.
RESULTS
FROM "USER NEEDS" TO "PRIORITIZED REQUIREMENTS"
Once we analyzed the data and represented the results as models, the next step was to start thinking about the future: what the service must do to succeed and these needs were later expressed as requirements. The needs were reformulated and then prioritized in must have , should have and nice to have - requirements for every side of the portal.
WIREFRAMES
After we set clear requirements for the work, we were able to brainstorm solutions and further develop our sketches into Wireframes.
These wireframes resulted in two different concepts that we chose to call the List View and the Card View. To choose a concept and investigate which solution was best, we involved the users and held further interviews. But sometimes it does not always turn out as planned, as the result of the interviews was almost 50/50 of which concept which users preferred the most. This led us to choose to combine these two concepts, but we started by developing the list view to relate to the time aspect.
DESIGNWORKSHOP
We were still not entirely sure how the users wanted the information to be presented graphically in an open page, as everyones opinions were very scattered. Therefore in the last phase of the design process, the detailing phase, a design workshop was held in the form of co-design where users could participate and put out finished components for how they would like information to be presented on an open page.
PROTOTYPE
SERVICEPORTAL 2.0 - MUST HAVE REQUIREMENTS
The service portal 2.0 resulted in this interface where the cases are listed under different categories. The challenge with creating an interface like this has been, among other things, that text fields can vary in length, that a lot of information should be visible and that it should work with many cases as well as for too few cases. The hope with the new service portal has been to make functionalities clear and easier to understand for the user.
An example of functionality that has been added is the note center at the top right. The note center compiles the activities that have taken place in the portal, for example if a new case has been received, a new message has been placed on a case or if a case has been ordered by the customer. We added a note center to the portal as we noticed that many people today use their email inbox as their own note center and in this way the notes are collected in the same place as the cases.
SERVICEPORTAL 3.0 - NICE TO HAVE REQUIREMENTS
With many nice to have requirements we decided to do an extended version.
In Serviceportalen 3.0, we have implemented the possibility for the user to choose between the list view and a card view. We chose to design the new interface for the Service Portal as half of the participants in our interviews would prefer to work in this view, which results in a better ease of use and user experience for more users. The card view gives the user the opportunity to interact with the system in a more exciting and visual way and provides a direct response to the status and development of a case. With this view we also see a development to handle a larger number of cases while still maintaining a good overview.
Thanks for scrolling!
If you have any feedback, want to collaborate or just want to say hello, let’s get in touch!
