First let me start off with what I am calling “SAP’s new UX Strategies”. What I am referring to is Fiori, Personas 3.0, and SMP native and hybrid applications. As I will discuss further, projects for these products are very different than your typical SAP project of designing reports or interfaces, writing customer functions to process custom fields or custom IDOC segments, etc. These are all things I have worked on before, and I can tell you, it is very different than the Fiori projects I have been working on lately.
One term you will hear again and again from the SAP experience community, top design schools, and companies working on projects and products all over the world in all industries, is Design Thinking. Wikipedia defines this term as “design-specific cognitive activities that designers apply during the process of designing”. It is a framework or process by which designers can solve complex problems, and a quick google search will show you many diagrams of the steps involved. The one I will use is shown below, and was obtained through a document by the Stanford University Design School, or “d.school”.
To focus today’s conversation, I really want to concentrate on the first three steps. Every SAP developer has gone through the prototype and test phase, but these first three steps are new territory. In a later blog, however, I plan on addressing how these last two steps have their own quirks in these new UX projects, but that is for another day. This blog will discuss the importance of understanding, and devoting time to, the Empathize, Define, and Ideate steps. With these processes, terms, and types of projects in mind, let’s dive in.
In my opinion, empathize is perhaps the most important step. The key skill here is listening. Listen to the people you will be working with and designing for and understand their process, their pain points, and what types of outcomes they desire. Whether you are designing new screens in Personas, developing new mobile applications in SMP, or creating a custom or extended Fiori app, your options are almost limitless. You can make it look, feel, and behave exactly how you want, so it’s important to know the goals of the application and the eventual end-users before you ever create a mock-up or write a single line of code. The same Hasso Plattner Institute of Design at Stanford I was referring to earlier lists how to empathize and they say to observe, engage, watch, and listen. Maybe you are tasked with creating a mobile application for an SAP transaction. A good start is to watch users interact with that transaction. Listen to what they have to say about it, both good and bad. Understand what process it is you are there to work on, and understand what the current state is. Engage the end-users and ask them questions about what they do, how they do it, and a few things they might change if they could. Engage not only the end-users, but all project stakeholders. This could include shop floor technicians, business users, approvers, managers, HR teams, anyone. Get the fullest picture you possibly can of how things are done today, and understand the desired outcome of the project you are undertaking. This process takes time and effort, but it is important to know all of this up front so you can create an accurate definition of the problem and goals you are out to achieve. A good tool for the empathize phase, and one that serves as a great summary of the process, is the empathy map. An example is shown below. This image comes courtesy of Machteld Faas Xander.
The concentration is on the user and what they are thinking, seeing, saying, doing, feeling, and hearing. By keeping this focus on the user and their needs, as well as the desired outcomes, and top challenges, the empathize phase will give a great start for defining the project.
After the empathize phase, after your project team has a clear understanding of the users they are designing for, the challenges they face, and the goals they would like to accomplish, it’s time to develop what the Stanford Design School calls a “point-of-view”, or POV. They define this POV as “the explicit expression of the problem you are striving to address.” What challenge are you tackling and why? By the end of the define phase, there should be a clear enough vision put together from all of the information and data collected in the empathize phase to set the team moving towards determining the solution. From the definition phase, the team gains a focus on the user-needs and goals they are setting out to achieve. As the Design School says, your problem should be discrete and not broad, so that you are not trying to do all things for all people. A properly executed design phase will provide the right amount of direction for the team to enter the ideate phase.
As the name implies, the ideate phase is where you start to hash out ideas and potential solutions. The first two phases, emphasize and define, have all been about understanding the challenges, and framing them to understand the goals of your project. The ideate phase is where you turn the challenges and goals into an end-product, a mobile application being an example in the context we are talking about. It is important not to judge ideas early on in the ideate phase or think any idea to silly or stupid to be worth mentioning. Sometimes an outlandish idea leads to a more reasonable one that is a very effective solution. There are all sorts of techniques used to approach the ideate phase, with the most common one being brainstorming. It’s an effective tool that lets the group build off of each other’s ideas, allowing more solutions to come about than if one person just thought about the problem quietly to themselves. From the ideation phase, it is not important to come out with a single solution, but perhaps a few, each of which can be prototyped and tested for refinement.
Brainstorming image courtesy of clixmarketing.com.
To me, these steps that I have outlined are relatively new when it comes to SAP projects. From my past projects, I might know that a customer wants to create an interface to update equipment records, and I create a batch process that does so, or they want to be able to run some report, so I add a few select options and check boxes, and fetch the necessary data. These types of projects are fairly confined to the typical way of doing things in SAP. There is not a huge focus on user experience and the many ways that a problem can be tackled. But developing custom applications for customers, that is blue ocean territory. And because we are not only developing the back end functionality, but also the presentation layer, the mechanism by which the user interacts with our solution, a lot of time has to be spent on understanding the user and their process and needs, and the potential solutions are almost limitless. UI5 provides a framework by which we can build our solutions, but it is far more flexible than building a report for the SAP GUI. For that reason, it is important to incorporate these new steps, and the Design Thinking process into your SAP UX projects. By not doing so, you not only open yourself up to more rework late in the process, but you don’t allow yourself to fully utilize these new, flexible, customizable products to their potential, ultimately doing the end-users we set out to help a disservice. But if these steps are implemented properly, and time and effort are spent learning and designing, as opposed to jumping right into building and testing, you can create simple, beautiful products that enrich the user experience and drive customer satisfaction to an all-time high.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
