Iceberg is a startup company that seeks to revolutionise the way technology is communicated through system architecture diagrams. An architecture diagram is a visual device used to communicate design, deployment, and topology of a network in the tech sector. Iceberg’s starting MVP is a tool to create animated architecture diagrams with code. Iceberg wants to commercialise their product and have come to us to validate their product idea.
What is an architecture diagram?
An architecture diagram is a layered representation of a system that is used as a summary of the relationships between components of a network. It is an important document for tech companies that demonstrates an overall view of the physical deployment of a system and how it evolves over time.
It is a tool to teach new and existing team members about a system’s architecture, to communicate the complexity of adding or changing features to stakeholders and troubleshooting when things break.
What Iceberg wants from us
We were presented with an already established MVP, creating and embedding an animated architecture diagram with code. We were asked to validate through research whether there was product-market fit and if this was a product that tech people would want to use. Some questions we were asked to validate included:
- Who would use this product?
- Why would they use ours and not competitors?
- What is the killer feature?
- Would people be willing to pay for it?
Business metrics for success
We were also given various business metrics to evaluate the success of the project at launch.
- Do people want to use a tool like this?
- Do people feel safe to embed a player in their documentation?
- Will people prefer to use another tool?
Practices: User Research, UX & UI Design, Prototyping
My Roles: Survey, Design Research, Design System, High-Fidelty Prototype
Contributed To: User Interviews, Synthesis, Problem Statement, Persona, Ideation, MVP, Usability Testing, Mid-Fidelity Prototype
Teammates: Brandon Reynolds, Eastina Zhang, Olivia Mckay
Discover, define, develop, deliver
We conducted user research and synthesised our results to develop a tool that addresses the problems of how best to create architecture diagrams and present the numerous layers to different stakeholders. We designed a mid-fidelity prototype, tested it on users and received valuable feedback for iteration on the high-fidelity prototype. We then designed a landing page to advocate the benefits of using the software as well as to gather contact information from interested parties. The next steps will be usability testing on the high-fidelity prototype and iterating the design. Read more about how we got here below.
Market research was vital for success
We knew from the outset that market research would be vital to the success of the project. We needed to discover as much as possible about our competition and use this to position ourselves in the market. We wanted to know what features they used, what their pricing structure was like and who their target audience was. We discovered that:
- There are a lot of products out there broken down into two categories; graphical drawing tools and automated API tools
- Pricing structure was organised into basic, premium and business tiers and ranged from $1 to $99 per user per month
- Free and open-source options appealed to smaller companies while larger tech companies used paid tools
This portion of the research took longer than expected because of the saturation of tools in the market. We were also learning about architecture diagrams at the same time so had to brush up on our technical knowledge. It felt overwhelming at first but was ultimately worth the effort to understand whether we could achieve product-market fit.
Who are we competing against?
We conducted a plus and delta analysis of the leading competitors in the market. We wanted to know why these tools were popular and what types of companies were using them.
We discovered that Visio is used widely by enterprises, whereas tools like Gliffy are used by smaller businesses. We found that Draw.io was used across the board in both small business and large corporations but generally in companies with no formal policy on which drawing tools to use. This breakdown was due to the popularity and individual pricing structures of each of the programs.
What are the users saying?
After speaking with our client about the competitive landscape, our focus shifted away from traditional drawing tools which produce flat and static diagrams to more modern tools with interactive outputs. This was due to the fact that the client believed their competitive advantage was in a non-static representation. We looked at forums and online discussions for what users were saying and found three tools that stood out. They produce attractive looking diagrams but can be expensive to implement.
While these tools produce beautiful images and generate live metrics, they can only be used with cloud-based networks. Companies who employ physical networks have to opt for manual drawing tools to map out their architecture. So while it was exciting to discover these options due to their ease of use and attractive results, our tool needed to appeal to an audience that sits somewhere between traditional drawing tools and automated ones.
Other tools that do great work of dynamic presentation
We then conducted comparative research into tools that were doing interesting things in the way of collaboration and presentation. The purpose of this research was to uncover any gaps in the market that our competitors might be missing out on. We went through the following apps to discover what’s working, what isn’t and what could be done better.
We discovered that interactive presentations are a drawcard for users and keep audiences engaged for longer. We also found that collaborative tools are good for productive feedback between team members and stakeholders.
What can we discover from users?
We mapped our assumptions and used them to create a topic map for user interview questions. Some of our assumptions included:
- Not all architects are able to code
- Architects need to collaborate on documents
- Animation is more appealing to stakeholders
We needed to recruit people for interviews who have experience working with architecture diagrams, specifically those professions outlined as archetypes by the client. These included DevOps, Product Person, Developer, UX Designer, Architect and Business Analyst. We searched for recruits through our own personal networks, LinkedIn and our client’s contacts in the industry. We found it difficult to recruit users for interviews as we were working with such a specialised topic. The majority of our interviews came from personal contacts in the industry as well as people they could put us in touch with. Those we did interview were happy to speak to us as architecture diagrams made up an important part of their job activity.
Thought-provoking insights from the survey
We sent out a survey to industry-related groups and forums to try and reach a wider range of participants and gather more quantitative data. The purpose of the survey was to validate the assumption that architects would want a diagramming tool created by code that resulted in animation. We also wanted to discover other preferences in diagramming tools if this was not the case. We collected all the responses and discovered who the most typical user was by identifying key patterns in behaviour. A typical user is:
- An architect who uses diagrams every few days
- They use Draw.io because it’s easy and free
- They prefer a manual drawing tool over coding
- They prefer interactive over static or animated diagrams
- They would not pay for diagramming software
These results weren’t looking good for a diagram created with code and output to animation but it was still too early to make any definitive judgements. For that, we had to turn to our user interviews to really deep dive into what users wanted out of diagramming software.
Inspiring insights from our users
We conducted our interviews remotely with people from all over the world. We then affinity mapped the results so that we could organise our insights into patterns and themes. Here are a few of the emergent trends.
- The tools people liked had simple, easy to use interfaces
- Collaboration was key to creating diagrams
- Diagrams were also used for discussion and presentation
- Not all architects who create diagrams can code
- Given the option, users would prefer interactive over animated output
Again the research was telling us that users preferred a manual drawing tool with an interactive output rather than a coding system with animated output. We needed to pivot away from the original MVP and focus on what the users really wanted. We were tentative and nervous with these results as they contradicted the clients original MVP and we weren’t sure if he’d agree with the findings. We were confident in our research however so continued along this path knowing full well that our final product would be a deviation from the original idea.
Meet Jeff, he’s a Senior Tech Lead
Jeff uses architecture diagrams to facilitate technical discussions with his team and to help make design decisions. Some other people in the office use Visio to create their diagrams but it’s bloated and has too many functions he doesn’t use. He is looking for a way to demonstrate the layering of diagrams to stakeholders in an appealing way.
Defining the problem
We wanted to align the team and focus on the core problem so we formulated a problem statement by identifying what our users needed and why.
Jeff needs a better way to communicate architecture diagrams so that he can collaborate with his team effectively.
We focused on communication and collaboration as the main pillars of our problem statement. These insights came up numerous times in our user interviews and we identified them as the most important aspects of the problem moving forward.
How might we help Jeff?
We wanted to reframe our problem statement into How Might We questions to turn those challenges into opportunities for design. Some examples include:
- How might we facilitate collaboration and recreate the energy of a whiteboard session?
- How might we show links and layers to further communicate infrastructure and flow?
- How might we create an integrated tool that optimises workflow?
Over 50 ideas were generated
We ran a design studio to help us figure out what our killer features would be. Then we ran a feature prioritisation workshop to rank our ideas taking into consideration the level of value and the level of effort involved in actioning these ideas. We consulted one of our interviewees as questions on implementation were out of our depth. These were the main features that emerged.
- Animation was valuable for impressing clients but not a feature architects would often use
- Interactive diagrams were more desirable and could effectively show users the layers of a diagram
- The key aspects to making the diagrams interactive was zooming and expandable layers
- Real-time collaboration with other users was vital
- The ability to easily see who is working on a document and what they’re working on
- Comment and direct messaging functionality was important
- Cloud-based access from anywhere
- Auto-saving a document
- Version control history
Not reinventing the wheel
Now that we had our main features we needed to focus on the user interface. Users needed an interface that was intuitive and easy to use as we found these were priorities during research. During our competitive analysis, we discovered that most diagramming software followed similar conventions in their functional layout. Users reported that they liked using certain software because the form and function was familiar and easy to use. We wanted to carry these same ideas in to our design. This meant keeping the core global navigation at the top of the screen and the drawing tools in the left toolbar.
Focusing on the features that would bring value
We created a paper prototype and made it interactive using Figma. We recruited six users from our interview phase to participate in usability testing and asked them a few fundamental questions.
- Are the tools in the right place?
- Is it an intuitive interface?
- What would you expect to happen next?
Users reported back and we gained valuable insight into changes we should make to the interface.
- They expected an undo button
- They wanted the maximum working space possible
- They expected the share button to provide a URL link
Turning the paper prototype digital
We then designed a mid-fidelity prototype using the feedback gained during usability testing. We created three flows for features that we discovered were important to users.
- Presenting your work to clients or stakeholders
- Commenting functionality to facilitate collaboration
- Autosaving changes to the cloud
Adding beautiful images and colour
We moved onto the high-fidelity prototype to test how colour and imagery affected functionality and if our users would respond well to the UI concept. We also opted for a dark mode inspired interface as users reported liking dark mode over traditional interfaces. We included the option of a light mode as well for the remaining users. We also simplified the interface and added a dashboard welcoming screen as users told us they expected one.
The design addresses the key components that users were asking for during the research phase. It has a simple and intuitive interface with with no hidden or hard to find features and contains the most fundamental tools only, which cuts down on user fatigue.
- It produces an interactive diagram with an easy to find button housed in the main navigation bar
- It contains a sharing feature to exchange your diagram with co-workers
- It allows for real-time collaboration and shows who else is working on the document
- It features commenting and direct messaging functionality to facilitate collaboration
- The document auto-saves into the cloud and is accessible from any machine
- It contains version control history in case you want to navigate to a previous version.
How would users find out about us?
As a new player in the market, we are unknown in the field of architecture diagramming software. We needed a way to make users aware of our presence and to demonstrate why we’re the best solution for their diagramming needs. We built a landing page where users could watch a tutorial video, find out about the company, read up on features included in the software and sign up to a mailing list to receive more information before the launch.
What did the client think?
Our original objective was to validate our clients MVP for an architecture diagramming tool that was created by code and output to animation. In speaking to users we discovered that they preferred a traditional drawing tool with an interactive presentation. The client also wanted to know whether people would pay for the tool. We discovered that individuals and smaller organisations would opt to use free or open-source options but larger organisations had a budget for the product. Systems Architects would be the ones to make use of the tool the most but stakeholders would also use it for presentations. The unique selling point is in the interactive output which demonstrates the complex layering of a diagram where users can zoom in and out of layers while presenting their diagrams to clients or stakeholders. We met the objectives outlined at the beginning of the project and discovered what users really wanted in an architecture diagramming tool as well as revealed who the target audience would be.
We presented our research and findings to the client which were well received. The client was impressed by the amount of research that went into validating the final product and happy we uncovered what users really wanted. He was understandably disappointed that his original MVP didn’t go over well with users but was glad to take on board our recommendations for changes to the concept.
Iteration, iteration, iteration
The next steps would be usability testing on the high-fidelity prototype to determine how users respond to a fully coloured and imagery built interface. Taking that feedback and iterating on the design to produce something that meets both user needs and business goals. Next steps also include evaluating business metrics through usability testing with the high-fidelity prototype and answering questions like do people want to use a tool like this and do people feel safe to embed the diagram into their documentation?
What did I learn from this process?
- How to familiarise yourself with a topic you know nothing about before embarking on a project.
- When unsure, come back to the research and follow the process
- The importance of clear communication between the client, stakeholders and the design team
- How to work efficiently and effectively in a remote team
What would I do differently?
- Validating features in the high-fidelity prototype with usability testing before designing the landing page
- More meetings with the client to facilitate discussion about our progress
- Given the chance, spend more time in the research phase to further evaluate the original MVP