At SAPPHIRENOW in early May I caught up with Sam Yen – Chief Design Officer at SAP. Sam’s areas of responsibility include design and user experience – the most high profile product outcomes being SAP Fiori and Screen Personas. But a significant part of his story is design – encapsulated by the “Design Thinking” mantra – and especially placing user experience at the forefront of the design process rather than as simply one of the outcomes.
A simple example of this is how the designer is becoming an integral part of the process of building user experiences. Ideally the designer is involved very early in discovery sessions with the end-users. In a perfect world the designer may end up producing a working prototype that can be passed across to a developer to complete. To get from discussion to final prototype might involve lots of sticky notes, whiteboard diagrams, iterative discussions, wire-frame diagrams, interim prototypes, etc. And most importantly real collaboration.
All good you say – but where are all these designers? How many do you have in your organisation? Let’s measure it in the ratio of developers to designers. Do you have a 10:1 ratio of developers to designers? If you do you would be an exception. Do you have 100:1? 1000:1? Perhaps you have a CX_SY_ZERODIVIDE exception? #abaprules
Designers have a scaling problem. This scaling problem often means the developer fills the design role – and developers are not necessarily great at design. They also tend to be biased towards building a solution without the discipline of working with prototypes to fully appreciate and incorporate the end user’s needs.
Sam shared with me a design tool that was being developed to help with this problem. It is called BUILD – and at OSCON a few weeks back SAP released it into the Open Source community so we can all try it out for ourselves. You can find it at https://github.com/SAP/BUILD
BUILD helps you create working prototypes quickly and easily. For example you may start with a couple of images taken from your whiteboard session with the end users. You can import these images into BUILD and then create a simple interaction to transition between them. Hey presto a working prototype! You can then enhance the prototype by placing actual controls onto the images to make them more realistic. Say put a button control where there are buttons, simple forms on data entry areas, tables on tabular content. As you add these controls you also include interactions so that, for example, when you click a navigation button the prototype navigates to another page.
Prototypes can be published and shared with others to get their feedback. BUILD also has a concept called “User Research Studies” where you can not just share individual screen mockups and working prototypes but ask questions of the study participants, allow them to add annotations, and set them user interaction tasks to evaluate how workable the prototype actually is. These studies capture information like page flows to describe the user’s interaction with the prototype as they perform tasks and heat maps to show where the users click on the prototype.
BUILD is very much a work in progress. There are signs that SAP rushed to meet the OSCON deadline. Expect more functionality to come soon. This will include the ability to create sample data models, and sample data, that can in-turn be used as input to so-called Smart Templates to create prototypes from the sample data model. Hopefully this functionality comes soon as these are not just useful aids for creating realistic prototypes but also important artefacts to pass over to the developers when it is time to turn the prototype into a working application. You can learn more here.
There are a few other things that I think would improve BUILD as well.
One is that I would like to have the complete suite of SAPUI5 controls available to me when I am building my prototypes. These libraries are changing and evolving constantly so a way of “plugging in” my preferred UI5 library into the BUILD prototype editor would be awesome. I would also like to be able to export my completed prototype pages as ready-to-run SAPUI5 XML views.
And finally, if I am building a sample data model I want to be able to export it in a format that can be consumed by my backend data modelling tool. If I use NetWeaver Gateway, for example, I want the data model to be available in oData metadata format so I can simply import it into the Gateway Service Builder tool to replicate the data model.
Loving the vision of BUILD – and as always wanting more.