As part of UX service offering, SAP held an on-site workshop with OpenText to go through the entire development lifecycle within one week: from multiple, iterative steps in design to development & deployment of a Fiori app. With this blog I would like to share both, the structure and content of this workshop offering as well as a role model mindset and behaviour of OpenText as the partner which made this particular workshop very successful.
Day 1 – Persona, pain points, ideate and story board
We kicked off the workshop with an overview of what Fiori is (concept, design & technology) as well as SAP’s UX strategy to create a common knowledge level within a diverse group as a basis to build upon. With 17 participants of very diverse background (UX designers, product managers, developers) and different knowledge levels reaching from experts to people who get in contact with the Fiori UX for the first time every participant was enabled to be ready for the workshop to start.
Before the actual hands on part of the workshop started, the basic design process was explained in order to set the stage and expectations for the first and second day.
Within these 2 days, the goal was to get through the full process of designing (see discover and design stages below) Fiori apps for personas who need to solve one specific business task in their job.
After teaching and discussing the first 6 steps of the design process, it was time to roll up the sleeves: 3 groups were created where each group started with the first step to define the actual scope of the business task each group wanted to tackle. Supported by a design coach, the first step was to create a persona. With a persona it is easy to keep focus on the business problem by also creating empathy for the user during the design process.
Each group then presented their persona within the workshop to share and openly discuss their results and experience of the group work.
To prepare the next round of hands on work again the theoretical background was presented and discussed about the concept for the next step, the “current user experience journey” which is a mechanism to identify the today’s process steps, system interactions and the users’ reaction and experience on each of the steps.
After getting back together in groups the groups had 1 hour to finalise this exercise which increased the coverage of the walls in the large workshop room.With the analysis of the status quo and ground work done, the groups now were ready to move to the next level: Improving the experience! In the first step, the groups generated ideas with the most possible diverse and therefore comprehensive output. In order to achieve these brainstorming goals, a few basic rules were provided:
With many ideas generated, the next challenge was to narrow the scope. The groups did achieve this by clustering the ideas. A final round of voting helped to prioritise the different clusters in addition.
Following this exercise, the day was already well advanced; however, before wrapping up the first day, the groups came together one last time to connect the ideas with the persona and the persona’s business issue. The groups accomplished this by creating a user story. In this user story a typical scenario out of the persona’s normal business day was drawn on paper / i.e. large post its. In this way it was possible to distribute the single steps, draw a story and put it up on a wall. The final user story was created quickly and ready to be easily told to others in a comprehensive way.
With the creation of the user story we wrapped up the day with a feedback round. The feedback was very positive to bring together people with different expertise like UX, product management and development to identify a persona, the persona’s daily challenges and design the user story which will make the persona’s life simpler and better. The process was perceived to be both efficient and provide valuable results.
Day 2 – creation of low and high fidelity prototype
After rejuvenating overnight, we kicked of the second day with each group to present their user story. The presentation was interactive because questions were raised to understand or refine the user story. This in turn helped the presenting group to sharpen the user story based on the feedback and do another iteration to refine the design. This was the base for the next step: The creation of a low fidelity prototype. The low fidelity prototype is the next step of the iteration to become more precise and evolve the user story to the actual application which can make the persona’s life simpler. With this iteration the cost is still low as the low fidelity prototype is realised with post its of various sizes. They are used to construct an application which meets the persona expectations by flexibly sticking them to the wall. In group work and discussion it is still very easy to discuss, rearrange or discard proposals which in turn encourages everyone involved to contribute with better ideas or additional thoughts. This effect is not equivalent when investing into pixel perfect design where changes are expensive and therefore more difficult to achieve. The photo below illustrates how a low fidelity prototype can look like, you can tell that it is easy to redo single cards & post its which the group actually did as new ideas came up once it was possible to relate to an actual application with a first look and feel.
In between these intense sessions we also enjoyed formidable coffee at OpenText during breaks, a big compliment – the coffee was as good as it gets!
The final step of the design phase left to be mastered was the creation of a high fidelity prototype. The goal at the end of this 90 minute session was for the groups to present their final design of the Fiori app where other participants would now be asked to in detail challenge the design before it is taken over by development to realise the application. Firstly the participants got an introduction and a quick tour over SAP’s design stencils, a set of UI images as part of a Fiori stencil template which can be used to compile complete Fiori app mockups. Secondly the groups got familiar with the stencils and started their work. Groups divided the entire scope form the low fidelity prototype into sub screens and assigned them to group members. Each person used available stencils from the template to create screens which exactly look like a real Fiori app screens. With each group member finishing their part, the overall design was put together piece by piece until the final presentation was done. Quick feedback within the group & direct action enabled the groups to actually manage to finish the high fidelity prototype within the given time frame.
From start to finish every button click was mockup up, e.g. see the Fiori Launchpad tile where the persona starts:
to the detail of the application:
Day 3 – Technical kick-off & first hands on
On day three the goal was now to kick off the development of the Fiori app and create a skeleton version of the app where views & navigation exist but the content of views is still open. Naturally the workshop attendees changed a bit to reflect the technical focus: UX designers & product managers stepped out, but not before sharing their interest in the results at the end of the week which was a nice proof point of the engagement level and enthusiasm by the results achieved in the first two days.
The day started with a technical overview of the current architecture, system landscape & deployment for Fiori apps on the on premise suite.
Following the overall architecture we gave an overview of SAPUI5 by explaining basic SAPUI5 concepts with the Fiori Sample / Reference applications which are available with the SAP Web IDE. To name a few examples we covered topics like the purpose of the Component.js file, explained how the MVC pattern is realized in Fiori apps, how test data handling (mock capabilities) or translations are realized. Of course we also dove deeper in particular topics of interest which were raised in this interactive form of initial enablement.
Next the group discussed how to best get started with the actual development. The agreed working mode was to have one team of two developers to focus on the OData service development where one SAP coach would sit at their side to walk them through the development process. The OData service development team decided to use the SEGW capabilities and used a step-by-step blog to build an OData service on existing APIs.
The remaining developers started with the Fiori app development with a code dojo like approach. Due to different knowledge levels in the team (expert to novice) the team felt this is the best approach to get started as it had the effect of having discussions & questions as well as getting everyone on the same page. A SAP UI5 coach assisted and guided the team when required.
The passion in both groups was very high, even so high that the OData team stayed some extra hours until the OData read service was ready to be consumed by the Fiori app the next day.
Day 4 – effective team work to finish the application
On day 4 the team got back together at 9 am and started with the discussion how to tackle the 4th day. Since the OData service was mature enough for the app to serve the read scenario, and the focus was to enable every developer to develop Fiori apps, it was decided to have the entire team to focus on the UI developments.
To get started, one developer shared his screen with the entire team which then started development. As a whole group, the team developed the connection to the available OData service through HCP capabilities and bound OData service attributes to the UI. More precisely the team used the metadata.xml of the built OData service as a base and developed the actual data binding to existing UI elements. After successfully calling the OData service and after seeing actual backend values on the UI, the pattern was clear to the team members, which was the base for scaling up the development. The team then took a few minutes to discuss the various work packages which needed to be developed: e.g. the master list, the detail header and footer as well as 4 different tabs for which the content needed to be developed.
Having identified the work packages, each developer picked up one of the topics and developed in parallel. Using the Web IDE and a central GIT repository, it was great to see with which speed every developer was able to provide his contribution to the overall Fiori app. During the parallel development, two SAP UI5 coaches helped whenever developers got stuck or had a question.
By the end of the development on that day there were 106 commits in the repository and the result was remarkable. It was pretty impressive to see how much of the design has been realized as a Fiori app and certainly the goal of enabling the team to develop Fiori apps had been achieved. To reward ourselves we had a great night out with the team to enjoy some local Bavarian food.
Day 5 – final presentation and time for more…
On the 5th day product managers & UX designers joined the development team which then presented its results. People were impressed on the progress to have a Fiori app that can read data from the internal test system with a UI that is responsive, simple and delightful to use. The Fiori app was close to the initially designed high fidelity prototype and proved the workshop to be a great success.
Due to the fact that the team was making such great progress, we spent some more time to present and demo capabilities of Fiori Smart Business applications and their power to cover insight to action use cases. After lunch we wrapped up the day with the next steps to take the Fiori app mobile by providing an overview into SAP Mobile secure and SAP Mobile app protection.
With a final positive feedback round, we wrapped a very successful week of passionate work and a great learning experience.
- SAP Managed Tags:
2 Comments
