Whats important to FIORI – Principles or UI5
Hello All,
I am writing my blog after one full year away from SCN. Consumed by work and delayed by the fixes to new SCN, I stayed away from blogging. Today, I take my time to share some deep, personal view on SAP Fiori application – custom.
SAP Fiori evolved from being a set of apps to an UX paradigm. UX paradigm proposes to list down guidelines and principles to execute user interfaces that ensure compliance to standards. In my discussions on the technical aspect of the applications, I am torn between choosing between the principles and sticking to wireframes. Do we follow the path of the sheep and stick to grass on our way or do we raise our heads and look at the higher picture.
In most applications, we are driven by requirements. We are driven to meet the expectation. Fulfill the wants. Needs are not quantified, so why bother fulfilling it. SAP UX design methodology talks of evaluating, design and develop. When the scope to evaluate and design is compromised, we have been left the option to develop. So, when the team is cornered to develop the stated, who owns up to the responsibility to ensure the compliance to FIORI design principles.
Fiori lists down the principles in the simplest of forms, Simplicity being one of them. So, if we are in violation of non-adhering to one of them, does it disqualify being a FIORI application. Is it enough to make use of UI5 technology to make the application qualify for SAP Fiori? What are the implications of an application being Fiori or not? Is it even important? Why is it that standards and rules which are so strictly applied and made legally compliant in all industries be blatantly violated and compromised in the software industry. The only factor against software is for it being too soft on its violators. There have been numerous occasions when we read from individuals of the pressure situations when the adherence of the team is to fulfill what is requested and not provided the environment to express the willingness and freedom to explore the various principles of Fiori.
Fiori is a great concept and is something which brings the SAP haters closer to SAP than ever. SAP has put in the immense effort is making it appeal to a wider audience. It is the implementers of SAP Fiori who carry the responsibility of fulfilling that vision.
Thank you.
The views expressed in this blog are personal in nature and have no resemblance to any organization or individuals related.
Hi Sharath,
Always a delight to hear another passionate voice on this topic.
Actually Fiori has always been about the Design - the first set of apps demonstrated that and from there it has grown and grown to a comprehensive design vision, supported by design and programming paradigms, methodologies and toolsets. Not to mention Fiori Qualities - which address exactly the topic of what really distinguishes a Fiori app from an app that just happens to be written with SAPUI5.
I agree it can be a challenge to keep the focus on end users and the principles that make Fiori a success for end users and stakeholders alike.
We are now starting to advocate for a User Experience Lead on project to drive this. In other words just as...
...we need a UX lead to look after the end to end user experience to make sure it delivers on the promise and the goals of the project.
For example the UX Lead would:
I'd be interested in your thoughts on whether this role would help address the challenges you see on project.
Rgds,
Jocelyn
Hello Jocelyn,
Thank you for your valuable comment.
I agree that a UX lead should drive the UI aspect of the development. UX lead should ensure the user's aspect of the actual solution. The manner in which the functional lead is responsible for the oData services and its logic, a UX lead shall be responsible for the UI and UX aspects of the solution.
Unfortunately, we do not live in an ideal world. Timelines and budget restrict the intentions and process with the obvious. Only if we could quantify the effort and the returns in having a UX lead, we can only talk about the best practices, but we usually fall back to our existing practices.
The UI design or UI developers should eventually be elevated to the role of UX leads which I see as a natural progression. It is for the stakeholders who invest in teams to define the role of UX lead as part of the team structure.
Keen to hear from you in this topic.
Regards,
Sharath
Hi Sharath, Agree that we need clear activities, deliverables, and effort estimates so that it can become part of stakeholder thinking and included in projects. That's what we are working on.
Rgds,
Jocelyn
Hello Jocelyn,
It's assuring to hear that SAP is pushing the design approach to its rightful place.
Regards,
Sharath
Enjoyed the Blog & comments.
My take is that we must seriously take up the ' Needs of the User Groups' & resolve them. But leave the 'Wants' - which are basically wishlists - good to have.
In situations where there is pressure from User Groups on 'Wants', the quick answer would be hold the relevant User Group responsible for the Time & Cost which would make them think again judiciously.
Hello George,
Thank you for your feedback.
User Groups help in including the user requirements. However, they are slowly turning out to be mostly the functional needs. UX is not a concept fully understood by the users as it's not easily quantifiable. UX also varies from users to users and generally bipolar requirements are ignored in favor of traditional requirements and perceptions of User solutions.
In my view, UI designer should drive the UI developments and negotiate on behalf of the User's Experience with the Design team or the functional team. This would be possible only if we have such a role within the project.
Thank you.
Regards,
Sharath
Hi George,
Just to expand on your thinking...
Wants and Needs are part of what the Discovery and Design process is there to identify. They are certainly NOT something we should simply be asking users.
If there's one most important piece of advice for newbies in user experience it would be ... "stop asking users what they want" . You'll get an answer but not the right answer or the right outcome. That's why we do end user research.
In reality its a little more nuanced than that... but essentially you are understanding the users real needs and desires to work out:
a) What's important to them and WHY - and that includes unconscious needs and desires - the ones they don't even realise they have or can't explain to you because its buried deep in their mental model and autopilot behaviours
b) Turn that into user stories that guide a Minimum Viable Product approach to design - so that each iteration provides real value to the end user and that value can be justified against business priorities.
Just trying to sort out needs and wants is not enough. To properly judge end user value and business impact we need to understand the why... often end users can't give you that clearly if you ask them. Similarly its easy to categorize real needs as wants if you aren't the end user.
Hence the importance of Discovery and end user research as a a prerequisite to Design.
In other words you - as the designer - have to understand the problem - even when your end users don't or can't or can't articulate it.
If users are pressing for what you think is a Want, it's important to dig deeper and work out what is really driving that need and not dismiss it too quickly.
Sharath & Jocelyn,
Thank you for your replies.
I was only viewing it from a Project Management & ROI perspective.