Aytra

Solution

A cloud orchestration platform that would allow organizations to adopt a hybrid model, which would allow them to use a mix of on-prem and cloud, thereby minimising the risk and allowing them to test and transition. It would even allow them to mix and match cloud providers to maximise cost savings.

The platform also has a solution for connectivity, which allows the organization to do the migration and from then on, connect to their cloud resources securely and with minimal performance issues. This would ordinarily be another product, another variable, another company to chase up when things go wrong, but in our platform it is integrated and seamless.

On the business side, there is also visibility on spending and controls to prevent overage for peace of mind.

Challenges

• When I arrived at the company, they were already in the solution space. There was a whole whiteboard-wall (pictured, blurred for confidentiality) that was filled with very detailed technical specifications but were not easily understood by outsiders
• Changing requirements
• Steep learning curve - not only is it a lot to learn conceptually, but each cloud provider also has a different way of implementing the same things/different terminology
• Difficult to recruit research participants
• The organization plays the role of all user groups (both the provider and consumer sides), adding an extra challenge when parsing their responses to questions

Strategies

Ideally, I would have wanted to validate assumptions with primary research before building the solution, but I was constrained and in this case, I had access to internal subject matter experts (SMEs) and a wealth of secondary research online, which, given the standardised and highly documented nature of the problem space, still gave me what I needed.

Learn

I needed to get up to speed, so I did as much research as I was able to do with the resources I had.

• Desk research – reading a lot about the subject matter to get up to speed. Again, because it is a product people use for work, there is a wealth of secondary research available online (white papers, tutorials, blogs about people's experiences, technical documentation, etc.)
• Using internal SMEs - Usually I would worry that this would introduce some bias in the results but in this particular case, the risk wasn't as big. The tasks and best practices are somewhat standard, and even if the way our organization does things is different to the industry at large, we had the option to use the tool for ourselves (which is what other MSPs such as Dimension Data and VMFarms already do) with the possibility of iterating pending broader research.
• Guerilla Research/Intercept Studies - Going to events (e.g. Tech TO) to people working in the roles we are targeting, as well as using people I knew/serendipitously met
• Competitor analysis – seeing how they communicate their value proposition and where we are in relation

Communicate

My first attempt at a workshop to elicit existing internal knowledge about users was difficult. The questions I was asking were very high level and centred around the human element, rather than the actual nuts and bolts of the tasks. While I thought this was very important, they perceived it to be extraneous. In light of this, I changed my communication style to meet them where they were.

• Using the HCD artefacts for design but communicating them in a way that fit with their mental model (e.g. task flows and diagrams), particularly early on
• Asking why and reframing explanations
• Taking the granular detail from the wall and taking it high level

Over time, the need to reframe got less and less as the team got familiarised with the approach and conversations naturally became more high level.

Co-Create

Being co-located with the infrastructure team allowed me to continually observe/learn about the domain (without the Observer Effect) and gave me a drip-feed of intelligence that I could use throughout the design procecss, rather than just at the beginning. It also gave me the ability to form a tight feedback loop where I could verify my designs quickly.

I also found that people had ideas for what would make their jobs easier, but they would get very deep into the details of the solution, which is what they would bring to me. To help articulate the user goal, I developed a questionnaire that worked backwards from their idea, and from the resulting user goal, we did divergent thinking.

Technical Review

Another important aspect of working with the technical team was communication with the developers during the prototyping process. This allowed them to see what the impact would be on the backend. To that end, I regularly showed the developers my designs in case they needed to prepare anything early on or in case we needed to make any compromises regarding feasibility and/or priority.