Successful design strategy happens with healthy consideration of form and function, business goals, and user needs
Gliffy was looking to grow its core business by adding a new product that complements our existing diagramming tool and increases its value to existing customers, while opening us up to capture new customers.
Goals
We set out to create a new Gliffy product that achieves these business goals:
- Continue our focus on software development teams, specifically in product development
- Create a high-use product, in terms of both frequency and breadth — ideally used daily (frequency) across product development team functions (breadth)
- Expand upon Gliffy’s visual tools “superpower”
- Strengthen Gliffy’s foothold as a top vendor in the Atlassian Marketplace
- Self-serve and inherently viral — create a product that teams use together, anyone can start using and adoption snowballs naturally through its use
Gliffy's existing core product tended to be used infrequently, and by few people within a product team. How might we create a new product that is complementary, adds value for existing users, and increases our overall product adoption and usage in teams?
Research & Problem Discovery
Through existing customer, non-customer, and competitive research, we identified the following three pain points that development teams were consistently faced with:
- Scattered communication and project documentation
• Team communication is scattered across email, IM chats, meetings, wikis, and task management software.
• It’s difficult to keep track of current status, what’s done, what needs to be done, etc. - Ticketing systems are text-based, while people and products are inherently visual
• It’s time-consuming to understand how written tickets relate to visual designs, user flows, software and information architectures, and complex systems.
• Details get lost in translation, leading to incomplete and inaccurate product experiences, wasted work, increased cost, and frustrated teams. - Complex projects need a single source of truth
• There is often not a single, up-to-date destination for teams to see the current state of their projects, what needs to get done and why, and the long-term vision
• Development teams are often guessing what’s needed due to unclear or hidden product requirements, slowing progress and limiting their ability to execute
Understand pain points by viewing problems from different angles
Uncover unexpected opportunities by mapping the problem space
Simply talking to customers isn’t always enough — our team shared interview-processing and note-taking, leading to better pattern identification and meaningful insights shared across members
Design Pillars
With a clearly defined set of user personas and high-value problem to solve, our team started to explore possible solutions.
We established a set of design pillars — constraints for the team to get creative within, while ensuring we stayed focused on our users' needs and our business goals:
- Pillar 1 - Consumer-grade enterprise product
The status quo is that enterprise products are stuffy and ugly, bloated and inefficient, out of date and hard to use — products with little regard for user needs, polish, or delight. Our opportunity was to treat our enterprise product experience with the same care, craft, and attention to detail as any consumer product, across every experience, interaction, and pixel. - Pillar 2 - 80:20 Jira functionality
Jira is a deeply complex and flexible product that enables teams of any size or structure to run agile development any way they like. With our focus of maintaining our foothold in Atlassian's product ecosystem, we aimed to enhance and complement the Jira experience, not replace it. This pillar is about enhancing the 20% of tasks that 80% of Jira users do day-to-day by making them more visual, efficient, and effective. - Pillar 3 - Mandatory multiplayer
One of our key business objectives was to increase overall breadth and frequency of Gliffy product use, so creating an inherently multiplayer / multi-user product drove every design decision. This is a product for cross-functional product development teams, not for teams of one. Its user base should grow organically, through core product use. Systems like notifications, live collaboration, organic invites, and 3rd-party integrations exist specifically to create value for cross-functional teams working together, as well as organic adoptionand growth.
Exploration And Validation
We began to dig in and think about how a new product might relieve some of the pain that product development teams feel around cross-functional communication, scattered documentation, and complex, text-based task management tools.
This meant lots of ideating, whiteboarding, sketching — and killing — ideas, working to deeply understand other products both inside and outside of our space, and building prototypes to test and understand where we’re on track and where we’re not.
Some pieces came easy, while others took countless rounds of exploration, iteration, and testing to get right.
Early ideation — going wide to explore lots of potential directions quickly and cheaply
Zeroing in on where the most potential may lie
Sharing and learning from other products in and outside of our market
Our idea evaluation wall — broad view of possible directions and tradeoffs
It was important to understand the benefits and deficiencies of potential directions with low cost to the team — the goal was speed and ROI
We spent as little effort as possible to make design ideas clear and tangible through rapid prototyping and visualization, and then evaluated strengths, weaknesses, and tradeoffs through strong feedback loops with customers and stakeholders.
Constant feedback loops highlight where our ideas fall short and where potential lies
The common design cycle of Build > Test > Iterate allowed us to evaluate lots of different directions relatively quickly, and weigh their pros and cons with both our internal team and external testers. Every conversation helped inform what made sense for users and what didn’t, and where the product’s real value lay for teams.
Low-fidelity prototypes helped validate product value and inform early, foundational design decisions like information architecture.
