Strategy
Reimagining digital strategy and how we document data architecture
An overview of how I created an app that allows our teams to communicate and strategize better.
One of the most influential life lessons that I follow every day is about planning — which teaches us that if you fail to plan, then you are planning to fail. You may wonder if planning really is that important. Uh, yes — yes, it is.
As part of a digital agency, planning is one of the core phases of every project we engage with. The ability for us to strategize as a team really feels like a game of chess. Every piece has a purpose, and if you plan well in advance, you just might make it out alive.
When it came to planning, communicating, and documenting data architecture, I noticed that our organization had some inefficiencies — repeated issues that chewed up both time and money. This past year, I sought out to design and develop a tool that would build in efficiency into our process — and look good while doing it too.
Digital strategy has always been about connecting people to information through well-informed navigation.
For most projects we’ve engaged with, there had been some level of documentation around research and data architecture. Who is this product for? What information are they seeking? How will they get to this information? Rinse and repeat. I can safely say that digital strategy boiled down into three primary areas:
People.
Until the robot apocalypse occurs (it’s only a matter of time), the products we design and develop are to be consumed and engaged by people. Whether we put together assumptions on personas or we conduct user research and interview actual people, it’s important that we document the characteristics of these people to help us understand them better. The better we understand, the more accurate our recommendations become. Empathy is a powerful emotion that we can use to connect with people.
Information.
Let’s be honest — the main reason people use our products is for the information. Information can come in many forms, such as products or services. They can also tell stories and evoke emotions. We use content strategy methodologies to define and organize content that audiences will demand. More specifically, content models help document information with a brand, and defines the relationship between them. These relationships help shape up things like data types, taxonomies, and templates. Content is king, after all.
Navigation.
The bridge that connects people to the information they desire is through well-informed navigation. Even the most desired information becomes useless if people cannot ultimately find it. We frame our content and navigation around sitemaps. Sitemaps help us show connections between our content, and give’s us a bird’s eye view of the product. Keeping our content well-organized allows us to provide better design solutions.
Documentation for us was as messy as an overloaded PB&J on a hot summer day.
Did that get your attention? As the creative lead in our organization, I likely have reviewed as much — if not more — documentation around research and data architecture than our engineers. Teams can do their jobs better when documentation is well-written. After countless hours of reviewing documentation across various projects, I was able to audit on just how good we were documenting and setting ourselves up for success for digital strategy. Spoiler alert — it wasn’t pretty.
Each project was almost entirely different in their approach to documentation, yet they all shared similar problems, like:
- Too many documents
- Too many file formats
- Too many locations
- Inconsistent branding
- Proprietary software or hardware
Are you nodding your head? Does this ring a bell? Needless to say, our documentation was fragmented and ineffective.
Our visual sitemaps were not environmentally-friendly.
One document that we typically produce in projects is called a visual sitemap. These are graphical representations of a website or applications content, and the connections made between them. What makes them unique is how we apply illustrations that best represent the kind of information each page may have. Visual sitemaps can give us a glimpse into user journeys, template architecture, and so much more. Often times, we print these sitemaps on a wide-format printer, which gives us a tangible poster for the team to review collectively.
As you can imagine, large-scale sites or apps can make for some impressively large visual sitemaps. When you account for multiple revisions, projects can end up wasting lots of paper and ink in order to produce these. Not cool.
Documentation was riddled with inabilities to find, comprehend, and update information.
Cultural diversity in technology and inadequate governance policies ultimately made using Google Drive as our repository for documentation ineffective. Documents were being created in various applications based on personal preferences, projects were not being shared properly to team members, nothing appeared to be brand-compliant, etc. Drive was supposed to be the answer for us. It wasn’t.
Remember the visual sitemaps? We used to make those in Omnigraffle. Personally, I love Omnigraffle for making diagrams, however, if the designers weren’t available to make edits, the rest of our team could not help — Omnigraffle requires both macOS and a paid license. Sorry Windows.
To make matters worse were the other ways documentation got out of hand. Some were posted as activity notes in our project management platform (which almost always gets lost), while others were simply emailed between one another. As if that weren’t bad enough, we’ve ran across files that were stored on people’s desktops — or worse — in their trash bin. Ugh, seriously?
If you were not part of the project team from the very beginning, getting involved became almost impossible. The landscape of how we documented and stored our plan of actions was chaotic. When you can’t effectively communicate with your team or even comprehend what is going on, you ultimately waste both time and money. It’s game over.
Design an inclusive app that promotes better team communication and strategy? Yes, please.
From what I could tell, addressing these issues felt trivial. It was like going to each identifiable problem and flipping a switch. I wanted to design and build an application that:
- Centralized documentation into a single location
- Allowed access cross-platform
- Automatically applied branding to all documentation
- Reduced dependency on 3rd party software
- Reduced or eliminated ink and paper waste
By creating an app that can do all of that, we could reduce wasted costs on hunting down documentation and allow teams to spend more time on making awesome products.
What if we could use technology to help us make better decisions? Improve planning? By allowing the application to display real-time metrics — like page counts, page title lengths, and persona distribution — we could make more-informed decisions around the data architecture. Pretty sweet, right?
I branded and called the app Sapphire — for its clarity, strength, and beauty around providing value to us. It was also considered a hidden gem in disguise. Sapphire’s core value is about being a real-time data architecture planning tool — that can help us strategize digital products at any scale.
More empathy for people.
Sapphire makes it very easy to define and explore personas for projects. Every project can create as many personas as necessary, with just the right amount of information at a glance. It’s incredibly easy for team members — especially designers — to empathize with a person’s goals or frustrations.
Better organization for content.
Creating the architecture around a project’s content is well-organized and effortless. Each project can have content broken into data types, taxonomies, templates, and pages. In fact, you can also create relationships between pages and people. This allows us to understand who our target audience truly is.
Crystal-clear perspective on navigation.
In the past, we had to document the same information multiple times. The best part about Sapphire is that both branding and visual sitemaps are automatically generated in real-time. If I could get people to focus on the content and nothing else, Sapphire could handle the rest. Visual sitemaps are fully interactive, allowing anyone to explore pages and what architecture goes into each one.
Build a single-page app with an emphasis on speed and intuition? Truly magical.
In order to provide such a rich experience, I wanted to ensure Sapphire was using the latest technology. With performance being an important factor, I needed to choose technologies that were built for speed.
Sapphire was built on React — as both a progressive web app and single page app — and used Google Firebase for its NoSQL real-time database. Users were authenticated securely using Google Domain Authentication and was securely hosted through Google Cloud Hosting. All of these technologies were relatively easy to pick up on and wire up together. Did I mention I’m a unicorn? Considering I work for an organization who touts Amazon Web Services so much, it was nice to see that we can just as easily build and deploy an app through Google too if needed.
To power our intuitive sitemaps, I opted for jsPlumb framework over something like D3 — primarily due to time constraints and the amount of effort required. I’ll admit, jsPlumb integrated extremely well with React and allowed me the power to customize as I needed to match the desired functionality.
Could Sapphire turn into a SaaS offering? I don’t know, maybe. If we spread the word about how it has helped us internally — and people show enough interest — then maybe we open this up to the community. Let us know! That would be pretty sweet to hear how other teams succeed by using it.
Final thoughts on digital strategy.
Documentation allows teams to communicate and work together on projects of any scale. Digital strategy around architecture plays an important role in documenting how products should work. When we ignore documentation — or simply allow it to deteriorate over time — we are hurting our ability to communicate effectively.
By recognizing these problems, I was able to design, develop, and deploy a tool that helps us reimagine digital strategy and how we document data architecture. When we can work better together as a team, anything is possible. Make something people love!
