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 from the app. We also need a solution that helps our prospects to become members directly from the app itself.”
— Ianis Defendini
First Meeting

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 office spaces around Mexico), telling us how they already had built some solutions, and that they weren’t being used by their clients, either because they were incomplete, non-useful or just unkown by their clients.

We listened to all of their current problems and realized how much complexity they were planning to bring to what they thought was going to be “The key app to solve all their issues, and that all clients would love”. After discussing the origin and foundation of these ideas, we then suggested they should actually figure out what clients wanted and needed before building a very complex solution. We talked about the risk and potential waste and opportunity cost, which clearly resonated with their recent experience.

Because the exact jobs to be done in order to fully satisfy IOS's clients wants and needs weren't clear - although some interesting alternatives were discussed - we suggested to start with a Design Sprint, explained the concept and how it would help tackle this problem, and Ianis was onboard with the idea. So we began this 5 days adventure.

Day 1 — Monday: Asking the right questions

To make the Design Sprint easier to the IOS experts and decision makers, we had it take place at IOS Offices. The first thing we asked on Monday was: What are we trying to accomplish? Ianis promptly answer that it was for us to understand how to build an app with all the functionality around the IOS environment that was friendly and engaging to their clients.

We started asking what they've done in the past to solve this problems. He showed us some applications as well as some websites that let you do A LOT of stuff. One of the apps even showed their monthly magazine. He later told us a lot of information and how the partners, most of the time, had no idea of the things that were going on at IOS. Then he told us that he wanted to create a better community with the events they organized and other activities they usually have.

After a long Q&A and lots of back and forth, we had an idea of what the main issue of the company was and how things were being done, as well as some ideas of why their previous efforts 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, it was clear that it was meant for the current partners. This enabled us to jump quickly into a deep productive conversation.
By lunch time on Monday we had mapped the whole process revolving around IOS's ecosystem, who the key players were, and what goals we were trying to accomplish.

Monday's afternoon was dedicated to interviewing various guest experts, including IOS's CEO, capturing and gathering all the relevant info and feedback based on their experiences, in order to understand how we might tackle the main problem, what obstacles we could expect to find, and how to overcome these in turn. A lot of this information was used to complete and alter our map.

Day 2 — Tuesday: Sketching solutions

With Monday's map on the board and all the understanding we acquired, we were ready to begin pouring ideas into paper.
We began by investigating and discussing different existing solutions and seeking for similar products out there. After an hour or so had passed, we began with the “Lightning Demos” — three-minute demonstrations to share our findings and curate great existing ideas that could inspire specific parts of our solution.

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 created a detailed concept for how the UX could work. We built up from individual ideas, to individual sketches, revised over and over until each person in the Sprint team had at least a final 'presentation-worthy' sketch of a solution they wanted to propose to tackle the most critical problems and help reach IOS's goal.
Note how this process works in opposition to the typical Brainstorming process, because we have proven over and over again that this individual evolution of thoughts and ideas beats Brainstorming everytime when it comes to the quality of the solutions.

Day 3 — Wednesday: Decisions, decisions

Unlike other days, Wednesday begins with total silence. Each person's (anonymous) sketches were mounted on the conference room walls, just like an art museum. Then we each took our time to look at and individually try to understand each sketch.

Through time-driven and time-limited flows we then criticized each of the ideas as a group, and on each of the flows we posted notes of what we didn’t understood or thought was missing. Later we worked on a “heat-map” by voting with stickers on the ones we thought might work the best.

Based on the voting and the decision maker's last thoughts we dedicated the rest of the day to building a concrete, cohesive storyboard that seamlessly integrated the best ideas sketched and voted on. This story board allowed us to have greater clarity of what exactly were we going to build on thursday, and also shed light upon some other key points regarding product consistency.

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: Prototyping

On thursday we have less than a day to build a non-functional, yet interactive prototype that the users will love and understand or else we fail.

This is where the process proves why you need to stay focus during the previous days. By the time we started working, we already had designed the prototype and we knew what had to be done, which is usually the most time-consuming and energy-draining part of prototyping a solution.

The whole day on Thursday our lead designers were dedicated to creating and mounting all the interfaces on specialized prototyping software, while the rest of the team focused on writing (the prototype needs to look AND read realistically), gathering digital assets such as logos and photos for the prototype, and stitching up, making sure the whole interface flow made sense towards the experience we were trying to test.

In order to have a believable result on friday not only did we need a prototype, but a well structured interview flow, so the other big task to tackle on Thursday was to write and revise the interview script, making sure we touched and assessed all the key assumptions the team was looking to prove.

Day 5 — Friday: Were we right?

Friday's the time of truth. This last day is all about validating our ideas with the actual users of the product. So, we did the cameras and audio arrangements for the users to be analyzed and questioned while we present the prototype to them.

We designated an interviewer who would sit in a private room alone with each user, guiding them into the testing of the actual prototype and afterwards conducting an interview, proving for further unbiased feedback that would come in handy for validating and improving the product.
The rest of the team gathered in the conference room where they observed all of the user's interactions and reactions through a live video feed, taking notes and even doing small enhancements to the prototype on the go.

Because our prototype felt like a real product, users could easily understand what it did, and give detailed feedback about things they liked and things they were confused about.

While we started our interviewing session, we realized that the age range was way wider than we expected it to be. Lots of different profiles and plenty of variations regarding the likes and dislikes of each person. Nevertheless, people quickly got what the app was meant for and easily navigated through it.

Some of our initial assumptions were reaffirmed as users reacted to the prototype. They all wanted a closed platform with only current IOS partners, that allowed them to have easier communication. Also the idea of getting rid of the emails that were currently sent and replace them with in-app notifications was a hit!

By the end of the day on Friday we had gathered an enormous ammount of business intelligence in regard of the 'jobs-to-be-done' and what exactly the IOS App should and shouldn't do. The user tests and interviews were vastly helpful in helping us figure out problems way ahead of time, helping us focus on the most important things, and do all the fine tuning of the app before even building the real thing.

At the end of the whole process not only had we validated the core ideas of the new app, but we had generated all the user stories needed to swiftly move through an agile development process and IOS had two attached 'experts' inside the Icalia team who greatly understood the business, its goals and challenges, and the user profiles that would be using the app. Needless to say Ianis felt way more secure in investing on the new app and the team as a whole was ready to move on to the development phase with a lot more certainty and guided optimism.