Designing a multi-service app for a Mexican University.
Product Design Lead & Researcher
Qualitative research, Interaction design, Product management, Stakeholder management, Facilitation, Teaching, User interface design
Project manager, Delivery Manager, Engineering Team, and Design Team
Mural, Whimsical, Sketch, Zeplin, and Google Docs
This project was challenging because although we knew there was no obligation to deliver on specific functionalities, our client had a very well-defined list of features in their mind and was used to doing things in a rigorous way. At the same time, they wanted to learn from us how to do user-centered design, adopt an "agile mindset," and bring these new ways of working to the rest of the organization.
These two directions were conflicting but also linked: we knew that we would need to influence their way of thinking on the first one to do the second one. We decided that before kicking off the project, we needed to start with a few weeks of training onsite with their team.
I traveled along with one Design Manager to provide training for three days on the following topics:
We presented examples of how we have implemented these methods in the real world and got our students working on familiar scenarios while putting these activities into practice. After us, peers from other disciplines (engineering, data, project management) visited our stakeholders to provide training as well.
At the end of these sessions, our stakeholders were ready to learn through the execution, so we decided to kick off the project.
The project started with me as Design Lead along with one Interaction Designer, one Visual Designer, a Project Manager, a Delivery Manager, and a small engineering team who would be doing technical research while we focused on user research and the re-definition of the scope. The engineering team substantially grew as we moved from discovery to execution.
We kicked off the project with user research to let our users dictate what was necessary. These are the steps we followed across the project:
Step 3 ran in parallel with steps 4 to 7, which, at the same time, ran in cycles as we designed every feature.
I spent 50% of my time on this project for six months, typically the time a Design Manager spends on critical projects for the company. With the other 50%, I managed ten direct reports and other internal activities such as hiring. These were my responsibilities on this project:
Three of our stakeholders were heavily involved in this phase. They recruited students and professors, and ran the studies with us, first as note-takers and then as interviewers – they saw this project as a learning experience, so we got them involved and coach them as much as possible.
Also, they had already gathered much information through informal interviews and surveys, so we poured all that information into proto-personas. We reviewed the information they had documented and extracted data during a couple of workshop sessions that helped us put together these archetypes.
While our peers/clients helped us recruit users based on the proto-personas, we created interview scripts with a combination of open-ended questions and behavioral variables. The variables were focused on activities, attitudes, motivations, and skills and were extracted from the information we had, which helped us create spectrums to map our interviewees across.
During the interviews, every note-taker would have a printed copy of a template to take notes and map our interviewees across these variables. This process helped us to optimize the synthesis and debrief phases later. We interviewed ~60 people, around 15 per archetype, which was more than enough to create the first set of personas.
We followed Copper's approach to creating personas, also documented in Designing for the Digital Age by Kim Goodwin. We optimized it a little bit though, by using digital tools:
1. In Sketch, we created four boards (one per proto-persona). We mapped our interviewees across each of them and assigned one color to each interviewee to identify them across the variables in the board.
2. We identified clusters across the different variables. The ones that repeated across more than four variables indicated a potential persona to us.
3. We added insights from our notes above each cluster: an insight could be a specific description of the behavior, a pain point, or a goal. Goals could be explicit (what the user directly told us during the interview) or inferred from their behaviors, pain points, or other goals.
4. We classified the goals per type:
5. Lastly, we put together the archetypes.
We presented our personas and the process we followed during one of our bi-weekly demos and continued referencing our personas across the rest of the project.
At this point, we already had a clear idea of what the business wanted to accomplish. It was time for us to bring in users' needs, clear up assumptions, and get together to define priorities. The main challenge was that our client had a 6-month time frame to deliver the first version of the product and the number of features they had in their mind was too high for us to get there on time.
I decided to go with Jeff Patton's User Story Mapping to tackle this challenge. This method allows teams to shape minimum viable products (and subsequent phases) in detail using sticky notes and any wall available (a 20 x 9 feet wall, in this case). I spent three days with my team and our clients in a meeting room, mapping everything we needed to do based on what the business needed, what our personas needed, and what the technical team thought might be viable to implement. The following is a picture of how the map looked like at the end:
Before the project started, our clients had meetings with different business units to define the list of features they wanted to include in the product. Although they showed interest in being agile and recognized that some of the features would not meet any of our personas' needs or pain points, it was complicated for them to leave things out or push things for later without getting in trouble with their peers and leaders.
Despite that, we knew we needed to work incrementally and ship a minimum viable product before the first deadline. I decided to split the scope into shorter increments and spot the areas with more uncertainty for us to research and come back with more solid answers in terms of feasibility. These were the outcomes of our workshop:
The user story map was revisited throughout the rest of the project and more often as we got closer to our deadline. It evolved as we moved forward, and as we moved forward, certain features became more relevant than others, which helped the team focus on what was more important.
We started working on two tracks from this moment: the first one focused on the brand attributes, style tiles, and component library, the second one focused on the interaction design through user flows, sketches, and prototypes. At some point, these two would meet but were not dependent on each other at the beginning.
For the first track, I invited one Design Manager expert in branding who ran a few sessions with two of our stakeholder. He used a digital version of the brand deck to run a workshop, extracted brand attributes, and created a couple of proposals for style tiles. The style tiles were iterated a couple of times and then delivered to our Visual Designer. He used that visual direction to create our component library, starting with the atoms (buttons, badges, input fields, etc.) and then adding molecules as we defined the components in the user interface.
We followed an iterative process, involving different stakeholders at every step to avoid as much waste and rework as possible:
User flows described the high-level interaction before moving to screens. These were reviewed, iterated, and even co-created with our Technical Lead and Project Manager. We often spotted technical or business-related questions for which there was not an answer yet; they would spend a day or two figuring things out for us to iterate and then move forward. This step was crucial for us to clear up dependencies early in the process.
Here we explored the interaction on a deeper level, the layout, the components, the copy, and the microcopy. The Interaction Designer, the Visual Designer, and the Technical Lead participated in these sessions. These "wireflows" helped the Visual Designer to identify components to add to the component library. They also allowed the engineering team not to "feel blocked" by designers – they already had a picture of the user flow screen by screen with their components and layout. They could start focusing on the functionality without depending on final mockups.
After the whiteboarding sessions, the team split and worked on different streams. Our Visual Designer would create high-fidelity mockups while the Interaction Designer would update user flows or create prototypes for user testing. Our Product Owner would review these mockups and provide feedback on copy and microcopy, especially related to regulatory terms and industry jargon.
We used prototypes with two different purposes. To accurately showcase the work done during demos with our clients and validate our features during usability studies. We ran a total of five usability studies on this project, one per epic. We recorded every session and had workshops to debrief on the insights. This is what we did during these sessions:
During each end-of-sprint demo, we would present our insights and recommendations. During the next sprint planning, we discussed potential changes by considering the impact on the user experience and the timeline.
This continuous cycle of doing user flows > whiteboarding > visual design > prototyping > validation was not linear. As we moved forward, the focus was less on the user flows (mostly defined) and more on the visual design. Based on new findings, we also revisited flows and screens that we had already delivered. It was key for us to show pragmatism and focus on the value we wanted to deliver.
Adjusting the scope and prioritizing to meet the deadline was the topic we brought up almost every sprint. It is essential to mention that although the team delivered a product that we felt confident would meet user and business needs, it was difficult to please every stakeholder regarding the functionalities they wanted to see in the application. From my point of view, we had two primary goals in front of us when we started this project:
The first goal was accomplished, for the second one we will need more time and practice on both sides to get there.
This project opened the door for two more projects that started shortly after working on this project. The expertise and confidence of this team showed helped to build trust in our client.