BUILD – from the outside

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.

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.

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.