Off the Garden Path —
Supporting a Value-Led Design Process

Clayton Farr

Clayton Farr

Below is my presentation for the FRONT Product Design Conference on June 18th, 2015.

I took a slightly different approach collecting my thoughts for this one and basically wrote them all out in article format first. Helpful for quickly republishing here, not necessarily recommended for easily converting into spoken ideas on stage ;)

This probably needs to be (and probably will be) broken into a couple of individual articles to make it a bit easier to digest, but here it is below in its full glory for you early visitors. About a 30 minute read, all together – or you can jump to a specific part, via the section links below.

If you'd like you can also download the slides by themselves, and for those who don't like silly pictures, you can download a PDF of just the content.

Enjoy,
Clayton

TL;DR.

I believe there’s a need, and now the opportunity, to improve the information we base our product design decisions upon.

Today, most of our early design decisions are based on pretend use of pretend things. It’s only when our ideas meet reality – usually when a product ships – that we truly learn what, if anything, people find valuable about them.

To build our best products we need to be able to build out from the actual value they provide, as early as possible. Understanding actual value requires observing real behavior, which requires the we build design experiments that feel like real things.

Dig in below for some detailed thoughts on how we can do this, today.

What Lies Ahead

A Premise for Building Better Products

Principles for Value-Led Design

Putting Principles into Practice, Today

Join Conversation

The Premise

Our Goal

As the ‘designers of products’, what is it exactly that we’re trying to accomplish?

I believe our goal as product designers is to create things that complement the needs and desires of the folks who use them. To compliment the way they think, live, and what matters most to them - things they themselves may not even be aware of. In shorthand, to match their values.

To do this well we need a couple of things - an understanding of those values, and how well we’re actually meeting them.

The Problem

However, today this understanding is far less than ideal.

Most of our design feedback today comes from user behavior that is contrived and artificial – a garden-path, zoo-like experience that doesn’t reflect real-world use. This input is helpful to a point, but it can yield incomplete or incorrect learning since use in the real-world is often surprisingly different.

We do this because real behavior - allowing our designs to be used in the wild - requires that we build real things. And building real things is expensive. Too expensive to be wrong.

So even amidst a wealth of design tools and processes our understanding of the value that we’re actually delivering happens very late in the game. Too late often to inform our foundational design decisions and help drive our subsequent choices.

But to build our best products we need to be able to base our decisions on the actual value people receive from them.

An Opportunity

So what if instead we could move our understanding of that real-world use and behavior to the beginning of our design process? What would happen if we could learn early not only if someone can use our product or will use our product, but also when they use it, how they use it, and possibly why they use it as well? What if we could make building real things inexpensive enough to be wrong? What effect could that have on our work?

Through a mix of strategy and recent technology, I think we can start using such a value-led design process, today.

In the first half, we’ll look at the larger principles we can use to guide a value-led design process and toolset. More important than any specific tool or technology are operating truths that can help guide our choices amidst the options available today, tomorrow, and the day after.

Then, to make good on the promise that we actually can work this way, in the second half we’ll explore what tools are available today that support and afford a value-led process.

Value-Led Design Principles

In our world, the sands of our tools and technology seem to change daily. We need higher-level guidelines that can direct our specific day-to-day choices. As we look into the details of building and utilizing a value-led design process, there are three larger ideas that we can lean on for guidance.

Principle #1

To begin uncovering these, we first need to ask ourselves what types of value we can actually create or affect through design?

In our field there’s no shortage of specific design titles, and activities associated with each — visual design, interaction design, user experience design, product design, and a number of others I’m missing or that we haven’t thought to stick a label on to yet.

But for our purposes here, it’s useful to consider design in the larger sense of the word – all of the choices we make toward a goal and even the choice of the goal itself. Whether we’re making these choices consciously and purposefully, or whether they’re occurring implicitly they all add up to the outcome we receive – or have in effect, designed.

There are other methods for creating product value, of course - marketing, positioning, and the like - but what are the of methods of creating value that are specific to design itself? With an understanding of these, we can then know which levers are available to pull, and when.

If we take our multitude of design roles and associated tasks and do a little of the affinity mapping that we like to always talk about, we start to find some interesting and helpful groupings.

It seems that through our design activities and choices, we can create value in four ways - we can make something more useful, understandable, enjoyable, and possibly delightful.

I’m sure there are other names we can use for these groups as well, but these feel close to the mark.

Useful

The choices we make for our product’s basic form and function determine what use it can serve in our audience’s lives. The better we’re able to match their needs and desires, the more valuable our products become.

Our choices of what basic form our products should take set the playing field. For example: Is it a personal or group experience? Is it meant for intermittent or consistent use? Will it be tailored to small screens, large screens, or all?

Our choices of what functionality our products should provide determine their ability. For example: What types of things or content does it allow to be experienced? What, if anything, can be manipulated or created within it? And what can be shared, either within and outside of the product?

Understandable

Beyond designing utility, we create additional value by making that utility meaningful and usable. We spend much of our time in design working to craft meaningful organization for our products - to answer the question ‘Can this be understood enough to actually be used?’.

This work includes activities like user research and information architecture to choose how to organize, group, and name things to match our audience’s mental models. It also includes the choices we make in task and interface design to organize and layout elements across time and in space to create meaningful relationships and hierarchies.

Enjoyable

Beyond being understandable we can also use design to make our products enjoyable to use. We can add value by making them pleasant and attractive, and easy and helpful.

We use visual design to craft compelling presentation that is appealing and appropriate. And we use interaction design to provide clear feedback and responsive functionality.

Delightful

Ah, that word we toss around in meetings and on our promotional websites. In fact, I think we might have it on our site right now.

What about the value we can sometimes create that goes beyond just making something enjoyable? Those details or enhancements that pleasantly surprise people, providing them with enhanced meaning or unexpected abilities.

We do this through transitional design, progressive functionality, or the occasional hidden feature - things that complement all of our other work, in helpful and unexpected ways.

As we look across the types of value we create with design, it’s helpful to consider what relationship, if any, they may have with one another?

Are we able to enjoy something, without first being able to understand it? Is there anything worth understanding if the item has no use to us? Can we experience delight - the pleasantly unexpected - without first being in a positive frame of mind to receive it?

It seems, that to deliver some types of value other value must already be present.

A Hierarchy of Design Value

This suggests that there may be a hierarchy in the types of design value we create.

Now, like any good model, this one probably overlooks some exceptions to make a larger point that generally holds true.

It’s not that any one of these areas is more worthwhile than the other, but rather that there is an order of concern in how we create and deliver value to the folks who use our products.

Although the breadth of design in each level may differ, it appears some value in a lower level must be satisfied before we can create meaningful value in the next level. Knowing this, we need to ask ourselves at each step, have we provided a secure foundation to continue building upon?

Incidentally, in looking for exceptions to this, one thought that comes up is ‘art’, where it seems it wouldn’t need to be obviously ‘useful’ or ‘understandable’. But I think even here, those values are likely satisfied in the one who values it - whether consciously or unconsciously.

Principle #1 – Follow Hierarchy of Design Created Value

This model provides us with a helpful guideline, our first principle in adopting a value-led design process: Follow the hierarchy of design value.

By identifying the types of value we can create, and appreciating their dependencies, we can then recognize where our current work falls and ask “can the ground beneath it can support it?”. And if not, we know to work instead on those things that need our attention first.

Thinking and working in this way allows us to follow a design process that is able to build upon, and outward from the actual value we deliver in our products.

Principle #2

The catch then is, how do we know when we’ve delivered the value necessary to be successful and support the next level? Each product is unique mix of purpose, context, and audience, and therefor has unique design needs.

We don’t know - so we test.

We create examples of our products - prototypes of all sorts - that not only help us better understand their form and but also allow us to get feedback from the people we hope will use them. And thankfully, over the last couple of years we’ve received a windfall of rich tools for prototyping digital products.

But when we look across our levels of design value, what exactly are we testing?

What We Test (and What We Don’t)

Our design tools are increasing in fidelity and ability, but nearly all of them focus on prototyping the value in the middle and top levels of our design hierarchy.

No matter how detailed the interactions or animations, most of these prototypes are still a proxy of the final thing. Proxies are able to help us test agreement, usability, and visual appeal but what about the foundation that this work sits upon and is informed by?

What does it mean to receive positive test results for ‘understanding’ and ‘enjoyability’ when we aren’t certain that what they’re serving is correct?

We can and do test demand - ‘if’ people are likely to use our product - but it’s often not until the actual release that we truly understand ‘how’ they use it.

How we test our design work has changed as our understanding of its value has evolved and our technical ability has improved.

Originally it was pretty much go with your gut, hope for the best, and fix any unforeseen issues as quickly as possible after the initial release.

Thankfully, we’re a lot smarter now. We try to gain understanding and confirmation of work as early as possible, testing its organization, usability, presentation, and hopefully demand.

But, it’s time to build on this and move to the next evolution of how we test our work. In order to create our best products, in order to build out from the value we’re actually delivering, we need to make the testing ‘usefulness’ a standard part of our process as well.

How We Test

Equally important to what we test is how we test.

Today, almost of our testing is essentially pretend. Controlled experiences with pretend products, where we and our test subjects do our best to approximate what we might do in real life.

When we pretend to use a pretend thing, we think we know what we like, and what we would do, but we’re very often wrong. It’s our actions in real situations that reveal what we truly value. Actions reveal if we’ll use a thing, why and when, and what we’re willing to trade to get it.

In the real world our behavior is driven by an unforeseeable mix of factors — whatever needs, location, limited time, state of mind, and distractions a moment may dictate - let alone what device we may be using. It’s these real-world contexts that reveal true behavior, which in turn reveal the value people will perceive and receive from a product.

Our goal as the creators of products should be to acquire as accurate of a compass for our design decisions as possible. To do this we need to observe real behavior.

Principle #2 – Build Real Things to Observe Real Behavior

Real behavior requires real use, which requires real things.

“Why, we never thought to build real things! You’re an absolute genius!” Well, thank you. But, assuming that this thought may have crossed our minds, then why aren’t we doing it now?

Well, to build real things has normally taken a lot of time, a lot of expertise, and all told, a lot of money. To much of all of these to try something out that could be wrong.

But if the benefit is great enough - that we could accurately inform our designs from the start - is there anyway we could possibly make creating ‘real things’ possible and as affordable as our current prototyping methods?

Principle #3

To do this, first we need to define what’s necessary for something to feel real enough to solicit real behavior. A few higher level considerations stand out –

It should be useable without supervision. To support real use, a person shouldn’t have to keep their actions on a garden-path, or require our oversight or direction.

It should be useful in its entirety. All of the displayed options or content should be navigable and all of the displayed features should be functional. No dead links or ‘Under Construction’ GIFs.

It should be accessible in the context that it’s intended for. Meaning that it should be available on the devices and in the locations that our targeted audience will be using.

To illicit real use, what our products are made of doesn’t matter much, as long as the experience they provide feels authentic.

Now, as the ones doing all of the work, what do we need to make creating real things viable?

We need to be able to make real things easily and quickly enough to be wrong and be able to build upon our learning - repeatedly.

We need to be able to test the relevant things in question, without having to build unnecessary, irrelevant infrastructure around them.

To make this all worth it, we need to be able to observe that behavior in the real world to learn what in our products is being used, as well as when and where.

And ideally, we want tools that remove abstraction, that can put us close to the design process, allowing direct and visual manipulation of our work.

Perfect. So, what manner of sorcery can we employ to accomplish all of this?

In a word, leverage.

Archimedes is credited with claiming - “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” And given that he was a much smarter guy than I, I’m inclined to follow his advice.

There a number of ways we increase our leverage to make the creation of real things, on our terms, possible - both in the processes we follow and the tools we utilize.

Leverage of Scope

There’s a bit of sage wisdom in development that the fastest code is no code. If you can achieve your result without requiring additional code that needs to be run, and later maintained, you’re doing something right.

The same wisdom applies to design. What’s the optimal amount of design - enough, but no more - that’s needed to achieve our desired result and test our assumptions?

Of course, this depends on the result we desire. Often when we talk about limiting scope, we talk about creating a Minimum Viable Product. But what we usually mean by this is a stripped down, first version of our product.

Instead, I think a term coined by Steven Cohn, is more appropriate and useful. Rather than thinking of Minimum Viable Products, instead think of Minimum Viable Experiments.

Experiments are intended to learn something. They’re not expected to grow, or scale, or even succeed. Our goal should simply be to start gathering feedback and observing users actually interacting with something.

We can gain leverage through scope by diligently asking ourselves, at each step, what amount of design is truly relevant to what we’re trying to learn?

As we start our products we can begin by identifying and guessing the core usefulness they require, and then build only what is needed to deliver it, iterating as necessary from there.

Leverage of Prototyping

Design prototypes can provide us with an incredible amount of leverage using, but only when we let them remain what they were intended to be – experiments.

They give us license to not only be wrong, but also to not be the final product.

Of course, it is important that we can reach the actual people we’re testing, but we don’t need to reach all of them - just a meaningful number. This means that for our design experiments, we’re not bound to using the final technology, final infrastructure, or to set the groundwork for the final code.

We’re free to use whatever we can to get the job done. Our prototypes can be made of duct tape and unicorn hair as long they appear real to our audience.

However, once we begin expecting our design prototypes to be the final thing - to be able to reach everyone, to be fully scalable - we start to willingly give this leverage away.

Leverage of Convention

What is the special sauce in our creations? What makes the things we create for our companies and clients unique?

I think it’s rare that we actually create some new element that the world has never seen.

Most of the ingredients that make up our products are relatively common and present in a host of other products as well - it’s our unique combination of these elements, aligned to a purpose, that usually produces value.

Taking advantage of these conventions can provide us with massive leverage as we work to bring those pieces together and shape them into a form of our own.

We can do this in our design process by leaning on common design patterns, solutions, and audience expectations - and building on and out from these as needed.

We can take advantage of recent advancements in web technology that allow us to reuse, and customize, interface and functionality across our projects.

All of this allows us reduce the time we spend on what’s commonplace and instead focus what is truly unique to our designs.

Leverage of Design Value Hierarchy

Someone once said the fastest design is no design - or something like that.

We gain leverage when we recognize there is a relationship between the types of value we create in design - and that some require the support of others. This allows us to better understand what types of design choices are necessary, and unnecessary, depending upon what value that we’re currently looking to confirm.

Leverage of Existing Data

When we look to make real things we quickly run into the issue of using or modeling real content.

Beyond just adding ‘real’ content into static mockups, we need to be able to serve dynamic content across a range of connected screens.

Thankfully the Internet’s got our back. A rich supply of tools exist today that allow us to quickly create large sets of content, that can be modeled in any shape or form we may need.

Additionally, we’re also living in a golden age where information of all sorts is available only an API away. Which is nerd speak for ‘pretty easy to get to’.

We can connect this modeled and 3rd-party content to our prototypes, creating experiences that mirror the real thing.

Leverage of Direct Design Tools

Lastly, is the leverage our design tools themselves afford us.

Knowing how to craft your ideas in code is certainly a worthwhile skill as it opens up a wide range of additional options and tools.

However, using code to create things that are either visual or move in time is a pretty abstract process. Even when you learn to speak the language you’re always doing some level of translation in your head between code and its result.

We don’t do it because it’s the better way to design things, we do it because it’s often the only way to get the results we need.

Design tools that afford direct manipulation of what you are creating allow you to react to and be informed by your work much more quickly – which encourages free form creation and quick experimentation.

When you have several options of tools available that could meet your needs, utilize the less abstract tools - to speed up your work and put yourself closer to your work.

Enough Leverage to Move Worlds

All told this gives us six areas we can look to, to gain the leverage we need -

Principle #3 – Increase Leverage to Afford Real Things

There are likely other ways we could also improve our advantage but by combining these levers, we can get the power needed to quickly and effectively make real things - things that let us look into the real world and people’s actual behavior within it.

Putting Principles into Practice

So, it’s nice to have ambitions to root our design decisions in real behavior, and to have some principles to guide us, but can we actually put them into practice?

Implementing this is a two-prong affair. On the one side we have the processes we choose to follow that will guide what work we do, and on the other we have the tools that can actually support those processes.

Processes

Our principles for value-led design also suggest our processes -

  1. Follow the hierarchy of design value.
  2. Build real things to test real behavior.
  3. Increase leverage to afford real things.

Appreciate that there is an inherent hierarchy to our work that affects how we can approach it.

Commit to building real things and observing real behavior in order to obtain an accurate compass for our design decisions.

Look for - and capitalize on - any advantage available within our methods and tools.

Since we’ve already looked at these ideas in detail, we’ll take the remainder of our time to dig into specific tools and technology available today to support that process.

Tools

We’ll need two types of tools -

  1. Tools that allow us to create our living prototypes, and
  2. Tools that allow us to observe real world behavior.

We’ll focus primarily on creation tools, since these are the less familiar, but also take a quick look at the landscape of observation options available.

Tool Criteria

Let’s quickly re-cap what our creation tools should offer us to build things that feel real –

They should allow us to breathe functionality into our designs - giving us the ability to add and mix the pieces that makes our products useful.

They should be able to work with data, allowing us to feed in content at the outset and also allow our audience to create, read, update, and delete information. They should also persist any changes to that data.

They should allow us to reuse common interface and functionality elements, giving us the means to leverage convention and prior work.

The designs we produce should be consumable outside of the tool. They should be deployable to the devices and contexts that our target audience will be using.

Ideally, they should have minimal abstraction of the things we’re creating, allowing direct manipulation of our designs.

Lastly, although perhaps not critical in every case, I’d personally give higher marks to tools that aren’t limited to creating designs for only certain screen sizes. Most recent prototyping tools seem to be focused on creating applications for small screens only. The world is a big place, with screens of all sizes - having the flexibility to design for any of them is an attractive option.

That’s a reasonably tall order to fill, and the likelihood of finding a tool that can do all of these things for every possible case, is pretty small.

But there are two types of creation tools that can satisfy most of these needs most of the time.

Web Components

Web Components are not a specific tool, but rather an emerging web technology. They help the web truly support modern applications, not just text documents that it was originally designed for.

If you’re not familiar with them yet, you can be certain as someone who works with digital and webby things that you will be. Like Winter, they’re coming - and it’s a very good thing.

What they afford is a whole new suite of tools and ways of working. Ways that perfectly compliment and support creating real things, real fast.

Web Components allow you to build your applications like legos - using building blocks from your earlier work or from the work of others - and customizing them as needed. These plug-and-play pieces of interface and functionality are designed to easily connect irrespective of where they came from. This is huge.

The idea of packaging interface and functionality into a single element isn’t new. We’ve been working with examples of this as long we’ve been working with the web.

For example, when we include a <select> element in an HTML document it already knows how to display the content you feed it and what behavior to use when you interact with it.

Web Components now allow us to create our own custom elements that can be used just as easily, packaging up whatever structure, presentation, and behavior is necessary.

Amazingly, this can also include packaging up how an element displays on different screen sizes - its responsive design. All of its HTML, CSS and JavaScript packaged in a single tag.

Custom elements can also be used to quickly give structure to our applications - controlling how our other elements are organized and displayed. We can quickly create dynamic page layouts that serve most situations - customizing additionally, as we need.

And using all of these elements is straightforward. They’re added like any other HTML tag, and we can quickly declare any configuration we may need on the tag itself.

We’re also not limited to only creating UI elements. Custom elements can be made for non-visual functionality as well. This allows us to easily add functionality like local storage, geo-location, and access to cameras and microphones.

To flesh out the functionality of our applications we can connect to a whole world of backend services, each also wrapped in a simple tag. Although it often feels like Google is taking over the planet, at least now we can benefit from its world domination.

One stand-out backend service - that was also recently acquired by Google (see earlier comment on world domination) is Firebase. Firebase, and others like it, allows you to save and manipulate data, perform user authentication, and more.

Once you have the option to create reusable pieces of applications something else wonderful begins to happen - a world of people making them.

The ability to use 3rd-party elements, from any source, in any project gives us with a wealth of interface and functionality to leverage for our projects. As with anything, these will vary in quality, but we already have a large number of quality component libraries available.

With Web Components we can take advantage of reusable elements and convention to focus our efforts on the value that is truly relevant and unique.

How can we start using these today?

For now, using them does require that you to jump in and mess with a bit of code.

At the shallow end of the pool this can be pretty quick and simple. There are boilerplate documents you can utilize for your application and then copy-and-paste in any available element you desire.

The deeper end of the pool requires a bit more comfort with coding, but is still pretty approachable. Here you’re able to create your own custom elements and do even greater customization.

One of the better resources to help with this is Polymer, another gift from our friends at Google. Polymer is a Web Component library that includes both a range of high-quality components and tools to make creating web components and web component projects easier.

They've also created a resource that allows Web Components to work across all modern browsers, on both desktop and mobile. Some browsers, like Chrome, already have native support for the various features Web Components requires. Others have partial support that these polyfills help to round out.

Native support and overall performance of Web Components is improving at a quick rate. They don’t work perfectly everywhere yet, but there’s a good chance that they work well for a large enough portion of your audience to be able to use them in your design prototypes today.

Visual, WYSIWYG tools for Web Components are still in development but it’s encouraging to see where these are headed.

One interesting example of what's possible can seen in how SalesForce used an earlier version of Polymer’s visual designer. They customized it with their own elements and made creating SalesForce apps (that can be deployed to phones no less) as easy as drag-and-drop.

It also opens up a whole new range of possibilities for how we build and use Design Systems for our products, but that’s a topic for another time…

Web Components Scorecard

So how do Web Components measure up to our earlier criteria?

Functionality? – Through the use of components for both front-end functionality and backend services, they allows us to build prototypes that work and behave like real applications.

Data? – We can connect sources for data - like our custom sets of modeled user content - and services to manage them - like Firebase.

Reuse? – Since Web Components are built upon reuse, here, of course, is where they really shine. They give us a powerful, flexible, and open system for reusing, creating, and sharing the building blocks of our applications.

Deployable? – Since Web Components are based on web technologies and standards they not only play nice with the web but can also be packaged up for native deployment using tools like PhoneGap.

Direct? – Ah, a negative, and for some people a large one. Right now, using Web Components does require coding, which by it’s nature is more abstract and removed from the thing it is creating. Thankfully the level of coding can be minimal and visual tools are on the horizon, although once you want to do a lot of customization, coding of some sort will probably be required.

Multi-device? – Yep, thanks again to good ol’ web standards, although Web Components have an added bonus here. Many higher-quality components have their responsive design baked in, again giving us leverage to skip creating this ourselves while we instead focus on other, more important things.

Now, even though Web Components are crazy cool, there is another category, of similar, but differently focused tools that also deserve our attention.

Visual Application Builders

As the name would suggest, these tools emphasize a visual interface, over code, while still allowing you to create functionally-capable prototypes.

These prototypes can also be data-driven, and in some cases, can integrate with all manner of 3rd-party content via APIs. And in addition to offering a visual interface, some of the better tools take other steps to help reduce abstraction in interesting ways.

Sounds great, and it is, but as with most things there are trade-offs when we compare these to other options, like Web Components.

The number of these tools is growing quickly. Quite a few are tightly bound to using fixed templates and don’t fit our needs, but a number of them are surprisingly capable.

One of the better, current examples of these tools is Bubble.

In addition to being a very capable tool Bubble has also implemented several simple, but foundational ideas that help reduce abstraction in large and important ways, making it ideal for quickly creating real things.

Like many visual builders, Bubble has a suite of interactive components to help create your product. Unlike Web Components, that allow you to import and integrate anything, these are limited to a curated set, or ones that you create in the tool itself, but they tend to cover most cases.

In most visual prototyping tools, you either have to stamp these components out onto the page and then modify them from there, or in some cases you have to know how to place them in a logical order that follows the flow of the code underneath.

Bubble lets you ‘sketch’ these dynamic components onto your page instead. It sounds like a simple difference, but the impact is massive. (Quick note: some of the linked Bubble screencasts show the older, darker interface.)

For those who are accustomed to sketching layouts by hand - using tools like paper and whiteboards or Keynote - this will feel like home. If your home was suddenly made out of magical ponies.

For those who aren’t used to creating layouts this way, sketching helps your design move closer to your speed of thought. It’s one of the most direct ways you can manipulate and interact with your designs. Rather than having to drop and adjust pre-sized widgets you can quickly sculpt your ideas and adjust fidelity as you go.

But instead of simple shapes, these are fully interactive, dynamic elements with all of their functionality intact. Using a tool like this allows you to quickly sketch working interfaces. You can quickly explore and evolve different ideas. Just the kind of leverage we need.

I’m not aware any of any other visual tools that use this approach yet, but I think it’s an example of the better way to do things.

The second interesting choice Bubble has made is to decouple the ideas of programming and coding. Programming - like cooking, designing, or any other form of creation - is essentially the act of deciding what elements to include and how they should be combined; while coding is converting these decisions into a language a machine can understand.

Many visual app builders try to help with converting ideas into code, but most make the mistake of still treating programming as coding. They do this by expecting their users to often think in code or as trained developers.

Appery is a good example of this. It’s a very capable prototype builder, but as you move past building UI and start building the functionality that drives your product you’re required to understand concepts from a developer’s mindset rather than talking about what those choices actually mean.

In Bubble these ideas are converted from the language of development into a mental model that makes sense to anyone who has to decide what something does, not how it does it.

This tool does have some rough edges here and there, but it’s a fantastic example of where things are headed and also what’s possible today.

Visual Application Development Scorecard

So how do tools like this measure up to our earlier criteria? And what are the pros & cons when compared to something like Web Components?

Functionality? – For functionality these do remarkably well, allowing us to create most of the utility common to our products. Web Components likely score a bit higher since they’re an open system that allows any functionality to be added - but at the cost of having to do more abstract work to accomplish this.

Data? – The best of these tools are data intelligent and capable. Allowing us to pre-load, create, and manipulate data persistently.

Reuse? – Reuse is a bit of a mixed bag, depending on your needs. These tools do include most of the building blocks you’re likely to need to create your prototypes, but you’re limited to the curated set they provide. Most don’t allow you to import components from other sources and the elements you create yourself are often limited to the project they were created within.

Deployable? – Being web based, these tools are pretty easy to deploy, with some having deployment to native devices baked in. One factor, that may be a pro or a con depending on your needs, is that many of them require you to host your prototypes on their infrastructure. This makes deployment easy but sometimes a little less flexible.

Direct? – Direct manipulation of what you’re creating is where these tools really shine. Tools like Bubble are setting a great example of what’s possible here, encouraging quick sketching of interactive elements and translating programming concepts outside the realm of development.

Multi-device? – As for creating multi-device designs, these tools vary. Like many recent prototyping tools, many of them seem to focus on small screen design exclusively. Thankfully, the better of the bunch also afford creating designs that are responsive or adaptive.

The Real, Possible Today

So, between robust new technologies, like Web Components, and increasingly sophisticated visual tools, like Bubble, we the ability today to create prototypes that feel like living, breathing applications. Pretty cool.

We do this to see the ways our audience actually uses our products so we can base our choices on reality. Once our designs are out in the wild, how can we go about actually observing that real-world behavior?

Observation Tools

Thankfully there’s already a lot of people interested in knowing how others use their products - which means there are quite a few tools available to do this. All we need to be able to do is hook them up to our functional prototypes.

To determine what tools are the best fit, we need to consider on what types of devices the behavior is occurring and what we want to observe.

For our purposes we want to observe if and how our products are being used.

The answer to ‘if’ is pretty much ‘yes’ or ‘no’. To answer ‘how’ our products are being used we need to look at the what, when, and where of their use.

What features and views are being used and what are not? What kind of patterns of use do we see across a day, or weeks? What are the devices and locations that our products are being used within?

By learning more about each of these we can begin to properly understand why people use our products, which is the secret to designing them well.

Basic analytic tools, like those we’ve used on websites and products for the last decade, can help us answer much of this.

Additionally, new tools are cropping up that hold very true to the idea of ‘observation’ - allowing us to gain a much more accurate look at how people use our products.

Depending on their use, these screen-recording tools can range from impressive to straight-up creepy.

Would something like this be suitable for every case? Definitely not. There’s a lot of my real-world use I’d rather you didn’t observe. Many of our products are personal and the content within them even more so.

Could these tools be useful in some cases? Probably. If the situation makes observation socially acceptable, and we can make it clear to our audience what is being observed and why.

fin

Thanks for making it this far (or ambitiously scrolling to the end to see what treasures await).

This was a large whirlwind of information, but what it all boils down to the importance of basing our design decisions on actual behavior and realizing how we can build real things to make that possible.

I hope the ideas and tools touched upon here struck a chord for you and hopefully can lead to a positive impact on both the way you approach your work and the value you’re able to deliver through it.

More Information

I’ll be sharing more, practical information on implementing a value-led design process soon. Links to specific resources to help jump-start your learning of tools and likely some practical demos.

If you’re interested in knowing when this is available you can sign up to be notified at ValueLedDesign.com.

Join Conversation

These ideas are very much at the front of our minds as we work to continually improve the products we help create at FORM.

If you think they’re important as well and have any questions, complaints, or flattering remarks you’d like to share, please reach out, either by or thru the Twitter.

Thanks – Clayton