Global Assessment Platform

Overview

The Global Assessment Platform (GAP) is an internal tool for a consulting firm that allows them to create different types of assessments for their own clients.

It was born since the view of some of the assessments they need to run is not something they can configure in sites like Google Forms or SurveyMonkey. Also they can not risk the information of their clients on those kinds of sites. And lastly they wanted a centralized database of the assessments they apply, to whom and when.

Over the course of 5 months GAP was built from concept to MVP, incorporating the most important features.

Role

Led the design of this project from concept to MVP. I also was in charge of the front-end layout.

Outcome

Made to order customizable and professional assessment platform, with all the main features developed for the MVP.

Collaboration

1 Project Manager
4 Developers
1 Tech Lead
1 Product Owner

Project Details

Problem
‍Consulting Company’s current software to apply assessments to their clients is very robust and is hard coded, it does not allow customization or the creation of new assessments in an easy way. The company can’t use sites like Google Forms or SurveyMonkey because they don’t want to risk the information of their clients, they don’t think it looks professional and most importantly these sites don’t really work like they need them to.

Goal
The goal was to build the perfect assessment platform for our client and also design the best experience we could for the people who will be using the GAP.

Constraints

Time

The time for building the GAP was very short, it was around 5 months to develop it from concept to MVP. This tight timeline meant the design had to be done in around 2 weeks so the developers could start coding.

Style

Since GAP is an internal tool for a company that already exists, the style used needed to be on brand with the company, not allowing a lot of room for exploring other styles on fonts, colors and composition.

Learning Curve

The way the GAP needs to be built is very specific. There are certain steps that the people creating the assessments need to follow, this process can be confusing and requires close attention.

Kickoff

For the kickoff of the project a very short workshop was run, it consisted of 4 sessions of 2 hours each session, one session a day during one week from Monday to Thursday. The people involved in the workshop were some stakeholders, a product owner who was also a subject matter expert and the development team including a project manager and me, a UX/UI designer.

Day 1
During this day the teams were introduced, the client’s team was very small, it was just the product owner, who was also a subject matter expert on how the assessment should work, and a major stakeholder who was the manager of the product owner. On the company’s side we were 8 people, a facilitator, a project manager, a tech lead, 4 developers and a UX/UI designer.

Following the introductions we started talking about the assessment platform. We got to hear our client a lot, they explained why we needed to build this, how it was going to work in a really broad way and what was the vision for the product. Finally we got to see what they’ve been using during the time that the assessment platform has not existed and gained so much more understanding on what we are building.

Day 2
On this day the product owner (he was from the client’s side) continued explaining the assessment platform but more in detail. This time around we got to discuss the different users the platform was going to have, the permission for each type of user, what sections should be on our navbar, what those sections would lead to and what you can do in each section.

It is important to mention that the developers asked a lot of questions on how the client would expect the application to work but on the backend, so they could build it the best they could. I really think involving the developers from these sessions, when the product is not designed yet but the client has a very clear idea of how it is going to work, was key for making sure there was a sync between developers and designers and backend and frontend.

Day 3
This day was a lot more fun, the facilitator (she was from the company’s side) got us working on the user flow diagram, to make sure that we had gotten the client's idea right, since the client was also participating on building the flow, we all builded together and the facilitator made sure ,the developers and me (the UX/UI designer), were understanding the flow and how the activities jumped from one user to another, depending on the permissions the user had.

This is how out user flow diagram ended up looking:

Day 4
The previous day we got a little homework, it was to bring images of how we imagined the GAP, each section and the most important features. Everyone did some research to find their images, some were from dribbble, others from google, blogs and a few from product pages. I have to say that the availability of images of products similar to what we wanted to build was limited, I assume it was because other companies might have built something similar but was also internal, so there was not a lot of public information about it.

This last day, one by one we got to show the images they found and we got to discuss a little about the images. Most of the images were saved as lightning demos.

Once we had the lightning demos we got to build a storyboard based on our user flow diagram and of course using the lightning demos as part of the storyboard. This is a visual representation of how we imagine the GAP is going to look like. The storyboard is the starting point for designing and building the prototype.

•••

We finished the workshop with the understanding of what we are building (developers and designer) and ready to start designing and programming.

Design

After the workshop it was time to start designing. I had 2 weeks to design the GAP before the developers started to code any interface. In the meantime, they (the developers) were setting different things for the project.

During these 2 weeks the team (product owner (client’s side), project manager, devs and UX designer) met twice a week, usually on Tuesdays and Thursdays. I started to design the screens based on the storyboard. The meetings were crucial to ensure we were all on the same page and we were not omitting any feature.

Early design

Features

These are some of the features that were discussed for the GAP. Most of them made it into the MVP but few didn’t, and others were added along the way.

Log in
For the people creating and applying the assessments it is important to have the login feature, it recognizes the kind of user you are and gives access to what users are supposed to see and interact with. It protects the information of the assessments and prevents unauthorized users modifying, deleting and creating assessments without prior approval.
Create teams
The ability to create teams is there to facilitate the grouping of people dedicated to specific themes who are working together in the same assessment or set of assessments.
Survey creation
Probably one of the most important features, for the GAP instead of using the name survey, we use the name framework. To create a survey it is needed to give it a name and a description, then it is possible to add questions or in this case criteria. There are 4 types of questions the user can create, for 3 of those types it is possible to add answer options. Once all the questions are created it is time to click the finish button (even though the survey is automatically saved with every piece of information it is added).
Template creation
To be able to create a template it is necessary to give it a name and a description, then it is necessary to add surveys that have been previously created. A template is built by a set of surveys. It is a super useful feature to help save time because sometimes the same assessments need to be applied to different clients, so this sets the common ground for the shared assessments, preventing having to create the surveys everytime the assessment needs to be applied.
Assessment creation
The assessment creation usually involves taking a template and assigning it to a client, it is also possible to add an image which is expected to be the logo of the client. Sometimes an assessment can be a set of templates instead of just one. The assessments can be shared at a template level, since most of the times the templates don’t share the same recipients. It is able to track how many invitations were sent and how many responses have been received. It also tracks the status of the whole assessment. For getting the answers it has to be done at a template level and it gives you a CSV file with the answers.
Filtering
For facilitating the retrieval of teams, frameworks, templates or assessment filtering needs to be added to the indexes of these parts of the GAP. Some of the filtering options may be: date, client, tag, status and member.
Search
Also for facilitating the retrieval of teams, frameworks, templates or assessment a search option is contemplated, it is supposed to be added to the indexes of these parts of the GAP.
Notifications
Receiving notifications is incorporated to let the user know when they have been added to a team, what the user’s team is working on, when someone has answered the assessment they sent and more. Notifications help users stay up to date with the assessment they might need to be working on and reminds them of the most important stuff on the GAP.
Assessment application
When someone receives an assessment to answer, they receive a mail with a link to the assessment and a password to be able to answer the assessment, the assessment application is a different view from where the assessment is created. Having a password prevents unwanted people from using the platform, and the application being outside of the creation panel makes it easy for people to answer it since they don’t have to create an account and at the same time this makes the database lighter since it doesn't have to store that many accounts.
Question counter and time estimated
While answering an assessment, the first screen a user sees (after entering the password) is a short description of the assessment that includes a question counter and time estimated needed to answer the assessment. This was included so the user could know what is ahead and decide if they have time right there or make time later, since some assessments could be very long.
Autosave
For preventing the loss of information while answering an assessment an autosave has been contemplated. A user could close the window where they are answering and open it again later and will find themselves at the same point it was previously.
Progress bar
A progress bar was added to the assessment application to give the user an idea of how much is left or how much has been done of the assessment, so they aren't desperate and see progress continuously.

Defining the MVP

Due to the time we had to develop the MVP, we had to be very wise with our decision of what to prioritize, to focus on the main features first we identified the key user stories that would make the GAP usable:

Create frameworks
Users with an expert account can create frameworks, and there exists 4 types of questions a framework could have.
Create templates
Users with an expert account can create templates, each template can be composed from one or many frameworks.
Create assessments
Users with a facilitator account can create assessments, each assessment can be composed from one or many templates, they can share the assessments and also download the answers.
Assessment application
Users that are participants receive a link and a password in their email, so they can answer the assessment.

In order to manage the project, we used Pivotal Tracker as our tool. The user stories were added there and assigned to a developer. Everything is ready to start developing and building the GAP.

Development

With the early design ready and the user stories we were going to focus first, it was time to start developing. Since the developers had been in the process from the beginning (the workshop), including the design development, they had a pretty good idea of how the GAP was going to look.

At Icalia Labs, we like to involve a designer in the developing process, to always ensure the actual application looks and functions as it is intended to do. The designer works along with the developers and the project manager building the product. The main task of the designer is to use html and css to style and build the product and its interactions.

During the development of this project we met twice a week with the stakeholders of the project (product owner and subject matter expert from the client’s side). Mondays were for planning sessions and Fridays we had demos.

Setting the backend
‍As I mentioned before, while the design was being built, the developers were focusing on setting most of the backend of the project to be able to start with the frontend and the views of the application.

Creating a style guide page
I agreed with the developers to enable a view (page within the application) to put the most important and used elements of the application so they could see them and also retrieve them from that page.

For this, in this page I built all the most used elements like navigation bars, side menu, buttons, and more.

Weekly tasks
Once most of the backend was set and also with the style guide created, most of the weeks looked the same. Each week was one sprint.

On Mondays we reviewed the tasks on our project management tool and approved what was ready, then we determined what was next and created the tasks in the tool, each task was scored depending on the difficulty and assigned to a person.

From Monday’s noon till Thursday’s afternoon it was all about development and making sure the user stories for that week/sprint could be completed in the MVP. First thing in the morning on Friday everything ready was sent to staging.

During Friday’s demo we presented what we worked on during the week, and our client would let us know if it was as expected or if we needed to make any changes. After the demo meeting, Icalia's team made a team back meeting to review everything and be ready for the next sprint.

Testing

After 3 months into the project, a usability testing round was scheduled. It was with some of the people that would be using the GAP on a regular basis.

The whole testing round was handled by the client’s team. It consisted in giving the people some tasks to perform in what was developed at the moment. The team also asked for general feedback and thoughts.

Since all the people, the ones conducting the usability testing and the ones performing it work at the same company, very honest and enlightening opinions about the GAP were gathered.

Once the client’s team finished conducting the usability tests it was time to meet with Icalia's team to share their findings.

What the client’s team let us know about the usability tests and the user and their feedback was very valuable to improve the user flow and the whole experience.

Key requests / Main iterations
These are some of the main requests taken into consideration to iterate on the design so we could improve the user experience.

Draggable criterion and possible options
When creating a framework having the ability to drag and drop any criterion to alter the order, so the user wouldn’t need to delete criteria and enter it again wasting so much time. Same for the possible options, being able to drag them and reorder them.
Content pages
This was suggested to be able to add information with instructions, context, etc. in between the assessment so the person answering it could have a better understanding of the assessment and why it is important.
Tagging and search by tag
For a better search and group of frameworks / templates / assessments tags are introduced, this will facilitate the access to information.
Users
Instead of having groups, creating a user manager for superadmins, to handle the different roles and permissions.
Export
Being able to export different answers from different assessments to make comparisons without having to enter to each specific assessment page.
Company logo on assessment application
To increase the customization of the assessments, the image that is added to the assessment being displayed in the assessment application, always procuring the image added is the logo of the company the assessment is going to be applied to.
Reminders
The ability to send reminders to those persons that hadn’t responded to the assessment, so in case they have forgotten, they get a reminder to answer it so the consulting company could keep on with the process.
Responsiveness
For increasing the access to the GAP it was suggested that the GAP was responsive to smaller devices like laptops and tablets instead of just desktop computers.

Final design for MVP release

Takeaways

Next steps
Here are the future steps for the Global Assessment Platform:

Post-launch optimization
This is a crucial next step for the UX improvement of the GAP. Not only optimizing the design but also the code to make the experience more enjoyable and the product better built.
Test
Conducting another round of testing is important to receive feedback and keep on improving the experience and the product.
Develop more features
Since some features were left out of the MVP and are very important and useful, this is the time to start developing them so they could be implemented in future versions. Some of the features that were left out are: filters, integration with Tableau or Power BI, and home dashboard.
Upgrade the design
Due to the time for the development, the design of the product was fast, it could use some improvements that would make it look better with small changes that would build on to a better and smoother experience.

What I learnedThis project taught me a lot, it was a super fun, challenging and enriching experience, here are the main learnings I had while designing and developing the MVP of the GAP:

Not every feature will make it to the MVP
Usually when developing an MVP there is an established timeframe to have it ready, focus on the key features at first to make it functional and not to worry if some features don’t make it to MVP as long as it is an usable product.
Strategy to launch the MVP
It is important to have a strategic plan to launch the MVP, this helps deal with out-of-scope requests that could potentially derail the project and helps deliver a quality product in time.
Involve developers early on the process
Involving the developers from the beginning will make them understand better the product they are about to develop and its interactions, this will minimize doing rework later on the development of the product.
It’s ok to ask for help
Sometimes answers to problems don’t come as easy as it might seem, it is ok to ask for help when many things have been tried and the answer doesn’t look very close. This will most likely save a lot of time.
Be aware of how tech works
Having some knowledge on tech and even programming languages can help to design better, this helps understand how websites and applications are built and design accordingly, so the hand off to developers is smoother and the reference file is more understandable for them.
Design for responsiveness
Always take responsiveness into account, from the beginning establish the smallest device the product is supposed to work on. I also recommend to start not only designing but also developing from the smallest screen to the biggest since it is easier to adapt.
User testing doesn't end after development.
Design is a constant iteration of improving the experience for the user. Always find ways to collect and listen to the user's feedback.

Building a personalized assessment platform

Global Assessment Platform