Challenge: Umbilicus mundi. Being a corporate monster, disrupt your own market before a small startup does it.
Empires. Ancient nations, ruling beyond their boundaries by force –or more discreetly by indirect power– or the present corporate hydras, taking domain of cross-oceans markets. If there's something that connects these two kinds, is the effort and time invested in preventing or fighting a soon-to-come oblivion caused by a small, quick and always external threat. But each time this paranoia caused the sovereigns to run in circles, it was actually the same empire that was preparing its own fall. It was no plot, but a conundrum called institutions (processes and protocols, to assure certain stability) what created the breeding ground for a fall.
Ill of its inner processes and protocols as world-class classifieds company, OLX brought in a couple of outsiders to create a small and global innovation team. In –what I assume it was– a shock-therapy effort to incorporate some foreign DNA hoping to grow some inmune defenses based on it. I was part of that couple. The team grew organically and very healthily, though I can't say the same of the expected cultural changes. First symptom of that: if you tell someone there is an innovation team, suddenly they assume is not their responsibility to innovate anymore, pretty logical to be fair...
From MVP experiment to a 15 markets full product.
After a year and a half of harvesting an awesome team and some small successes with big inner impact, suddenly –and once more– a small, quick and external threat took the whole empire's attention and was blamed for everything happening to it. Being our innovation team the closest to this threat, the empire's move was analogue to the deployment of the Varangian Guard towards the barbarians. We were asked to create a product from scratch to disrupt the classifieds markets before somebody else could do it. We had three months before going live. Even being a very fast and agile team, we needed to double-down all efforts to make it and we needed a one-shot kill anyway. A dead and very small market was set as the first test scenario. An unknown place to us where no classifieds lifeforms had been able to survive. Somehow, we managed to get there by launching Letgo before the 3 months deadline...
"Somehow"? you really don't know how you did this?
Actually I can explain a bit of how: By the time we took the project as a team, we already were a really oiled and productive machine. Our design thinking and agile loop had been working like a charm for a year already for the innovation team's projects. It was a very user-centric team. The whole product and tech team had a really good idea of who the classifieds users were and their needs, after being exposed together to more than 150hrs of moderated user testing and interviews with users from around the world. Attendance was above 80% of the team each time. We also had some awesome and, more important, eager to share and explain product and business analysts. As well as an impressive development team, not only technically speaking, but very product-minded and willing to learn, to collaborate and also to question our UX and product practices. Also, we had an incredible sponsor regarding UX research priority, what increased a lot our chances of a one-shot-kill, and our team was safe-space where we could suggest or point out anything.
The Letgo UX work and process evolution could be split in 3 stages. A first original design stage, where we tried to find out and validate which product should we design and build in order to solve the users' needs we should cover as a classifieds platform to dominate the young, digital-natives market. The second stage would be to prepare and adapt this green sprout to compete as a massive product without losing its essence as differential. The third and final stage would be to develop low-risk and low-cost iterative research and design processes to extend the product's functionality. That must be done in order to let several teams to work cohesively on their own objetives.
Stage I: From board doodles to launching.
During the first 6 months I set my focus on the first stage. As usual, the first thing we need to do was to undress the business requirements to reveal underneath the set of hypothesis and product-related sub-hypothesis based on their business findings. Usually those requirements are something similar to: "We did some benchmarking and followed the market movements for a while... we have to do X, because our competitors did it and worked".
After going through that information ourselves, I organized a user interview session for my team to have the opportunity to ask people about certain topics and compare those assumptions to the users expressions on their thinking, behavior, the reasons behind their behavior and to know a bit about their context and priorities regarding the needs our product should cover according to them.
As we had preached as an innovation team, we did a team task of this. Even though I was alone in the room moderating the interviews, the team not only observed and discussed each case with me, but they also usually had a chat channel to send me their questions outside the interview structure. This kind of hybrid between in-depth, structured interview with something more spontaneous allowed us to get a lot and deeper insights of each case than a more orthodox method. Extensive team observation of a reduced amount of cases gave us multiple data points on each topic and not only saturated information but enriched one via the multiple perspectives a multidisciplinary team could have.
With our users mental model already in the sight, I organized a collaborative design workshop for all the team. I split it into 3 main needs we should cover according our interview's insights. Then we worked in pairs to design proposals covering each of the needs, I think we set 30 mins for each including the pitching time for the prototype for the rest of the team. As a result we got focused discussions around each need and plenty of proposals as triggers to discuss approaches, priorities, effectiveness and costs of each.
I took all this home to start working on some early prototypes considering all we heard from users, all we had discussed (and my designer gut as well). Once this first prototypes were ready we tested them with users. Again, this was a team task. Participation was key for developers to start having a better idea of what they should research and estimate with product guys to start building a realistic backlog. Product guys would have a better idea of how to prioritize each feature, what could be left behind and what was crucial to cover (for the users and for the business). Designers...well, design perception testing has its own paragraph below but regarding usability and interaction, designers would understand better how the product should feel for users to suit them as satisfactory.
Knowing how a product looks and feels for the user
Think-aloud protocol is focused on user behavior, effectiveness and efficiency in the results of a given task, all rational parameters. As a collateral, the emotions that a product wakes on its users while in use, are very difficult to observe (except when this is a very unsatisfying experience). Even when getting some information, this is very hard to transform into something actionable without a very long discussion based in assumptions.
To tackle this, we used a set of 8 likert-5 scales comprehending two opposite but both positive attributes as poles of each scale (ex.: a scale from surprising to predictable). After the users had ran through the product test, we asked them to vote on each scale according to what they felt the product was for them, then I asked them to explain the reasons behind each vote on each scale.
That gave us a good idea of how the product was perceived, what we should reinforce or rework and where were the attention-dragging points to shine with design (and where to avoid extra complications for the users). We even got what vocabulary would the users use to communicate our product experience to others.
Later on, considering the qualitative insights, we built an average product perception matrix also and we followed its evolution from test to test.
Iterate, iterate, iterate
All this was done in a iterative loop, we tested each prototype for different tasks in an additive process, as we had each feature ready covering a certain task, we added the task to the testing protocol. So we made sure to start by the most important task to have it better (more) user-tested.
After this process, we had to design all in order to be developed, provide assets and –instead of documenting design– we sat next to the front-end developers to make sure they had everything to build it properly and do Design QA with them: "X-Raying" the screen captures of alpha versions overlapped to the photoshop original designs and debugging every pixel out of place, every color out of the palette. I have to say I had never worked with developers this patient to the exhausting process of design QA (that I DO hate as much as them, but it definitely makes the difference).
A first market-ready version was ready to be launched after all this. We expected this product to work fine, but given to us a dead market as a first one, we didn't know if that (or anything) would be enough to move it. The first and preliminary numbers we got after a couple of weeks told us clearly that we should have been preparing ourselves for an overwhelming success instead of thinking that much of contingency plans of a harsh landing!
Wow! Thanks for following me up to here! Stage II and Stage III of the process will be part of my next article.