Cause what you think you need, is not always right — Sprint Week Case Study: IOS Offices
“We need a solution to integrate all our services into one app. We need an app that help us bring new clients onboard, as well to our current clients to schedule an office directly form the app. Also help the prospects on becoming member directly form the app itself.”
— Ianis Defendini
In our first meeting with Ianis, he quickly began telling us about the current state of their recently launched apps. IOS Offices has nothing to do with Apple’s iOS, they have multiple offices spaces around the Mexico. How they already have some built solutions, and that they weren’t being used by their clients. Either because they were incomplete, non-useful or just not know by their clients at all.
We heard all of his current problems and how much complexity they were thinking to bring to what they though was gonna be “The key app to solve all their issues, and al clients would love”. We immediately told him that we didn’t think that was the path to follow. Since the past solutions they had built, hadn’t worked.. They should actually figure out what clients wanted and needed. And, putting so much functionality into one app wasn’t the solution to make people want to use an app.
Also, the idea of jumping directly to an expensive development process without thinking in how much work it would be and not testing or talking to client before building it, was a huge risk — specially with the recent non-successful tries.
We suggested an app constalation. This with the goal of narrowing down app functionality, reducing complexity and increasing the chances of IOS-Offices actually using the applications. In other words, finding the jobs to be done.
We notice Ianis didn’t quite understood why we mention them, so we the told him we should do a Design Sprints. We explained to him what it meant, and one he undestood what we were saying, he was onboard with the idea. From there we started this 5 days adventure.
Day 1 — Monday: Asking the right questions
To make the Design Sprint easier to the experts, we decided that it should take place at IOS Offices. At the begging of the session, the first thing we asked was: Why we were doing this Sprint? Ianis promptly answer that it was for us to define the unified app with all the functionality around the IOS environment (which is plenty).
So we started asking what have they done in the past to solve some of the issues. So he showed us some applications as well as some webpages that let you do A LOT of stuff. Some app even showed their monthly magazine on their phone (Couldn’t read it there because of how it works). He later told us a lot of information and how users, most of the time had no idea of the stuff that goes down at IOS. And that is meant for the clients, but they never know of events or notifications. The he told us that he wanted to create a better community with the events they organized and other activities the usually have.
After a long session of questions and lots back and forth, we had an idea of what the main issues of the company was and how things where being done. As well as some ideas of why they hadn’t worked. By that afternoon, we had a good handle on the company’s goals, short and long term. As for the target market, we kind of had clear that it was meant for the current users. This enabled us to jump into a deep productive conversation quickly.
That day we came up with the players and the actions that were currently happening on IOS when an anouncment was made and how the users got a notification of it.
By the end of the day, we had decided to focus on all the communication going on IOS. We had quite clear, that this could be a very specific or very wide subject, but it was the one that had to be treated.
Day 2 — Tuesday: Talking to the experts
IOS experts being such busy people with a very saturated agenda, gave us a 30 min space by Tuesday morning. Fortunately we had the time to get prepare and make the most out of this 30 min gap. First we started by asking questions we had written down on Monday. This in order to try to figure out it we were on the right path. The profiles in the room were quite varied. From the CEO passing with the human resource people to the IT guys. Everyone seemed quite excited an with plenty ideas to share. So before we got deviated with more ideas. We decided to show them our map and what we thought was one of the main issues going down on IOS. Fortunately, most of the seemed to agree with us.
Once our 30 min where up (they actually stayed longer since they were hooked with what we had to say), we immediately move to the “Show and tell” part of the sprint. We started to make a quick research on how to make the communication more efficient, this in order to create a better community around IOS.
With the map on the board, and the problem we were trying to solve quite clear, we started to investigate with different solutions and products out there. After an hour or so had passed, we began with the “Lightning Demos” — three-minute demonstrations to share our findings (in all frankness we took a lot more than that!).
After this, we each had an idea of how the app should look like, And so we began to put it down on paper. Each person creates a detailed concept for how the experience could work. To be honest having done this again and again on each sprint, it doesn’t get any easier. But also, is quite fun doing it for each new idea you have to work with. By the end the results tend to be quite good.
For Wednesday, each person will have their own sketches. We try to make them anonymous (something quite impossible to do). After done, the team doesn’t look at them until Wednesday morning so we can start tearing them apart one by one and then put them together to build a Frankenstein.
Day 3 — Wednesday: Sketching for the user
Wednesday morning, the room of silence. Unlike the rest of the days of the sprint on which we all talk and think out loud, today is quite different, at least for almost an hour. In total silence, each of the member start to understand each of the others flows.
Again, we critiqued the ideas, and on each of the flows, we posted notes of what we though of didn’t understood. Later to work on a “heat-map” by voting on the ones we thought were the best ideas. However, the Decision Maker (Ianis) has the final decision on which aspects of the sketches to use for the final version.
Finally, after all the silent review, questioning, commenting, voting and joking (Ianis flow gave us a lot of good laughs), we had decided what should be in the prototype.
So, the time had come to build this beautiful Frankenstein. With this done, the sketching started. The window became our precious canvas. Screen-by-screen, the flow started to take shape. By taking ideas for the various sketches around the room and applying them to a new, single concept the magic began. This, is the most important part of the Sprint. Why? well from this we can only pivot so far from the idea, due to the time left on the clock.
As usually as with every sprint, by the end of the 3rd day, we knew exactly what we’re building.
By the time we left the room, we had 5 complete flows, fully designed based on the business aspects we needed to test — and a FINAL design ready to be prototype. And as always, we think we nailed it!
Day 4 — Thursday: Work work work work
No time for questions, hands on the Mac and start working. Just kidding… but not really.
We have less than 24 hours to build a non-functional prototype that the users love and understand or we fail.
Today is one of the few days that allows us to have devices. With most of the decisions made, every one stays focused on their respective tasks.
This is where the process proves why you need to stay focus during the past days. By the time we start working, we already had designed the prototype and we knew what had to be done.
One crucial part of the process that some fail to execute, are the interview questions. We need to set a way to learn the most out of the users in less than an hour not only from them (to set their profiles), but also to see what the product reflected on them.
By the end of the day while seeing the prototype almost done, it enables the team to make final decisions to improve usability.
As always thanks to the team, we were able to create a realistic prototype in record time using Sketch + Marvel.
Day 5 — Friday: Where we right?
The time of truth. The last day is about the user validation. So, we did the cameras and audio arrangements for the users to be analyzed and questioned while we present them the prototype.
We settled into two rooms, one on a private space where we recieved the users to talk to them and show them the prototype on a phone and do all the interviews and recordings. The other where the rest of the team will take notes and analyze more deeply all the answers.
Having the prototype being so realistic, users can easily envision what it was for, and give detailed feedback about things they liked and were confused about.
So, while we started our interviewing session, we realized that the age range was way wider that we expected to be. Lots of different profiles and plenty of variations regarding the likes and dislikes of each person. Never the less, people quickly get what the app was meant for and easily navigated through it.
Some our initial doubts were reaffirmed when we got the user reactions. They all wanted a closed platform with only current users, that allowed them easier communication. And also the idea of getting rid of the emails was a hit!
Little feedback that required small changes on the app was given. And by the end of the day we had interviewed 6 profiles and we were done! (mentally and physically).
With all the info gathered and all suggestions done, we knew the path taken and the implementation made had been, right on the spot.
“It is amazing what you guys did in only one week. We never though we could end up with something this elaborated in such short time!
— IOS Team
With the help of a process like Design Sprints, we were able to do this in just 5 days. Never forget that the steps to follow are a guide line. The execution of the members is extremely important for the final outcome. Also the chemistry and the relationship you develop over the curse of the week with the client and the team, has a lot of weight on the final outcome.
Like we said at the begging; “what you think you need, is not always right”. Even when we decided not to do what the client asked for right at the start of our conversations, didn’t followed what they had in mind. The outcome was, according with the clients; great and exactly what they needed to make their life easier at IOS Offices. They said, that it would help them to create a tighter community, and get rid of the constant emails (which are currently blacklisted from some servers).
Our Sprint Team for this Project
- Alex Sandoval Operations Manager, is the Operations Manager at Icalia Labs, has over 7 years’ background as a developer. Check him out on Linkedin of follow him on Github or Twitter.
- Noe Araujo Product Designer & Lead Designer at Icalia Labs, has over 6 years working with desing and great part of this has been with digital products. Check more of him at Dribbble or follow him on Twitter
- Scarlett Garza Designer and Front End Developer, is an awesome designer, with tons of front end developing. You can check her out on Linkedin of follow her at Dribbble
