Schematics Blueprints
Process Book
—
Tucker Hemphill
Designer @ IBM
Table of Contents
2
Setting the stage�- What is Schematics?
- What is Terraform?
Identifying the problem
- Architecture conversations
- Initial Research
- Target Users/Personas
- Hills/Client Value Statements
Identifying business need
- Business Conflict Resolution
The Solution
- What are Schematics Blueprints?
- Core benefits of Blueprints
- Design/Research Iteration
User Validation Research/Design Refinements�- Prototype Validation Research/ Design Response�- Measurable Outcomes
Closing
- Questions, remarks.
Setting the stage…
Part 1
What is
Schematics?
4
Think of Schematics as your one-stop-shop for provisioning IBM Cloud resources.
Users can write a script in the form of a Terraform file to provision large amounts of resources.
For instance, instead of manually setting up 67 various resources individually on IBM Cloud, you can use Terraform via Schematics to provision those 67 resources with a click of a button.
What is
Terraform?
5
Imagine you walk up to your refrigerator... All you want is a basic, Italian Sub. Easy, right?? You open the fridge doors, add everything you want to your sub, and you move on with your day.
Now, let's say you have 75 subs to make! All of the subs have slightly different orders. You write down all 75 sub requests on a sheet of paper so you know what ingredients you'll need to buy, and how the subs will be made.
Terraform operates like the list of subs, personal shopper, and sub assembler — so instead of having to go off to grocery shop, assemble the subs, and deliver them yourself — you have this handy friend that does it for you! That friend is called Terraform!
With Terraform, you'll write your code file — defining the hundreds of cloud resources such as Kubernetes Clusters, VM's, etc you may want (ingredients) you'll need to create the end solution (sub recipe) and ultimately deploy to the cloud (Doordash delivery).
BOOM! You just had a crash course on Terraform! There's a TON more we could dive into, but none of that's necessary for the sake of you checking out my portfolio right now :)
Identifying the business need…
Part 2
Collaborating with the IBM Architects.
7
To kick off the process of identifying the problem space, I had to lean on the Architects on our team to better understand how the technology works and identify the technological gap on the IBM Cloud Platform we were trying to solve for....
This led me to several key findings:
1.
Creating monolithic, declarative Terraform files have a maximum file capacity of 4MB. Once the files start to get large, it can slow down the provisioning/update process.
2.
When updating or destroying resources, it can leave users accidentally re-provisioning resources that their infrastructure is dependent on - resulting in downtime and potential errors.
3.
There’s currently no way for users to manage and re-deploy architecture models that exceed one Terraform File. Making lifecycle operations and management extremely volatile.
Benchmark User Interview Study Context
PARTICIPANTS
5
Types of questions we asked:
��
�
Concept testing interviews: August, 2022. (n=5)
��
�
Key Findings:
��
�
Operations Team
9
RJ is in charge of an operations team that manages the stability and integrity of his infrastructure. In addition, his job role is to make sure they’re working efficiently while not wasting personnel hours. He has a lot on his plate, so ease of use/low barrier of entry is essential to him choosing the right cloud provider.
Goals and motivations
Responsibilities
Painpoints
RJ's main motivator is to provision infrastructure for his employer as fast as possible to meet their needs. He also wants his team to envision more ways they can reuse their code for solutions to automate their companies workflows.
1. Currently, he's manually provisioning each Terraform file separately and can’t believe there isn’t a better way to deploy them.
- Designs new solutions for the company
- Ensures Efficiency in the infrastructure
- Designs new solutions for the company.
2. He doesn’t have a way to easily view the architecture of how the terraform files are knitted together. He wants to view the relationship to make them replicable
Hill/CVS 1 — Operations Team
10
An Operations Team
can view, monitor, and reuse multiple code files
All within the same pane of glass at a quick glance.
Who
What
Wow
Solutions Architect
11
Goals and motivations
Painpoints
Michelle's goals are to ensure stability and maximize performance. Drive adoption of standards within her own team.
Michelle is a solutions architect who solves complicated problems around performance, scaling and security. She is responsible for maintaining the network and infrastructure.
She strives to increase efficiency when possible by automating tasks and processes.
Responsibilities
- Managing, building and maintaining infrastructure
- Automating processes to increase efficiency
- Testing and monitoring
- Act as both engineer and advocate of software solutions
1. Michelle doesn’t have much time on her hands, which means her process of manually provisioning TF via the CLI locally is too time consuming, and makes her nervous about maintaining state.
2. Currently, Michelle isn’t able to easily discover job failures and diagnose the problems because she needs to manually go through each Terraform file via the CLI.
Hill/CVS 2 — Solutions Architect
12
A solutions architect, familiar with Terraform
Who
What
Wow
can download, deploy, and manage their TF using both the UI and the CLI
while utilizing consistent commands, syntax, and error handling.
13
Conflicting Business Products/Business Need
Throughout the process of ideation, I ran into a challenge where another offering currently being developed on the IBM Cloud platform that was being designed to do a similar function.
I regularly had meetings with the architects, developers, PM’s, designers, etc. to help create artifacts, positioning documents, and create an identity for each offering that was distinct from the other — So when users come to our cloud, they know instantly exactly which product they need and why.
14
Initial Research - Competitive Analysis
After I identified the broader why for the project, I led us in a competitive analysis to make sure we weren’t reinventing something that already existed for these particular use-cases…
Findings:
AWS CLOUD FORMATION
STACKSETS
AZURE BLUEPRINTS
AZURE TEMPLATE SPECS
CLOUD DEVELOPMENT KIT
GCP TERRAFORM
PULIMI
TERRAGRUNT
The solution…
Part 3
What are
Schematics Blueprints?
16
Schematics Blueprints help DevOps teams deploy and build large-scale and repeatable application environments, by building on existing and proven Schematics automation concepts.
Blueprints allows the user to gain access to reusable automation building blocks for their complex environments.
17
Module 1
VPC Terraform File
Module 2
Cluster Terraform File
Module 3
Accounts Terraform File
Basic Architecture of a Blueprint
A Blueprint is essentially a wrapper that specifies and holds the modules (individual TF Files) being utilized and defines their relationship for data passing between them.
This wrapper allows for monoliths to be split up so users can reduce bulky files (increasing speed), split up the TF files (reducing error), and make it easy for users to reuse their code patterns.
BLUEPRINT
Customer Benefits of Blueprints with Schematics
18
Faster time to production
Create and deploy solutions and cloud resources faster using reusable automation components.
More efficient infrastructure deployment and management
Accelerate every phase of infrastructure provisioning and lifecycle management of your infrastructure resources from creation to solution retirement.
Improved Consistency
Eliminate the risk of mismatched environments for development, test, and deployment by using components and solution patterns across environments.
Increased ROI
Free your team from developing infrastructure content by leveraging existing hardened and compliant infrastructure automation modules so you can deploy solution environments quickly.
Two interfaces to design for
19
CLI
The role of the UI is intended as a simplified user interface that allows you to manage the health of blueprint environments, resolve/diagnose deployment failures, and mitigate issues.
UI
The CLI (Command-Line-Interface) is a more traditional way that users can interact with Schematics. For some users, they are more comfortable with this approach as it can be deemed to have clearer Information Architecture than the UI at times.
Overall Navigation
20
Next Steps Interaction
A Blueprint involves two steps.
1. The creation flow, that creates an environment for the blueprint to live within, defines its parameters, etc.
2. A plan/apply step, which deploys the modules that are deployed…
Via research (more later), we found that when users hit “create”, they expected their entire Blueprint to spin up. Architecturally, this wouldn’t make sense from the backend. Because of this, I designed a “next steps” interaction to provide context to the state the Blueprint is in.
High-level context
We found through initial testing that users needed quick insight into the state of their blueprint, what geography it was created for, and their module/resource/variable status.
Quick-view Job Runs
Jobs are a HUGE aspect of understanding the state of your blueprint. By adding “recent job runs” to the homepage, we increased the speed of users understanding when the task was run, and insight as to whether the job run was successful or failed.
Modules View
21
Module Overview
Modules hold the resources inside your blueprint. Typically, users would create modules to serve different purposes, hold different resources, etc. By showing them a high-level overview at a glance, we enabled users to understand the health of their resources, and decrease the time it took them to locate the TF files.
Resources overview
22
Resources by Module treatment
Looking one level deeper, users were now able to sort their resources based on the module. This furthers the use-case that they would nest their resources based on resource need, type, etc.
Resource Filtering
Once the user selects a module to filter by, we enabled them to have filters they would find helpful, such as sorting by resource type, resource group, and searching for any tags they may have created.
Variables
23
Inputs/Outputs Interaction
In a blueprint, there are two types of variables — inputs and outputs. Both serve drastically different functions, and if you were to mismatch them, it could be fatal to the blueprint. Because of this, we decided to design a toggle that visually separated and reduced error that users might face.
Source Overview
Arguably the most important part of this screen is understanding the source file they’re working with. Without that context, a user wouldn’t know what Git repo to upload their new code to. This helps them rest assured that their editing the proper file and their changes will be pushed to the Blueprint.
Editable Overrides
When a user writes their Terraform file, they can add space for required and pre-filled variables. We designed this aspect of the screen to parse the fields from their file, and if they choose to edit, it would fill those variables into the TF file behind the scenes so the user wouldn’t have to do it themselves.
Jobs History
24
Create, Modify, Destroy Interaction
In Terraform, there are three possible commands it can execute; it can create a resource, modify a resource, or destroy a resource.
We found through research that it would greatly decrease the time they spent sifting through prior jobs if we surfaced how many resources were affected within each module.
Job Logs
Job logs are the way TF users diagnose issues, understand the order of operations, and gain context as to what Terraform is doing. We decided to surface the logs at the module level because it would reduce context-switching behind which module is calling each response if we had one large log file.
Cost Estimate
On IBM Cloud, you can deploy pretty much anything in Terraform. This means, you can cost your company tens of thousands of dollars if you make a mistake. Prior to this, we didn’t have an API with our other products to call cost, but with our new API, we were able to incorporate a cost estimate into every plan and apply action.
Public Beta Validation Research
Part 4
Design + Research Collaboration
User Research Context
PARTICIPANTS
9
LIVE BETA USABILITY BENCHMARK
Main Recruitment criteria
�
Jobs to be done
��
�
�
�
Live beta Usability Benchmark: September, 2022 (n=9)
��
�
Live beta Usability Benchmark
CLI
Documentation
Blueprints UI
Blueprint user tasks via the CLI:
Blueprint user tasks via the UI:
Key task results
28
28
n = 5
28
28
PERCEIVED EASE OF USE
Comparing expected ease of use to actual ease of use
Task was difficult
Expected to be difficult
Expected to be easy
As easy as expected
Easier than expected
More difficult than expected
Significantly more difficult than expected
Significantly easier than expected
Task was easy
Pre-task How easy or difficult would you expect Task X to be on a scale of 1–7?
Post-task How easy or difficult was Task X for you on a scale of 1–7?
Most of the tasks were rated in the positive highest scale of 6-7.
Creating and Installing the Blueprint was as easy as expected for participants.�Destroying and deleting the Blueprint was more difficult than expected. �Discoverability was one key factor in the ‘Destroy the Blueprint’ task. A number of key findings signifies the slightlylower rating of ‘Creating a Blueprint’ compared to the other tasks.
Critical Issue #1
No Creation in the UI
Before: Previously, the creation was only available in the CLI, making the barrier of entry high for new users unfamiliar with the CLI… You also had to provision two separate terraform files, this has now been eliminated in the UI.
After: The UI now features a creation flow that will guide users through setting up a blueprint. It will also help them understand how a blueprint is constructed, and allow them to add/edit the variables easily.
Critical Issue #2
Unclear that creating a blueprint doesn’t create resources automatically
Before: Nothing displayed in the docs or UI that obviously shows the two stages of creating a blueprint.
After:We designed a solution utilizing the progress Indicator component to help the user develop a mental model of how a Blueprint is set up… This helps provide context to what they’ve done, and what they have yet to do…
Plan/Preview (Issue 2 Cont.)
31
Resource preview by action
Traditional Terraform would call the job, process it, and only display if it passed or failed. This provided limited insight to the users about what resources were being spun up, modified, or destroyed until after the apply command. Because of this, we created a dropdown interaction so users can see the individual resources.
Quick-view Module logs
While each module is being processed, we enabled the users to dissect the logs inside each module so they could follow along with the syntax of the commands in real-time.
Critical Issue #3
Users are unable to edit variables in the UI, no flexibility in editing…
Before: Users weren’t allowed any autonomy when visiting the UI… It was solely in a read-only state, which is very limiting.
After:The UI now features the ability to edit variables, basic settings, pull your latest blueprint repo, etc. It now has A LOT more autonomy.
Critical Issue #4
Users can’t be taken to the resources directly when clicking on each resource
Before: Users weren’t provided with an easy way to navigate from blueprints to the resource they wanted to see in the console.
After: Now, where there’s a linkable resource, Blueprints has the functionality to take you to the resource/offering
Critical Issue #5
CLI & UI Terminology doesn’t align, which leads to mental-model confusion.
Before: Some of the old CLI language was unclear in relation to the perceived outcome of it in the UI.
After: We first designed the UI, then ideated on commands that we could phrase differently to convey the proper perceived interaction.
+ 57.69%
+ 259.6%
44.65%
Measurable Outcomes
Increase in total resources provisioned
Sample:
292,345 Avg/Month Before Blueprints,
461,022 Avg/Month After Blueprints
Increase in unique users creating resources
Sample:
1,812 Avg/Month Before Blueprints,
6,916 Avg/Month After Blueprints
Decrease in total workspaces provisioned
** This suggests that the introduction of Blueprints enhanced the usability and clarified the mental model of Schematics architecture. This was seen by users decreasing their number of workspaces, while seeing massive growth in actual resource provisions. **
36
Observe
Chat with users, get colleague feedback, etc.
Make
Get into Figma, sketch on paper, etc!
Reflect
Aggregate Insights, curate feedback, etc.
Thank you.
37
If you’re interested in seeing more process, please feel free to reach out, and we can discuss via a call.
Tucker Hemphill
Designer @ IBM
tuckerhemphilldesigner@gmail.com
(202) 579-7811