Case from Sogeti
"IT-Steget"
This was an Agile project where a gruop of seven people (including myself) with different knowledges and skills worked for half a semester to "solve" the case that we recived from Sogeti Umeå.
The case was to:
Create a Two-way communication between IT-students and IT-companies, as well as create a plan for marketing this solution.
My roles where primarily as a:
- Scrum Master
- Designer
but also
- Write the project plan (along with everyone else in the team)
- Write design documentation
- and more
Before planning:
Before creating the plan of how to do what we were going to do, we had to figure out what we were going to do.
This meant conducting reseach of what both IT-companies and IT-students wanted to know when communicating between each other. We also had to figure out how to market it in a way so that it will be used.
- A survey about students prefered social media usage, possitive company interactions and what they would like to know about working at an IT-company
- Interviews with both students and workers (HR, new hires and general personel) to learn what they wanted out of interacting with eachother
- Literary analysis on UX -design and marketing
Planning with Sprints:
We split our work into 5 sprints, where each sprint was one week (our actual plan in Swenglish below).
- Sprint 0: Make project plan
- Sprint 1: Create Graphic Profile, Perssonas and User Stories
- Sprint 2: We designers created paper wireframes and user tested the first verion of the app. The rest of the team did research towards the marketing.
- Sprint 3: We designers coninued with a more High-Fidelity version of the app and tested it. The rest of the team figured out what kind of content the company could add, based on what students wanted to see.
- Sprint 4: We designers continued developing the app to a real looking prototype and tested it. The rest of the team continued working on the marketing and social media aspect.
Before each sprint the entire team sat down and planned for the upcoming week and assigned speciffic tasks to each team member in (microsoft) Teams. After each sprint we had a "Sprint Retro" where we evaluated the sprint together, sometimes moving tasks to the next sprint.
Meetings:
We set up meetings about 3-5 times a week depending on the workflow. They where mostly in person, but the Sprint Retro was generally on Teams. Each meeting started with a "How are you"-round where we asked everyone one by one how they were actually feeling. We argue this is something that made our connection so great, as people were actually able to say if the had a bad nights sleep, or if they were very excited about a game that was releasing that day that they bought right before the meeting.
After that - we had a more traditional standup meeting where everyone got to say what they had done since the last meeting and what they were going to do today and ask for help if needed. It was a great opportunity to take one step back as a designer and realase that not everyone understand what wireframes are, how much you can do in programs like Figma and how important user testing is. It meant we had to adapt out language and explain everything in a way that other team members understood, so that they could weigh in with their knowledge.
My role
I one of two designers, deigning and testing the app. I was also one of two Scrum Masters, something that isn't typical but wanted to make sure that everyone could try out that role if they wanted to. We split the Scrum master roll in to a kind of internal/external split where I was respnsible for setting up documents, sprints (including the Scrum board) and "lead" the meetings in the team.
While my Scrum Master-partner was reponsible for scheduleing group meetings and communication with the client and teachers.
Designing the app
The design process for the app also followed the Agile methodology where we deigned, tested and evaluated each version.
Our first objective was to use what we had lerned from the company about what they wanted to know about a student (possible hire). We wanted to make the process of filling in that information as easy as possible with clearly marked steps to achive the feeling of prograssion.
Our interviews told us that a persons technical skills in most cases wasn't nearly as important as their personality. Thats why we made sure the technical abilities could be filled in fairly quickly, with an about me section in the end.
To test a way of doing this we created quick paper wireframes. These were also used to communicate how we wanted the app to look for the rest of the team.
User flow 1
Creating an account
User flow 2
Social pages
After testing user flow 2
More frames
Progress bar for job search
While testing the users made it clear they wanted to see how the progression of their application. So we added a progress bar in the same style as "create an account" with important steps like "received application", "read the application", "made a decision" and answered.
According to users, the one of the biggest pain points was not knowing if they company had even read their application or if they had read it without answering.
Other frames
To show what companies profiles would look like we added one for Sogeti. It shows nasic information like if you follow them and their latest posts. But in between those "normal" functionalities is a button if you would like help with your CV (a service that Sogeti actually provides). There is also a button to chat with someone at the company. Our goal was to have people with different professions be able to answer student questions. However, in the begining it is more likely that one single person manages the account.
Lastly we added the search bar with the opportunity to filter out jobs and events.
Frames for reducing and managing errors
To make the user experience smoother we added
a couple more frames. The first one being a pop-up to confirm that the user wants to continue after pressing a link to an external website, with a primary "continue"-button and a secondary button to stay.
We also added an easy-going error-page. It says "oh, the page doesn't exist... but thanks for checking in and saying hi", which lightens the mood and leaves the user happier compared to a standard error page with a (to the user) random error code.
Designing the app
The design process for the app also followed the Agile methodology where we deigned, tested and evaluated each version.
Our first objective was to use what we had lerned from the company about what they wanted to know about a student (possible hire). We wanted to make the process of filling in that information as easy as possible with clearly marked steps to achive the feeling of prograssion.
Our interviews told us that a persons technical skills in most cases wasn't nearly as important as their personality. Thats why we made sure the technical abilities could be filled in fairly quickly, with an about me section in the end.
To test a way of doing this we created quick paper wireframes. These were also used to communicate how we wanted the app to look for the rest of the team.
