Interact Jones and the raiders of the lost library
This summer we had an internal discussion here at Interactius about which prototyping tool should we use in order to speed up our timings delivering wireframes because we were wasting a lot of time with our actual tool (Wireframe Pro).
As a person that loves to test all kind of apps, I started my own crusade to find the best tool for our team.
Here, we want to share with you this process in a different way, so we made an analogy between Indiana Jones and our journey.
Now, let the story begin.
Act 1: Research: Finding the Holy Grail
As every Indiana Jones film shows us, the first step in our journey starts with a little bit of investigation.
Archeology is the search of fact, not truth. If it’s truth you are interested in, Dr. Tyree’s philosophy class is right down the hall. — Indiana Jones
Before starting the benchmarking, it was mandatory to list all the weaknesses we had experienced with our actual tool and which strengths our new prototyping tool should have.
What do we wanted to achieve with the session? Easy: align all team members and choose the right metrics to review the tools. The first rule of any archeologist is: we can’t go find a treasure without knowing what are we looking for.
Must: Desktop version, Sketch plugin, Fast prototyping, Low and high fidelity wireframes, full adaptable wireframe libraries (Desktop, mobile, tablet).
Nice to have: Collaborative, cheap.
Once all the insights were gathered, I started a benchmarking of the 8 most powerful prototyping tools in the market. Second rule of archeology: Always relate to other findings to evaluate what you get.
Then, I presented the report to the team hoping they will follow me to the search of the Holy Grail. My proposal was neither the easiest, nor the most popular between UX teams, but I think it was the only one that could give us some personality and a signature in the way of creating wireframes and interactive prototypes. This solution was Sketch + internal wireframes library. After all, Indiana Jones didn’t find the Holy Grail without risking his own life!
Some of the questions that popped up in the meeting were:
Which kind of wireframes do we want to deliver to our clients?
Looking back to all our previous work, we found that we were doing more high-fidelity wireframes than low-fi ones; we also agreed that there should be an early paper wireframe iteration with the client, where they could share with us their vision of the product in a tangible way.
The golden question: How many hours does the implementation from scratch of the library is going to cost?
To avoid investing a lot of hours creating all the elements for the wireframes, we found a library that fulfilled all our needs. We were lucky, in this sense it was like a branch saving us from the leap in the dark in our adventure. But which kind of designers would we be if we just copy another’s designer job? Not very impressive ones, so keep reading if you want to find out how we achieve our Holy Grail.
Now, we knew where to find the tool but we didn’t have the instruments (library) to start our wireframes, so I chose two brave and fearless partners to help me in this task; Alexandre Cuadrado & Fabio Berloffa, two of our best designers who don’t feel scary confronting uncertainty.
Act 2: Decode the cave traps
We entered into the cave with our hats and whips prepared to avoid all the traps we could find.
Our first challenge came early, we needed to find the best design system to assure an understandable and easy way to use the library for all our users. Fortunately, my two colleagues had already made design systems in other projects using Atomic Design, so they were very confident to translate this knowledge into our wireframes library. We started by listing all the elements we had in the library of Wireframe pro and in the library we just acquired. That provided us with an overview of how we could split our system.
After we finished our first draft of elements we started to face other challenges like the need to adapt Atomic Design system to our own. How are we going to split the components of the library?
This is the part of the story where we entered the catacombs of the project, swimming through a canal full of rats trying to fill the gaps we were missing in our crusade to the Holy Grail. We started walking through the canals with no correct path, blinded by the darkness that surrounded us, until one of us grabbed a skeletal bone, wrapped it in a piece of cloth and lit it with the lighter. Then, we found Sr.Richard’s grave. We opened the tomb and inside there was an inscription on a shield telling us that the best solution to our questions was to use a programming algorithm called Divide & Conquer, where each one of us should select an Atomic design level and try to encapsulate its components.
Couple of days later we joined all the information together and adjust it to fit our requirements. Of course, it was not easy and we had to discuss some components going back and forth, checking whether the granularity of the system worked for all the cases, etc.
Finally, we figured out a solution that might be controversial but fits our requirements and our needs (that’s the most important thing). Third rule of archeologists: don’t mix your stuff in your bag.
We separated our system in four layers:
- Interactoms: In honor to our team. It contains all the set of colors, icons, cursors and mockups.
- Atoms: Where we have all the basic building blocks that matter like buttons, dropdowns, checkboxes, etc.
- Molecules: This layer has the characteristic of been divided between mobile and desktop, in order to create different components depending on which platform we are.
- Tools: The last layer contains the elements we use to describe the wireframes functionalities and the workflow they should follow.
We split some Atom’s components in two because we had a lot of them in one place and that supposed a problem when finding an element quickly. We also thought that Organisms (present in Atomic Design) were not needed due to the fact that each of our projects are different and we tried to improve and innovate in every one.
As I wrote in the first act, we used an already available library to speed up ours but the bulk of the library was made by us. The reason: we needed to be fully responsive, no matter the size of the screen and the text/icon/component had to be able to be overrided. That way every project can have its own differences with less effort.
Act 3: Get the Holy Grail, run and reflect
At this time of the film Indie was already caught by the enemy and is forced to help them with the challenges before reaching the Grail, so this act is about the last challenges we faced. Let me present you the FOUR CHALLENGES.
First Challenge: The breath of God
Only the penitent man will pass.
This challenge was about letting a small team try the library so they could give us qualitative feedback about it.
With their comments we saw some components were missing, that the learning curve was higher than we expected and that we needed to readjust some of the components, as the resizing items and some copies were giving us problems.
Second Challenge: The word of God
Only in the footsteps of God will he proceed
This challenge was about speeding up the process. We found a plugin called Sketch runner. The idea behind it is the same as the one in MacOS Spotlight, there is a keyboard shortcut that triggers the search engine and you just need to type the component’s name and press Enter.
Third Challenge: The path of God
Only in the leap from the lion’s head will he prove his worth
This was the most complicated challenge, releasing the library in real projects. We started with a single project, to see how the team and the client would react to the change.
The conclusion was that the team speeded up his time doing wireframes after some days working with it and the client was also satisfied with the new wireframes design.
Fourth Challenge: Choose the right Grail
We have to come back to the beginning. At that moment, we had a lot of valid options that could help us with our wireframes, I guess in your companies most of you are using ready-to-use libraries but we felt that this wasn’t the real Grail for us, didn’t represent who we are neither our company values “Be a craftman/craftwoman”. We wanted to have our own signature, something representative that our clients acknowledged when they see it.
Some of you might want to have the library but as the Templates guarding the Holy Grail said:
You have chosen wisely but the Grail cannot pass beyond the Great Seal. That is the boundary and the price of immortality.
This is not the end, we will need to improve our library, expand our ecosystem with new tools and standarize all these processes between projects.
P.D. No human casualties were reported in the implementation of the library.
Thanks to Fabio Berloffa for helping me developing this crazy post and for his amazing illustrations. Also thanks to Adriana Almada Ortiz and Josh Morales for helping me correcting the text and for giving me new ideas and last but not least thanks to all the Interactius team to be an active part in the creation of the library, specially to Alexandre Cuadrado (the one on the right side in the cover) for his amazing work in all the library creation.
