Skip to Content

Recently I posted a blog about BUILD – titled Let’s BUILD.

For those of you that missed it BUILD is a collaborative UX design tool. It lets you start with something as simple as photos from a whiteboard session to commence building working prototypes. These prototypes can be published and shared with stakeholders to get quick feedback and to facilitate rapid iteration of the prototype. One of the goals of BUILD is that the completed prototype will be of a sufficient quality so that it can act as a fully featured starting point for the developer.

RaviMBlog2.png

BUILD also allows you to collect feedback via User Research Studies that feed analytics to better understand how users are interacting with your prototype. Not something you find in your average UX design tools.

RaviMBlog1.png

For more information on BUILD I encourage you to check out this blog from Ravi Marwaha. You should also take a look at the BUILD YouTube Channel that shows off many of the features of BUILD. (Disclosure – I grabbed a few of the images in this post from Ravi’s)

When I posted my earlier blog I only had access to the version of BUILD that SAP had published on GitHub. This was (is) a very early version and many of the key features are not yet enabled on this release. While I applaud SAP for making BUILD an Open Source project there have been very few updates since the initial commit – and most of those are documentation updates and tweaks.

However at the end of Ravi’s blog there is a call for those interested in participating in the BUILD Beta program. This means I now have access to a much later version of BUILD to tinker with. Even better SAP are hosting it for me so I don’t need to jump through deployment hoops every time there is a commit.

BUILD also supports a “bottom-up” approach to prototyping where you can create (or import) a data model, create sample data, and then bind this data model to the controls in your prototype. You can also apply the data model to pre-defined templates as well. This is all very nice – but it is not exactly what I think is needed. It is close – but for me it misses the important “outside-in” perspective of designing user experiences.

The problem I have with this “bottom-up”, or data model first, approach is that what you are able to represent in your prototype is limited by the data model. You can’t bind a UI control to something that is not already represented in the data model. Sure you could jump between prototype editor and data model editor but what a pain that is.

I favour an approach where the requirements of the prototype can be immediately reflected in the data model. So, for example, whilst the designer can choose to bind a control to an existing object in the data model she can also choose to create that data model object at the same time. In fact she could potentially construct the complete data model from inside the prototype editor this way – leaving aside the step of maintaining relationships between entities.

Then the designer can hand over the signed-off UI prototype to developers for building the application and she can also hand over the data model to the developers for building the web API interface.

And for those of you who are thinking “BUILD is Open Source so why can’t you just contribute to this idea yourself?” Sorry, SAP is not yet taking contributions. And besides, that’s way over my pay grade (and skill set). 😏

If your day job is designing user experiences – especially “Fiori-style” SAPUI5 ones – I encourage you to check out BUILD.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Christopher Solomon

    Nice follow up to your last! Excited to see where this tool goes from here. I hope not too SAP-centric so it can really stand on it’s own to gain ground among the “design elite” but with the ability/capability for something like “plug ins” for really SAP-centric things. Why can’t I have my cake and eat it too?!?!?! 😛

    (0) 
    1. Graham Robinson Post author

      Thanks Chris,

      Ravi’s blog mentions being able to “plug-in user interface libraries” so it seems this request is on the project backlog. Here’s hoping it comes soon.

      Cheers

      Graham Robbo

      (0) 
    2. Jocelyn Dart

      Just fyi…. one of the things I played around with was using BUILD for storyboards… as a way to cover earlier aspects of the discover-design-deliver lifecycle and it works ok for that. 

      And that’s definitely an approach that would lend itself to non-SAP centric scenarios as well as being an excellent way to communicate and get feedback on use cases.

      I’ve passed those thoughts on to the BUILD team so we’ll see where that goes…

      … but I would also encourage everyone in the Beta program to email your feedback to contact.build@sap.com so that the team can take these suggestions and feedback into consideration.

      (0) 
  2. Arijit Das

    Hi Graham

    Great blog. Went through the Splash / BUILD demo yesterday (Build Your Own Fiori App OpenSAP course).

    Couple of questions –


    And is it BUILD embedded in Splash or Splash embedded in BUILD?


    Is it free or subscription based service?

    Thanks

    Arijit         

    (0) 
    1. Jocelyn Dart

      Hi Arjit

      Splash is the entry point to the Discover>Design>Deliver lifecycle of UX. 

      Splash includes an entry point into BUILD

      “embedded” is not the right term here

      If you do the exercise in the BYO Fiori 2016 course you will see that BUILD is currently provided as a free service. I am not aware of any plans to change that. However you could email your question to contact.build@sap.com if you need a formal response.

      Rgds

      Jocelyn

      (0) 
      1. Arijit Das

        Thank you Jocelyn!

        Did the exercise to experience it first hand! I really like the Heat Maps that show where users (sorry collaborators) have clicked!

        Regards

        Arijit    

        (0) 
  3. Arijit Das

    Hi there

    Seems that the first question management ask and are concerned about is the Security and Data Privacy.

    • What are the security implications here?
    • Is my data secure?
    • Who else can access my data?
    • Can clients get access to a private tenant?
    • Is there a pricing model for a private tenant?

    Any ideas on how to address these?

    Regards

    Arijit Das

    (0) 
    1. Jocelyn Dart

      Hi Arjit

      While these are valid concerns they are off topic for this blog.

      Please raise separate discussions. I would recommend separate discussions for security & data privacy as these are *very* different. Security is largely a technology concern involving measures in many layers. Data privacy is more a design concern IMO

      rgds

      Jocelyn

      (0) 
      1. Arijit Das

        Hi Jocelyn

        I concur!

        Security and Data Privacy are separate areas.

        Where would be the best place to raise this (are you suggesting just a Discussion on it in this space)?

        Regards

        Arijit

        (0) 
        1. Jocelyn Dart

          Hmmmm…

          Suggest you raise a security discussion in the Fiori space as it is tech specific.

          Data Privacy could be raised in Design Thinking first… might be useful to see if this has come up in discussions at all.

          (0) 

Leave a Reply