The Walhall platform

Journey mapping process

What is Walhall?

I wrote a good article describing what Walhall is and how it could be of use, not only to developers but also to UX designers. You can also access other articles on Walhall from the Humanitec blog. But, to summarise, it is a platform that helps developers to speed up development time and simplify deployment process by promoting micro-service architecture.

There was a dedicated UX designer for the Walhall product so I played a support role handling user journey mapping and UX copy since I, too, had my own dedicated projects — TolaData and Kupfer. However, I was also involved in sketching team performance dashboard for early discussion.

The process

My UX process is based on Elements/Phases of UX by Jesse James Garrett. In Walhall product, I mainly focussed on the first three phases of strategy, scope and structure. The definition of a high level user journey with its sub-journeys was the ultimate deliverable. This process relied heavily on research, interviewing stakeholders and facilitating mapping workshops.

The main reason I proposed and facilitated the creating of the high level journey map was to get all stakeholders aligned on where we were coming from, where we were then and where we were going. Before that everyone had a different understanding of what was expected with business requirements changing frequently and only discussed with one or two top level managers before it became a dev ticket. This bred confusion in the team as everyone had their own understanding.

In addition, to get everyone in the company aligned on the journey mapping process and its benefits, I did a brown bag presentation. This was supported by material from the Nielsen Norman Group UX workshop I attended on Journey Mapping to Understand Customer Needs hosted by Kim Flaherty.

The workshop

Preparation phase:

I began by collecting all the research that had already been done on the product. This included all sales documents that provided information on business goals and target personas. We also had some high level user profiles defined both from our assessment of internal developers as assumptions across the industry. These needed to be detailed and validated since engineering teams had developers with different roles.

Since the product was already implemented, this research also included feedback from usability tests. However, because we had not secured any actual customers, the research from these tests was still very high level with few insights about the end to end process of development. We, also, tested with users for just one hour which was not representative of a real work day for a developer that could she light on the whole experience.

We already had other company products out in production (TolaData and Kupfer), so the company decided to migrate these products onto Walhall to make them our first real users of the platform. This took a long time since those teams had to refactor the code and break down the features into micro-services. But as soon as one of the products was able to fully use Walhall, we had a user base we could test with, and developers we could interview directly, albeit biased.

I compiled all this information and created a workshop planning document that referenced this information.

The workshop

The goal of the workshop was to generate journey maps for the purpose of

• highlighting internal stakeholders’ assumptions for external validation
• focussing discussions on user perspective rather than sales
• align the team on requirements and process

The workshop plan covered the following sections:

1. Listing and prioritisation of business goals. We rewrote the goals as SMART whenever they proved too vague. This meant that the business and sales leads input was required. One of the goals included to have a physical office presence in the US by end of 2019 to target US market base.
2. Listing and prioritisation of product goals. Aside from the business focussed goals, the product itself needed to have goals that the designer could prioritise to make it a success. An example included faster onboarding and conversion of users. The interface look and feel was deprioritised to allow for focus on end to end interaction.
3. Next, we defined the user goals. These were solely based on what the user expected from interacting with Walhall. We reviewed the personas we were targeting and for this high level journey we focussed on the developer whose goals included speed, flexibility and reusability in development and deployments. We identified the pain points as well based on previous research and our assumptions. These were prioritised based on how often the issue came up in discussions and testing.
4. The first two goals above constituted the business requirements. Using a prioritisation matrix, we arranged the user and business goals in order of priority. This enabled the designer to know where to start placing effort first as they designed the product. One of the identified top goals included educating users on the platform as quickly as possible to allow for higher conversion and activation rates in the US market. This meant focussing on a good onboarding process followed by providing features for the main end to end process from creating an app to production.
5. Armed with a good base to have discussions we proceeded to develop a high level lifetime journey whose various nodes would constitute scenarios for detailed sub-journey.

The journey map

We defined 5 phases — discover, get started, design, deploy and monitor which covered the end to end experience for any app development cycle that a developer would go through. Different types of developers would drill in on different phases depending on their function in the team. These types of different developers had been identified roughly but we had not really validated. So we made first assumptions that the developer can be an dev engineer or an operations manager. This would be validated when we put the tested the journey hypothesis.

For each of the phases, we defined the various touchpoints (and channels where relevant), what actions the user would be expected to take including the inputs required. Then, we linked the different touchpoints to show the user flow through the journey. This concluded our high level user journey.

As at the writing of this, this is where we were for the journey mapping. We produced a high level map which was placed under discussion with all stakeholder before we needed to pull out critical parts to detail further. The UI designer had produced two main storyboards before this journey mapping workshop for one of the nodes. These would be improved upon once we had everyone on board with an understanding of the end to end experience and not just a part of it.

Following this exercise, we already saw a marked improvement in everyone’s understanding of the whole process.

1. Developers could easily remark on areas where they felt they required more detailed user flows to reduce complexity.
2. Discussions were now based on specific phases and numbered touchpoints.
3. Conversation on flows used user active verbs and not business perspective or sales verbs.
4. Keeping a record of changes in requirements and user validations became easier and less confusing once one knew referenced the numbered node.
5. Onboarding new staff onto the process was now so much faster saving time and resources in getting new staff up and productive.

We had a long way to making this a robust process, but it was now expected a as part of Humanitec’s UX process. Soon it should be ingrained in the team minds.