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.

  1. Low: Managers who seldomly use the system except for when they need a report on costs
  2. Medium: Developers were the ones who need the access and request for clusters
  3. High: DevOps users who configure and support the system also have all the keys and grants the access
niko profile image

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.

hub-wireframes 1 image
hub-wireframes 2 image

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.

flow image
wireframes image

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.

balsamiq image

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.

prototypes-screens image
hub-screenshot image

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