The Challenge
Appvia were trying to solve costs, resource and management challenges that their clients faced with their current development and operations (DevOps) infrastructure.
The solution
Create a cloud base platform that manages Kubernetes clusters, resources and teams.
The process
Research
- Competitor analysis
- User analysis
- Interviews
- Retrospective
Define
- Personas
- Features and backlog
- Userflows and journeys
Design
- low, mid and high fidelity prototypes
Test
- Usability tests
- Affinitiy maps
- Iterate and re-test
Research
Method
Discoveries
Competitor analysis
- There are many companies offering similar cloud based products that try an solve the same issue.
- The best competitors from that list include Heroku, Openshift and Firebase.
- Most offer a tiered self serve model whereas Appvia’s model is to open source and be the support service.
User analysis
- Different end users want different things for example the majority of developers don’t really care about the DevOps side of things they just want to be able deploy their code as easy as possible
- Management want a holistic view of projects and costs
- DevOps and support want all the mundane tasks like access requests to be reduced.
Retrospective
After talking to end users I discovered the main pain points with the current system were:
- Overloaded support tickets
- Costs were too high due to teams using up too much clusters and pods
- Hard to keep track of people in teams
- Onboarding process was convoluted
- Documentation was not being updated
Define
Personas
From talking to all the end users, I noticed that there were 3 types of users. Low, Medium and High end.
- Low: Managers who seldomly use the system except for when they need a report on costs
- Medium: Developers were the ones who need the access and request for clusters
- High: DevOps users who configure and support the system also have all the keys and grants the access

Feature list and backlog
With the information gathered from surveys, personas and interviews there were definite problems and pain points that could turn into user stories and features that form the back log for example:
- Self serving journey for onboarding new users this would streamline the process and greatly reduce support tickets
- High level dashboard/view for managers to view cost related data this would also reduce ticket to devops to extract data
- Team approval system for cluster creations and upgrading pods this would reduce the amount of resources being used that incur cost
Userflows and Journeys
Now that we’ve defined some features we can then start to map out some ideas of how these user flows could work.


Design
Prototype, test, iterate, repeat
low fidelity sketches
I started sketching some ideas on paper of possible layouts and interactions. This helps to form direction and more ideas quickly before committing to more time consuming wireframes.


Mid-fidelity prototypes
I used Balsamiq to create my mid-fidelity prototypes. I feel that by keeping out the visual design element at this stage really helps focus on the journeys rather than what colours and copy should be used.

Hi-fidelity prototypes
For all my hi-fidelity prototypes I code up the journeys using React and Ant Design/Bootstrap default templates to quickly represent the flows and interactions. It's important that these journeys are as real as possible so that outcomes of user testing can be more accurate.


Test
Method
Discoveries
Usability testing
- Devs wanted the complexity abstracted away from them so they can focus on developing
- The processes for integrating third party services can be long winded having to do many steps beforehand
- DevOps were concerned that they wouldn’t be needed anymore but like that fact that they will be the heroes
- Initial set up was easier and clearer
- Single sign-on via github is a great idea allowing onboarding super quick
- Liked the idea of a wizard/tour and ability to recover and dismiss when needed
- Adding new team members was easy
- Automation and detection is great but would also like configurable options when necessary
- Showing costs when creating new clusters was good feature
- Some people preferred the word “projects” or “apps” instead of “spaces”
Next steps ..
- Align visually with the new brand
- Alpha to be built
- More features
- Open source
- Test, iterate, rinse repeat ..
What I learned
Reflecting on this project I learned a few things:
- It’s ok to fail, the early the better
- Don’t get too hung up on what to name things sometimes you just have to go with something
- Keep it simple as much as possible
- Working on a project with many unknowns and direction changes can be quite challenging
- Be prepared to throw away, stop and start again