If you’ve ever worked on any remote or “outsourced” team then you’re about to be nodding your head. Unfortunately, all too familiar with the all too many problems of communication that arise. Often times the distance barrier creates misunderstandings and those misunderstandings lead to false assumptions which have far worse implications. Getting results with remote teams can often seem like asking for the impossible.
I’ve been there. I assumed that the developer would include a hover state even if one isn’t explicitly given in the design. I’ve assumed the team will be intuitive enough to understand common components. I’ve assumed that when something is a pixel off in certain areas, the developer will use the convention and forgive the extra pixel.
Failing enough times, I’ve learned that none of these assumptions can be made when the team is:
1) unaware of the product’s goals and roadmap
2) comes from a different culture
3) takes what is presented to them literally and executes on those designs fully (and without thought)
Building software is incredibly hard – it’s why there are so many tools in the market competing to help us stay on track (Trello, Basecamp, Jira, Asana, etc.) and so many internal processors familiar to teams (use cases, user stories, agile, kanban, waterfall) just so a few folks can be on the same page about a product’s needs.
Even with all these tools and systems, when keeping a project on track, the team still needs extensively crafted and detailed designs, as well as extensive and thorough project management. Though being too regimented makes it pretty hard to be agile and adapt to changes in the market.
One of the first projects I worked on after transitioning into software design had an extensive remote team with people living in different time zones.
We needed a way of communicating quickly, and effectively, the needs of the software we were building. We needed to be sure that everyone was on the same page, and knew what the mission was. To solve for this, we used a visual Information Architecture language – this permitted everyone to be aligned, work efficiently, and minimize risks while building a product.
What is IA?
Standard Information Architecture (IA) is a way for structuring information – it’s a tool to define the hierarchy of a system, the experiences a user passes through, and the organization of data. While this is an absolutely necessary part of development, I’ve learned that adding a visual layer creates an invaluable level of understanding across the whole team.
What is Visual IA?
Visual Information Architecture is a system for defining all the features in a product or app. It utilizes site maps and flows to create the blueprint for any software technology you’re planning on creating. It creates the structure, categorizes information, and determines content hierarchy, just like a standard IA. However, it also determines content, addresses feature sets, and in conjunction with user stories, determines the roadmap for building software.
This is a simple login-flow example:
The core benefit and power of this visual system is that a team member can see exactly what needs to be communicated quickly. It is a lot easier and faster than reading a series of cumbersome user story notes. Further, a designer or developer can take the diagram and begin to work off of it without any explanations. That ability for a new team member to jump in at this stage with no prior knowledge and be able to create a full app from this doc — that’s kinda priceless. Actually, it can be priced. It’s the cost of on-boarding new team members. While ideally no one comes onto a project blind, having a full map for them to understand saves a lot of time and confusion.
How do we make a visual IA?
Let’s start at the beginning.
We begin with a user walkthrough. This is the process of telling a story about a user and how they would use the product. This user, who usually has a name and corresponding identity, makes a decision to open – enter – experience the digital offering we are creating. (Let’s go with Max, he’s an accountant and this is a tool to help him see the state of his clients accounting needs.)
Max opens the app. It’s his first time, so he’ll need to register. On the registration page — what do we see? We see the ability to add a name, enter a password, accept a TOS ?, and potentially upload a photo. Once Max is set with that, he can hit “next” and move on to the next step.
Pretty simple. Pretty Straightforward. So what are we doing? We’re listing every single element that can possibly exist in this area, and noting their interactions. This allows us to put to paper if they have anything else that needs to be captured.
Next. Where does this section land us? Again, we ask the question of “what do we see” and lay out the sections and content that exist there. Literally — if there is going to be text, if there is going to be a user avatar, if there is going to be title text — this needs to be noted.
As we continue, we refine it more and more. Until it starts to look more like this.
One way of thinking about this is like a really simplified wireframe mixed with a site flow — one that has no design, and almost no layout, but refers to all the features that would exist.
Why isn’t this more popular?
Visual IA requires a certain thinking structure — the ability to hold multiple distinct options collectively in the mind before weighing each potential options benefits, then laying those benefits down on paper. It requires you to dive into the user’s mind and walk through scenarios in their shoes. You do this over and over, until you’ve discovered all the places a user might need to go. Then, you understand the drivers that exist to move them through these motions.
This may be why so many teams skip the process — it’s hard, tedious and requires significant concentration. It can take years to learn to do this well, as most things do. Though, the benefits—both the personal ones as a product owner and the benefits to the product itself—allows us to create far superior products in a shorter period of time, and communicate these strengths to remote teams.
If you’re having problems communicating feature sets and getting the results you need, try out this visual IA approach. The journey might be long, but it’ll be worth it.
* * *
The way we create IA at SWARM for app development is far more comprehensive than any other studio or team I’ve worked with in the past, and I owe this to Laura Strong and Marvin Avilez who taught me how to approach the language in the first place.
