Ultimately, she compliments you on your distinguished taste in scones and gingerly rings up your items. “How about an espresso to go with it?” You happily agree.  

She then pauses, looks into the distance, and says robotically, “Define customer payment method.” For a moment, the words awkwardly dangle in the air. “Um, credit please,” you say, and she swivels the payment kiosk toward you.  

You soon exit the shop, thinking not about the dark chocolate cardamom scone wrapped snugly in your bag or the impressive mural that spanned the length of the well-renovated space. But how it got a little weird there at the end.    

Our choice of words can affect an experience, whether on or offline. In a digital product, “Define customer payment method” is known as microcopy (or UX copy). Microcopy refers to the small text snippets guiding a user through the experience. Instructions, buttons, dialogs, labels, and error messages are all examples of microcopy.    

It’s worth pointing out that microcopy is not content. Articles, posts, media and marketing messages are all examples of content. It is important for a designer to be knowledgeable about a product’s content, but they are not responsible for crafting it. 

Writing is designing   

As designers, we take to heart the brand guidelines for aspects of visual design like colors, fonts, and type styles. But strip any interface down to the barest, most important elements, and you’re left with words. Words themselves are often not given the attention they deserve by designers (and often product teams in general). I would argue that the shortlist of core brand guidelines should include guidelines on writing. 

Writing should be led by designers  

Of all product team members, UX Designers have the best vantage point to guide UX writing. Our distinct perspective is fueled by our knowledge of the product, our users’ needs, and our client’s business objectives. Therefore it is logical that we, the architects of the user’s experience, should be the primary wielders of the words that shape that experience. 

Designers should hone their writing skills 

Writing is not a skill UX and UI designers tend to focus on in their core training. This was certainly true for me. Through experience and instinct, my writing skills increased incrementally over the years. In hindsight, this slow and steady progression could have been fast-tracked with just a bit of time and energy spent consciously building these skills. I recommend that designers of all levels do just this.  

I took a recent deep dive into various writing books and resources and wanted to share some of that knowledge. What follows are three fundamental principles for writing effective microcopy that I have found especially useful in my own writing. 

Editor’s Note: UX copy vs. UI copy: What’s the difference?

The line between UI copy and UX copy can be blurry. UI copy generally refers to the copy on interfaces, such as buttons and headers. UX copy relates more to informational text and help text — text that gives the user more context regarding the actions they can take and the results of those actions.  

1. Use plain language  

Writing in plain language ensures readers will gain a quick, clear understanding. Text written in plain language reduces the cognitive load on the user and allows them to focus on the task at hand. It is also a factor in accessibility. Plain language improves the experience of individuals with cognitive and learning disabilities. 

Above all else, be clear  

Messages should be straightforward and easily understandable. Period. This is plain language in a nutshell.  

Be concise  

Using fewer words can often simplify a message. Don’t use ten words when five will do — but don’t get carried away here! This does not mean that using fewer words is always better. Keep in mind the previous rule and make sure not to sacrifice clarity for the sake of brevity.  

Choose easy, informal words  

Reduce cognitive load by avoiding unnecessary jargon and complex terms. Deanna Horton’s Handy List of Human Words is a fantastic resource to help you trade fancy words for fast ones. 

Use short phrases and sentences  

These make for a quicker, more direct read. Simple as that. Nuff said. 

Write like you speak  

Keep it natural. Try reading your copy out loud and see if it sounds natural. Returning to our opening scenario, a more human alternative to the mechanical “Define customer payment method” might be, “How would you like to pay?”   

2. Be conversational  

Humans communicate with other humans through conversation. Humans communicate with computers through interfaces. Us humans have been communicating with one another for tens (hundreds?) of thousands of years. But it is only in our very recent history that we have begun communicating with computers. So we don’t totally know how to handle it yet.  

As Kinneret Yifrah points out in Microcopy: The Complete Guide, we “treat [our]computers according to the social norms we apply when communicating with other human beings.” Interfaces, therefore, should follow the rules of human conversations and abide by social norms.  

Know the context  

Through user research, you know a lot about your user’s overall needs, goals, and motivations. This is essential high-level knowledge. Being aware of their immediate situation is equally as important. You may know your user is overall very career-focused, so it might be a good idea to encourage them to connect their LinkedIn account. But you should also be aware that if the user is in the midst of recovering a lost password, now might not be the best time to prompt them to connect. 

When shaping your message, consider the user’s recent circumstances and what has brought them to this point in the experience. What are they trying to do? What are their expectations? What are they potentially thinking and feeling? A better understanding of the context of your user’s journey will help you better predict how to best communicate with them.   

Be cooperative & take turns  

In a good conversation, participants work toward a mutual goal: perhaps getting paperwork filled out before a doctor’s visit or something more indirect like filling the elevator with just enough conversation to make a short ride as least awkward as possible.  

Exchanges should be relatively even, not long, drawn-out monologues. Pause for understanding and feedback. Part of this is knowing how much information to provide at one given time and when to pause and listen for feedback.  

One option is to use progressive disclosure. Perhaps the user doesn’t need the ins and outs of why their email address is required, and you can provide a “why do we need this?” link should they want to know more.  

Use the active voice  

We tend not to use passive when we speak, just when we write. It’s also a way to ensure a sense of pace as the active voice feels more natural – more like a human conversation that we humans so irrationally expect from computers. 

Be polite  

Being polite does not just mean saying please and thank you. A genuinely polite interaction provides value, does not waste the user’s time, and provides options (especially for errors).  

Imagine you’ve ordered a coffee at a diner, and you’re told, “I am so sorry. There currently is no coffee. This must be very disappointing. Please accept our apologies.” While that response might be apologetic, it’s not exactly polite. It wastes your time, provides no useful information, and suggests no solution.  A better response might be, “Sorry, we’re out of coffee until tomorrow. How about tea?”  

A conversational design example 

Airbnb masters the art of conversational writing. Take a look at any property screen. It reads like a conversation you’re having during an in-person tour. “This is Where you’ll sleep… Here’s What this place offers… Things to know” The use of “you” invites the user right into the house.  

The property screen mentions something very human, which is the act of sleeping – Airbnb could have just as easily called it “Bedrooms.” 

3. Use your voice and tone

Let’s talk about who we represent on our side of the conversation. We speak for our client’s or employer’s brands. It could also be a sub-brand or an individual product’s brand. 

Your voice is consistent  

Think of your voice as your personality. Voice is determined in large part by your brand’s attributes/personality. At Big Nerd Ranch, our traits are things like Brave, Pioneering, and Seasoned. Your client should be able to furnish some documentation about their brand. If not, a workshop may be in order.  

Your tone changes based on context  

Tone conveys mood. If voice determines what you say, tone is how you say it. Tone should be adapted to fit the user’s circumstances and state of mind. The tone you employ while talking at a birthday party would (hopefully) be different than that you would use at a funeral. Likewise, the tone used while onboarding would differ from the tone of an error message.  

Check out this message from the Slack app, highlighting some recent feature changes. Slack describes its brand voice as human, clear, and concise. The tone is upbeat and informative.   

They nailed the delivery. “Two things!” You can imagine a coworker tapping you on the shoulder to relay a quick thought. Let’s check that “Human” checkbox on Slack’s list of brand traits. 

The informative sentence that follows is clear and concise, summarizing the updates in just nine words. The accompanying link is direct and phrased in plain language—it also offers the user additional information should they be interested. While Slack’s product team no doubt was tempted to list all of the other improvements they worked so hard on, they showed restraint in highlighting just two and tucked the rest away for more curious readers.   

It’s important to note the positioning of the message; It is positioned within the context of the features in question. Had the announcement been delivered outside of that context, in a modal or an email, for example, additional explanation or images may have been needed. 

One more thing. Let’s acknowledge the politeness of the message. It does not interrupt the user from going about their business, but perches atop the input field until the user acknowledges it.   

Editor’s Note: How much can you make UX copywriting?

Effective UX writing doesn’t just make you a better developer — it opens the exciting career path of technical writing. According to ZipRecruiter, the average UX copywriter makes more than $100,000 a year, with experienced UX content writers making over $150,000. Good UX writing is hard to come by and a critical part of the software design process.  

Tying it all together  

 Now that we have discussed three important principles of good UX writing: plain language, conversational writing, and voice and tone, let’s take a look at one last example and see if we can check the boxes on what we’ve learned. How does this final step in the Airbnb booking process rate?  

Plain language? Check. It’s clear, concise, and informal. It uses short phrases and sentences and avoids jargon.   

Conversational? Check. From the prompt, it’s clear how I’m to respond. It even has a suggested start to help get me on my way.   

Proper use of voice and tone? Check and check. “Straight-forward,” “Thoughtful,” and “Spirited” are some of Airbnb’s brand values, and all are represented in this example.  

Airbnb has earned itself an A+! 

Major bonus points!: Perhaps most importantly, Airbnb takes advantage of this interaction to accomplish goals important to both the users (both Traveler and Host) and to the business. In one of their posts, Airbnb mentions a couple of their company goals:  

• For Travelers to feel welcomed in a Host’s home   
• For Hosts to feel secure opening their homes to Travelers   

The copy nudges these two strangers into making a social connection, thereby encouraging a social relationship that benefits both the users and the business.  

Focus on writing! 

When written effectively, microcopy can make your designs more effective and the overall experience much more clear and enjoyable for your user. Keep in mind the three principles covered, take time to focus, and reap the rewards. 

Resources

Nielson Norman Group’s UX Writing Study Guide 

Microcopy: The Complete Guide by Kinneret Yifrah 

The post Writing is Designing: Three Principles for Writing Effective UX Copy  appeared first on Big Nerd Ranch.

Just a quick note, the last letter in a design pattern is where the business logic lies. It’s where you morph data. Others say it’s the “driver” of the application—it’s used to navigate the application. While the latter holds true for most patterns, there are outliers that make this false. We will look more into this below. But first, let’s jump into the four patterns we’ll be discussing today—MVP, MVC, MVVM, and MVVMC.

Model-View-Presenter (MVP)

Although it may seem like MVP is the most valuable (slow clap), it is rarely used these days since it’s been replaced by more robust and testable design patterns. In MVP, the presentation layer (the layer with all the awesome-looking controls) is where the business logic lies. In .NET an MVP pattern is commonly used in Windows Forms. The presentation’s code behind is in charge of most of the business logic. As you can see, oftentimes the View sits in the presentation layer, so this design can be redundant.

While this is great in small projects, unit testing is almost impossible since you have to spin up the application to test any logic. Mocking data is possible, but automating unit testing is not (or not easily possible without doing some major overhauling of the structure. Most of your tests will have to rely on reading data that may be formatted for the presentation layer, which may result in more assertions and more data conversions to test your application.

Model-View-Controller (MVC)

If you have worked in .NET web applications, you may have run across the MVC pattern. While this is not a true MVC pattern, it does hold many characteristics of MVC. In MVC, you have a Controller, a View, and a Model. The Controller is exactly that—a controller. It controls the business logic and navigation. The Model (a.k.a. a Data Transport Object, or DTO) is introduced here and is used to transport data from the data source to the View. The View binds to the model and displays what the model contains in a user-readable way.

There are a number of advantages this pattern has over its predecessor – MVP. You can now mock the data source and fill the Models with data without using a hard data source. With this, you can now test your domain (where all the magic happens) without running the application. This is good news in the automation world where you build and test your application in an automated build. The builds can not only test your application without running it, but it can also run multiple tests in parallel.

Model-View-ViewModel (MVVM)

If you have worked with Windows Presentation Foundation (WPF), then you have at least heard of the MVVM pattern. The MVVM pattern is very similar to MVC (after all, it manifested from MVC), except there are some differences. MVVM uses a shared (or portable) domain. Meaning that the domain can be placed in several front ends, or presentation layers. It also has multiple data stores.

In the beginning, MVVM was used to share your domain in Windows Desktop, Windows Phone, and Windows Apps. Since the developer only had to develop and test the domain once for each type of device, it saved a lot of time in development and testing. Much like the controller in MVC, The ViewModel is at the heart of the design. It contains the business logic and controls how the data moves in and out of the application. Also, much like the controller, the ViewModel sends and receives data with the use of a Model. However, the ViewModel (unlike the Controller) also holds properties the View will bind to. It does not pass a Model to the View, instead, the View binds to the ViewModel. Because of this, the View can now retrieve real-time updates from the ViewModel. All while keeping a separation between the View and the ViewModel.

Since Microsoft abandoned the beloved Windows Phone and increased the portability of Windows Apps, MVVM has changed over the years from a portable domain that can be used in Silverlight Applications, Windows Phone Applications, Desktop Applications, and Windows Apps to more of a power design pattern use to rely on data-binding to the View while keeping the separation between the layers—all while allowing unit tests and build automation. You can see why it is still used today.

Model-View-ViewModel-Controller (MVVMC)

While this pattern looks very confusing, it’s a pattern used very frequently in the ASP.NET MVC space. Instead of binding the View to a Model that comes from a database, the controller will take many models and combine them into a ViewModel. The View will then bind to the ViewModel. The ViewModel will not have real-time updates from the controller like in MVVM, but it will ease the pain of dealing with multiple Models in a View.

There is no real advantage as far as testing goes with this pattern. The Models are still used to transport data to and from the data source. The advantage strictly deals with the Presentation layer of the application.

Which Design Pattern Do You Choose?

While the world remains heavily invested in web technologies, there is (and always will be) a place for native applications. Knowing what design pattern to use is just as crucial as using the design pattern correctly:

• MVP is appropriate for very small applications that do not require unit testing or where scalability is minimal.
• MVC is appropriate for applications that usually have one front end, and run on one platform, such as small enterprise applications. This pattern is also used widely in the webspace.
• MVVM is appropriate for large, complex enterprise applications that require unit testing and real-time updates to the front end.
• MVVMC is used in applications where multiple models are combined for use in the Presentation Layer. This pattern is also used alongside the MVC pattern.

There is more to these design patterns as well as design pattern infrastructure than this post covers – such as Dependency Injection, Mocking, Automated Builds, and Automated Testing. I felt it was out of scope. This article aims to contextualize the common design patterns you will come across when working with .NET.

The post Which .NET Design Pattern is Best For Your Next Project appeared first on Big Nerd Ranch.

This blog post will be exploring these questions by building a design system with Stencil.js. The design system will support white-labeling via CSS Variables. Then the design system will be used without a framework, and with the React, Vue, Svelte, and Stencil frameworks.

Stencil is a compiler for web components that can build custom elements for use across multiple frameworks. The compatibility of custom elements with various frameworks is tracked by Custom Elements Everywhere.

The code for this blog can be found on GitHub at https://github.com/BNR-Developer-Sandbox/BNR-blog-stencil-design-system.

Building the Components

Each component encapsulates its own CSS and functionality. Developers wanting to publish a web component library can follow the Getting started guide for Stencil. The Stencil API provides decorators and lifecycle hooks to reduce boilerplate code and define implementation patterns.

Stencil Decorators

The Stencil API provides a number of decorators that are removed at compile time.

Each Stencil Component uses the @Component() decorator to declare a new web component defining the tag, styleUrl, and if the Shadow DOM should be used or not.

@Component({
  tag: "ds-form",
  styleUrl: "ds-form.css",
  shadow: true,
})

Lifecycle Hooks

The Stencil API also provides various lifecycle hooks. The only lifecycle hook used in this codebase is the render() method which uses JSX to return a tree of components to render at runtime.

Application Shell

The ds-shell component provides a header, main, and footer section available via slots. The header and footer slots are named slots, while the main content area uses the default unnamed slot. This component provides the general layout for an application.

import { Component, Host, h } from "@stencil/core";

@Component({
  tag: "ds-shell",
  styleUrl: "ds-shell.css",
  shadow: true,
})
export class DsShell {
  render() {
    return (
      <Host>
        <header>
          <slot name="header"></slot>
        </header>
        <main>
          <slot></slot>
        </main>
        <footer>
          <slot name="footer"></slot>
        </footer>
      </Host>
    );
  }
}

Hero

The ds-hero component provides a default slot container and encapsulates the CSS for the component.

import { Component, Host, h } from "@stencil/core";

@Component({
  tag: "ds-hero",
  styleUrl: "ds-hero.css",
  shadow: true,
})
export class DsHero {
  render() {
    return (
      <Host>
        <slot></slot>
      </Host>
    );
  }
}

Form

The ds-form component provides generic form handling by listening for input, change, and click events that bubble up to the form element. The component uses the @Element() decorator to declare a reference to the host element in order to dispatch the formdata event from the host element when the form is submitted. The component also uses the @State() decorator to declare the internal state of the form data.

import { Component, Element, Host, State, h } from "@stencil/core";

@Component({
  tag: "ds-form",
  styleUrl: "ds-form.css",
  shadow: true,
})
export class DsForm {
  @Element() el: HTMLElement;
  @State() data: any = {};
  onInput(event) {
    const { name, value } = event.target;
    this.data[name] = value;
  }
  onChange(event) {
    const { name, value } = event.target;
    this.data[name] = value;
  }
  onClick(event) {
    if (event?.target?.type === "submit") {
      const formData = new FormData();
      Object.entries(this.data).forEach(([key, value]) => {
        formData.append(key, String(value));
      });
      const formDataEvent = new FormDataEvent("formdata", { formData });
      this.el.dispatchEvent(formDataEvent);
    }
  }
  render() {
    return (
      <Host>
        <form
          // form event
          onInput={(event) => this.onInput(event)}
          onChange={(event) => this.onChange(event)}
          onClick={(event) => this.onClick(event)}
        >
          <slot></slot>
        </form>
      </Host>
    );
  }
}

White-labeling the components

In order to implement white-labeling, CSS Variables are used in the components which can be set by the design system consumer. The example repository only sets three variables to illustrate the idea; a complete design system would likely include more variables including sizes, fonts, etc.

Each application defines CSS Variables to implement a different brand.

:root {
  /* CSS Variables for theming white-labeled components */
  --primary-color: red;
  --secondary-color: gold;
  --tertiary-color: green;
}

Each application also defines a simple CSS Reset.

body {
  margin: 0;
  background-color: var(--tertiary-color);
}

Consuming the components

While consuming the custom elements the same HTML structure was used in each framework. Each example application implemented in each framework composes the ds-shell component for application layout, with a ds-hero to provide a call-to-action content area, and a unique form and form handler to process the form.

<ds-shell>
  <h1 slot="header">App Name</h1>
  <ds-hero>
    <ds-form>
      <label>
        Your Name:
        <br />
        <input type="text" name="name" />
      </label>
      <br />
      <label>
        Your Expertise:
        <br />
        <input type="text" name="expertise" />
      </label>
      <br />
      <input type="submit" value="Say Hello" />
    </ds-form>
  </ds-hero>
  <span slot="footer">
    <span>1</span>
    <span>2</span>
    <span>3</span>
  </span>
</ds-shell>

Event binding

The main difference between frameworks was binding the formdata event. Each framework has a slightly different syntax for declaring event handlers. The following examples demonstrate the event binding syntax for each framework.

Without a Framework

The Design System includes an implementation of the application without a framework in index.html. CSS Variables are defined in a <style> tag in the <head> tag. The event listener is added in a <script> tag at the end of the <body> tag.

<!DOCTYPE html>
<html dir="ltr" lang="en">
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=5.0"
    />
    <title>Design System</title>

    <script type="module" src="/build/design-system.esm.js"></script>
    <script nomodule src="/build/design-system.js"></script>
    <style type="text/css">
      :root {
        /* CSS Variables for theming white-labeled components */
        --primary-color: red;
        --secondary-color: gold;
        --tertiary-color: green;
      }

      body {
        margin: 0;
        background-color: var(--tertiary-color);
      }
    </style>
  </head>
  <body>
    <ds-shell>
      <h1 slot="header">App Name</h1>
      <ds-hero>
        <ds-form>
          <label>
            Your Name:
            <br />
            <input type="text" name="name" />
          </label>
          <br />
          <label>
            Your Expertise:
            <br />
            <input type="text" name="expertise" />
          </label>
          <br />
          <input type="submit" value="Say Hello" />
        </ds-form>
      </ds-hero>
      <span slot="footer">
        <span>1</span>
        <span>2</span>
        <span>3</span>
      </span>
    </ds-shell>

    <script>
      function handleFormData(event) {
        event.stopPropagation();
        const { formData } = event;
        const data = Object.fromEntries(formData);
        const { name, expertise } = data;
        alert(`Hello ${name}, I hear you are good at ${expertise}.`);
      }

      const form = document.getElementsByTagName("ds-form")[0];
      form.addEventListener("formdata", (event) => handleFormData(event));
    </script>
  </body>
</html>

In order to add the event listener without a framework the native addEventListener method is used.

form.addEventListener("formdata", (event) => handleFormData(event));

React

The React application is implemented in App.js with CSS Variables in index.css.

import "design-system/ds-shell";
import "design-system/ds-hero";
import "design-system/ds-form";

function handleFormData(event) {
  event.stopPropagation();
  const { formData } = event;
  const data = Object.fromEntries(formData);
  const { reaction } = data;
  alert(`I am surprised that you reacted ${reaction}.`);
}

function App() {
  return (
    <ds-shell>
      <h1 slot="header">React App</h1>
      <ds-hero>
        <ds-form onformdata={(event) => handleFormData(event)}>
          <label>
            How did you react?:
            <br />
            <input type="text" name="reaction" />
          </label>
          <br />
          <input type="submit" value="What is your reaction?" />
        </ds-form>
      </ds-hero>
      <span slot="footer">
        <span>1</span>
        <span>2</span>
        <span>3</span>
      </span>
    </ds-shell>
  );
}

export default App;

React uses a lowercase onformdata attribute in JSX to bind the formdata event to a handler.

<ds-form onformdata={(event) => handleFormData(event)}>
  <!-- ... -->
</ds-form>

Vue

The Vue application is implemented in App.vue with CSS Variables in base.css.

<script setup>
  import "design-system/ds-shell";
  import "design-system/ds-hero";
  import "design-system/ds-form";

  function handleFormData(event) {
    event.stopPropagation();
    const { formData } = event;
    const data = Object.fromEntries(formData);
    const { view } = data;
    alert(`${view}!?! Wow! What a view!`);
  }
</script>

<template>
  <ds-shell>
    <h1 slot="header">Vue App</h1>
    <ds-hero>
      <ds-form @formdata="handleFormData">
        <label>
          How's the view?:
          <br />
          <input type="text" name="view" />
        </label>
        <br />
        <input type="submit" value="Looking good?" />
      </ds-form>
    </ds-hero>
    <span slot="footer">
      <span>1</span>
      <span>2</span>
      <span>3</span>
    </span>
  </ds-shell>
</template>

<style>
  @import "@/assets/base.css";
</style>

Vue uses a lowercase @formdata attribute set to the function name to bind the formdata event to a handler.

<ds-form onformdata={(event) => handleFormData(event)}>
  <!-- ... -->
</ds-form>

Svelte

The Svelte application defines application variables and the form handler in main.js.

import App from "./App.svelte";

const app = new App({
  target: document.body,
  props: {
    appName: "Svelte App",
    fieldLabel: "Your Location",
    fieldName: "location",
    submitLabel: "Where you at?",
    handleFormData: (event) => {
      event.stopPropagation();
      const { formData } = event;
      const data = Object.fromEntries(formData);
      const { location } = data;
      alert(`Where's ${location}?`);
    },
  },
});

export default app;

App.svelte uses the variables from main.js to render HTML and bind events.

<script>
  export let appName, fieldLabel, fieldName, submitLabel, handleFormData;
  import "design-system/ds-shell";
  import "design-system/ds-hero";
  import "design-system/ds-form";
</script>

<ds-shell>
  <h1 slot="header">{appName}</h1>
  <ds-hero>
    <ds-form on:formdata="{handleFormData}">
      <label>
        {fieldLabel}:
        <br />
        <input type="text" name="{fieldName}" />
      </label>
      <br />
      <input type="submit" value="{submitLabel}" />
    </ds-form>
  </ds-hero>
  <span slot="footer">
    <span>1</span>
    <span>2</span>
    <span>3</span>
  </span>
</ds-shell>

The CSS Variables are defined in global.css.

Svelte uses a lowercase on:formdata attribute to bind the formdata event to a handler.

<ds-form on:formdata="{handleFormData}">
  <!-- ... -->
</ds-form>

Stencil

The Stencil application is implemented in app-root.tsx with CSS Variables in app.css.

import { Component, h } from "@stencil/core";
import "design-system/ds-shell";
import "design-system/ds-hero";
import "design-system/ds-form";

@Component({
  tag: "app-root",
  styleUrl: "app-root.css",
  shadow: true,
})
export class AppRoot {
  handleFormData(event) {
    event.stopPropagation();
    const { formData } = event;
    const data = Object.fromEntries(formData);
    const { expertise } = data;
    alert(`So you are good with ${expertise}...`);
  }
  render() {
    return (
      <ds-shell>
        <h1 slot="header">Stencil App</h1>
        <ds-hero>
          <ds-form onFormData={(event) => this.handleFormData(event)}>
            <label>
              Your Expertise:
              <br />
              <input type="text" name="expertise" />
            </label>
            <br />
            <input type="submit" value="Say Something" />
          </ds-form>
        </ds-hero>
        <span slot="footer">
          <span>1</span>
          <span>2</span>
          <span>3</span>
        </span>
      </ds-shell>
    );
  }
}

Stencil uses a camel case onFormData attribute to bind the formdata event to a handler.

<ds-form onFormData={(event) => this.handleFormData(event)}>
  <!-- -->
</ds-form>

Conclusions

Building web components allows developers to reuse UI elements in multiple frameworks. Starting with a design system, developers are able to develop a basic app shell in React, Vue, Svelte, and Stencil. The compatibility within frameworks is tracked by Custom Elements Everywhere. The application for each framework had different ways to handle events but each project handled imports, html, and CSS similarly. A properly configured Stencil project can be used to publish a component library that is consumed by developers across multiple frameworks.

Event Bindings

The main difference is how events are bound to handlers in each framework.

Without a framework use addEventListener(). In React use onformdata to listen for formdata events. In Vue use the @formdata shorthand or v-on:formdata to listen for events. In Svelte use on:formdata to declare a handler for formdata events. In Stencil use onFormData in order to handle events published by components.

The post Building a Design System and Consuming it in Multiple Frameworks using Stencil.js appeared first on Big Nerd Ranch.

Take Agile and Design Thinking. While these terms might be thrown around fairly casually, there is still real value to what they represent—and how they can be used together. And maybe that comes as a surprise, but thinking about Agile versus Design Thinking is the wrong way to approach things since they aren’t at odds at all. In fact, they work amazingly well. 

Before we get into that dynamic duo, let’s break down what the terms mean and how they are different. 

The Difference Between Design Thinking and Agile

Agile is the How

Agile development is, by its nature, a product development process that is focused on getting a product out the door as quickly as possible, with the idea of improving through incremental improvements after launch. The advantage of the agile method is that the users get a well-built product that they can begin using almost immediately—with the assumption being that there will be iterations down the road. 

Problems occur when the focus is more on those iterations and not on the impact the updates have on the overall customer experience. 

Design Thinking is the Why 

Design Thinking, on the other hand, typically begins before any code is written and the Agile process even enters the picture. It begins by having a diverse team of designers, developers, strategists—really anyone related to the project—sit down and think about the needs of the user first and foremost. 

That’s where the “why” comes into play. The main goal of Design Thinking is to generate as many and varied solutions to the problem at hand and then refine them until the users’ needs are addressed. And, as we mentioned, Design Thinking is for the whole team, not just designers. The whole beauty of the process is that it brings in a wide range of opinions and ideas. 

Think of Agile as the way you fix something and Design Thinking as the tools you use to get the final product. 

Understand not Just the Idea, but Where it Comes From as Well

To get the best from both, it’s probably best to not think of Agile and Design Thinking as sitting on either side of a divide. In fact, they can not just work simultaneously, but they can actually work together. Often to fantastic results. 

Start the Process with Design Thinking

The best digital products are those that find a healthy overlap of meeting business goals and providing the users with the best experience possible. This is where Design Thinking comes into play. 

Design Thinking starts by better understanding users’ challenges and then coming up with the best solutions for those issues. By bringing Design Thinking into the process early on, you’re setting your digital product up for success. And, perhaps more importantly, you’re ensuring that your design and development team is running smoothly—according to IBM, a “design thinking approach can reduce the time for development and testing by as much as 33 percent.” 

That reduction in time is largely due to the fact that Design Thinking brings up and, hopefully, answers the vast majority of questions a project might encounter before any work is actually done. That means a well-built and user-focused product that is delivered quickly. Happy users. Happy client. 

Remain Agile with, well, Agile

When done well, the Agile development process is an innovative solution that allows for teams to move quickly, adjust on the fly, and produce a quality product that can meet customer needs in a timely matter. When considered in the realm of Design Thinking, Agile allows for teams to take all of the information gathered through the Design Thinking process and created a scaled Agile framework that can be applied to the actual development and design of the product. 

The upshot is that while Design Thinking is providing the answers to all the questions, Agile is there to keep the guardrails on the project, ensuring that deadlines are met and clients are happy. 

As Always, Collaboration is Key

The absolute best-case scenario is that both Design Thinking and Agile work beautifully together as a cross-functional team and everyone is happy. And that’s achievable! But, it does require work. 

Throughout the entire development process of a digital product, all parties involved have to have clear communication and the willingness to listen. From the Design Thinking side of things that means clearly stating the user’s problems and possible solutions while being open to any changes that naturally occur during the process. From the Agile perspective, the teams working on the actual product need to meet the expected requirements while also keeping in mind the end user’s experience. It’s not easy, but great things never are. 

That’s where we come in. At the Ranch, we are lucky to have experts in both Design Thinking and Agile Development. Our teams have been working within both processes from the start and relish any and all new opportunities to continue to evolve how we go about things. So, if you’re in need of an amazingly well-built digital product that will surprise and delight your users, get in touch! 

Source:

IBM’s Agile, meet design thinking

The post Design Thinking vs Agile appeared first on Big Nerd Ranch.

If your legacy application is the older house on the block then application modernization is a much-needed remodeling. 

In the same way that you wouldn’t completely demolish a house that has good bones, you shouldn’t completely get rid of your existing applications, especially one that you’ve probably already invested in both financially and structurally.

What is Application Modernization 

Application modernization is the best way for companies to revamp their legacy applications for modern times without having to start completely over. Application modernization takes a legacy application and revamps it by updating its software for newer computing approaches. These approaches include modern languages, updated frameworks, and infrastructure platforms.

Why You Need It 

Two words: money and time. You’ve already spent both building out your existing application and it’d be a shame to have to completely start over. With application modernization, you don’t ever have to.

With application modernization, your company is able to keep the most critical application up-to-date by implementing new structures and frameworks, without having to build an all-new app. It’s also a great opportunity to implement any accessibility features that you might have left out of the original version. 

Beyond the purely technical side of things, taking a renewed look at your app allows you to reconsider any design elements that might be outdated. Not only will your app look great, but it will be much more user-friendly. 

How to actually use application modernization

There are many reasons why you might want to use application modernization and luckily, there are also many ways to use application modernization depending on your goals. The three main ways to use application modernization are lift and shift, refactoring, and re-platforming. Let’s dig deeper into each of these.

Lift and Shift

Lift and shift, otherwise known as rehosting is the process of taking an existing application and moving it to a newer infrastructure, such as a public cloud platform. The application itself doesn’t change, only its platform.

This can be a good option for you and your company for a number of reasons. Moving your existing application to a new platform, such as a cloud platform can help keep your business agile and in with the times. It can also help keep your business focused since there is no need to worry about system administration and ultimately it can help cut costs.

Refactoring 

The second option is refactoring or rewriting the application. This process involves taking the legacy application and rewriting a large portion of the underlying code to help the application run in a new environment such as cloud infrastructure.

Refactoring is a great choice for those with a single application that wish to break into smaller pieces, also known as microservices. It’s also a great way (or, the only way) of digging yourself out of tech debt—something that often and unfortunately comes along with legacy apps. 

Replatforming

The last option for application modernization is one that sits in between lift and shift and refactoring. This third option is known as re-platforming. Replatforming is the process of utilizing complementary updates that enables the legacy application to take advantage of a modern cloud platform.

You Have the Idea, We Have the Way. 

Now that you have a good understanding of application modernization, you’re probably wondering how to get started. We’ve got you covered. Whether you want to learn how to navigate an unknown bit of software or a different design perspective, we’ve got a team of Embedded Experts ready to help. Ready to get started? Get in touch and let’s chat! 

The post What Is Application Modernization? appeared first on Big Nerd Ranch.

You’ve done it. After months (or years) of dedicated hard work, you’ve launched your amazing new digital product out into the world. Or maybe you’ve added some amazing new features to your existing app and they are finally ready to see the light of day. Now, it’s time to sit back and let the good times roll, right? 

Since you’re here, we’re guessing you know the answer to that. We’re now to the point that just having a great digital product isn’t enough. To make things even more complicated, your company has to be in tune with your users, ensuring that you’re providing not just the experience that they want, but the one that they need. 

That’s where Customer Experience comes into the mix. But how can Customer Experience help your digital product, and by extension, your brand, stand out from the competition? 

Continuous Improvement of the Things That Matter

At its heart, Customer Experience is about listening to your users. It’s about looking at the breadth of their interactions with your product and brand and learning what is important to them, what’s working with your app, and what needs to change. This could be anything from “the colors make it hard to read the text” to “I really wish you’d add the ability to share a form with my teammates.” 

In essence, you’re getting the upper hand on your competitors from literally the most important source in the world—the actual users of your digital product. As you incorporate that feedback, you can do so knowing that you’re not just adding features or functionality for the sake of adding them but focusing on the things that will make a better experience for your users. 

So, listen, build, repeat. This is called a critical feedback loop, though we like to refer to it as the Awesome Feedback Loop because the result is a digital product that is user-focused and, most importantly, one that stands out from the crowd. 

Happier Users + More Users

Once you’re well into the Awesome Feedback Loop, you’ll ideally see a couple of things begin to happen. The first is that your current users will go from being customers to being fans. And why not? Everyone loves being heard, but seeing that feedback put into action takes that relationship to the next level. 

The second great thing is that you’ll find that your app is attracting a whole new customer base. In part because the changes, updates, and other bells & whistles you’ve put into place for your current customers are probably the same ones that new users have been craving. Also, your customers turned fans are going to talk and share their great experience with others. 

Bottom Line? A Better Bottom Line.

Following through on a successful Customer Experience project can, in the best case, create super fans of your current users and bring in new customers at a brisk pace. But even if the best case is still a ways off, you’ll have a digital product that keeps getting better as you continue to listen and respond. It’s a win for your company, and, most importantly, it’s a win for your users. 

And that highlights the real benefit of bringing Customer Experience to your company—you’ll find that the decisions you make for your business are inherently those that are best for your users. It’s a mindset as much as a process. As a digital product development agency, we can help bring your ideas to life.

It’s Time to Tap Into the Awesome Feedback Loop

All of this might seem daunting, but don’t worry, we’re here to help. We’ve got a crack team of Customer Experience experts ready to help you help your users. So, if you’re ready to get started on your next project or would like to just chat about how you might begin, be sure to give us a shout. 

The post A Great Digital Product Isn’t Enough Anymore appeared first on Big Nerd Ranch.

Have you ever been in a building that’s had several additions to it and the whole layout just seems confusing? Sure, all the types of rooms you need are there, but the flow is way off, and the door labeled “restroom” leads to a closet? It feels wrong and leads you to places you least expect. 

That’s your app with a healthy dose of design debt. The look and feel are off and the provided information doesn’t quite line up with what’s expected. But don’t fret, we’re here to help. 

We’ll take a look at the two major components of the UI and UX of your app—Visual Language and Information Architecture—and then walk through how to best dig out of that nasty debt. Finally, we’ll take a look at some steps to best avoid design debt in the future.

Visual Language and Information Architecture

Visual Language

The very first thing a user notices about your app is the look and feel of it. Now, we can talk all day about User Experience (UX) and how vitally important it is (and, it is!), but the visual identity, or language, is the first impression. 

Visual language describes all the things a user sees when they first open your app. So, not just your color scheme and font choice, but the size of your navbar and how rounded your buttons are. Having a consistent visual language is vital for an app, not just because it looks great, but because it helps the user navigate. If all the buttons to submit information are the same then the expectation for what those buttons do is clear at a glance.   

Often, a lack of visual consistency is the first sign of design debt. Maybe buttons don’t match a style or font sizes are all over the place and vary by 1-2pts. Basically, it looks like a cobbled together app with several styles thrown together. 

But having a clear visual language isn’t always enough. In fact, a strong visual consistency can actually mask some more deep-rooted UX Design Debt issues like poor information architecture. 

Information Architecture

In essence, Information Architecture (IA) is the practice of organizing, structuring, and labeling content in a way that allows your user to know where they’ve been, where they are, and where they are going in your app. So, it’s not just that your buttons are located where they should be, it’s that the text on them is clear and expected as well. 

When IA is done well, your users have a clear sense of the path they should take to achieve their goals. For example, if someone is ordering food through an app, they would rightly expect the menu button to take them to the menu. 

If the menu button instead takes them to the location address, that’s a problem. Poor Information Architecture can unintentionally hide important features, confuse your users, and, ultimately, lead those same users to abandon your app altogether.  

So now that we’ve talked about all the things that can go wrong, how do we fix it all?

Digging Out of Debt

To best work yourself out of debt, you first have to find all the issues you can and then begin solving them. 

Step 1: Design Audit

A design audit looks at both the visual elements of your app and how the information is presented. The end result is an analysis of the overall user experience that identifies visual inconsistencies and pain points while offering suggestions for a way forward. 

In practice, an audit will help you further define your app’s experience so that your users get the most out of their interactions. That means you’ll get guidance for visual style, color, and typography to ensure that the look and feel of your app is consistent throughout. You also get a list of critical usability flaws, the type that can be actual blockers to your app’s success. 

Finally, a design audit will take a hard look at your IA and determine what’s clear and what needs some help. Is all your labeling accurate? When you click a button that says “Contact Us” are you taken to a form or another, random page? 

Now that we’ve got the list, it’s time to start the clean-up. 

Step 2: Reduce, reuse, recycle 

The good news about cleaning up design debt is that we rarely have to start all over. In fact, one of the best ways to pay down design debt is by recycling previously used content, components, and visuals, a concept best illustrated through Cradle-to-Cradle Design. In a nutshell, Cradle-to-Cradle Design is the concept of taking a product that is no longer useful or wanted, breaking it down into its essential parts and using those parts to build something new.  

This is most often seen in physical products, like an electric toothbrush. We can take all the individual parts of the toothbrush—the tiny wires, springs, and motor—and break them down, reconfigure them, and then repurpose them in a new toothbrush. But how do we do that in a digital product? 

For this example, let’s consider an app designed to create and submit forms while also allowing team members to collaborate using that shared information. We’ll start with our main navigation bar—the same navbar that you’ve been iterating on, adding content to, and implementing new features in for the past three years.  Now, your navigation bar is bloated. 

Let’s start by breaking down our navbar into its individual components, both from a visual and content standpoint. It’s an easy lift to get our color scheme set and make sure our fonts are consistent, so let’s move to the content. 

In looking at our ‘reports’ and ‘teams’ tabs, we can take a step back and try to find new connections that allow us to reorganize and restructure. Maybe we now understand that the most important feature to know about our team is how their reports are connected to one another. So let’s merge teams and reports together and see what that looks like. 

Now it’s clear where your users should go to both create and share reports with one another. We’ve eliminated a step and cleared up any possible confusion with our IA. 

How to Avoid Design Debt

Unfortunately, there’s no way to completely avoid acquiring any debt, but there are things you can do that will ensure you and your team avoid the vast majority. Put simply, it comes down to planning. 

Start by making sure your project team is set up for success by creating a single source of truth for all things visual—things like button styles and font usage. It’s important the entire team has access to the style guide and usage documentation so that everyone on the team has the information they need to check where simple styling inconsistencies may show up. 

Second, focus on your Information Architecture. Make sure that you’ve put the time in to discover how your customers will use your app and what they expect from it. A lot of this context comes from an in-depth Customer Experience project and will help you make the best decisions possible in regards to how your information is laid out. 

BNR—The Debt Erasers

If all this seems daunting, don’t worry, you’ve got support. From a Big Nerd Ranch Design Audit to a full-blow Customer Experience project, we’re here to help dig you out of debt and, best case, start you on the right path before any accumulation even begins. Get in touch and let’s get started. 

The post How to Best Manage Design Debt appeared first on Big Nerd Ranch.

How can you include accessibility in your app?

Think about accessibility before the build even begins 

Have you ever seen a building that had a wheelchair ramp added as an afterthought? Think of an all green building with a random red ramp. It looks messy and forced, right? It looks like it’s not supposed to be a part of the building. Adding in accessibility to your app after you’ve finished has the same look to it. So how do you avoid that? 

The best way is to consider the accessibility aspects of your app before you start. This means that accessibility for as many users as possible must be a forethought when creating your app. Ways to make it easier for all people to use your application have to be thought about before the building process even begins and definitely not after. Considering all types of users in your design will allow for a smoother design process and a better-looking design.

Avoid bad design at all costs.

Including accessibility in your application is the right choice, but it needs to be done correctly. Here’s a little secret: people don’t like bad design. Bad design is painfully noticeable. And bad design is usually what happens when accessibility isn’t thought about until after the application is already built (it’s also a way to build up some nasty design debt). Avoid it at all costs by simply including accessibility in the planning process because people will notice. Accessibility doesn’t have to be clunky and awkward. Good design is seamless and accessible technology should be, too.

For the basics on getting started with accessible design, check out Learn the Basics of Accessible Design. 

Understand that accessibility is not one size fits all.

There are a few concepts to consider when planning for accessibility technology. Accessible technologies work across a wide range of differing abilities and work to accommodate as many people as possible. That means it needs to be thought about every step of the way, from text size to application colors. 

Give users the option to enlarge text. This will make your app easier to use for all people, especially for blind or visually impaired individuals. Additionally, a voice-to-text option is very helpful for those who are deaf or hard of hearing but will also benefit a person on the go. Captions are beneficial for those who struggle with hearing but also make for a more enjoyable viewing experience for all people. 

Why is Accessibility so important? 

Accessibility means opening your app to as many people as possible.

So now you know that accessibility means making your application available to as many people as possible. But maybe you still need more convincing on why you should include accessibility in your app. Not a problem. 

For starters, consider that accessibility is a critical aspect of universal design. Universal design is the design of products and environments to be usable by all people to the greatest extent possible without adaptations and special design.  The fact of the matter is that 1 in 4 Americans has a disability. So, including accessibility is not just the right thing to do, but it also opens you up to a whole new customer base. 

Accessibility makes for a great customer experience.

The beauty of accessibility is that each user can interact with your application in the way that works best for them. Remember, first impressions are everything. Once users click out of your application, you want to make sure you did everything in your power to ensure they come back. How do you get users to keep coming back to your application? Great question. 

The answer is simple: excellent customer experience. Customers don’t want to feel frustrated when using your application, and by not including aspects that make for a great customer experience such as accessibility, many customers will be left feeling very disappointed when they cannot use your application correctly and are going to take their business elsewhere. Avoid losing customers by simply keeping customers happy. Keep customers happy by making your application user-friendly for all people.

There is literally money at stake 

Title II and Title III of the ADA requires that software, websites, and apps be accessible to as many people as possible. Not following those guidelines? That could end up literally costing your company money paid out in fines. 

Additionally, if your app leaves out an entire customer base or makes tasks more difficult for certain employees, you’re losing money, both from potential clients and from the time spent having to create workarounds. 

It’s the right thing to do

Bottom line – accessible technology is key for creating a more equitable society and that’s some good stuff for all of us. There’s also a really good chance that you’ll find that the more thoughtful you are about how you build your apps from an accessibility standpoint will translate to being more thoughtful about how you approach different parts of your business.  

Now that you have an understanding of why accessibility is essential and how to get started with accessibility in your app, you may be wondering how you can begin to implement it with actionable steps. Give us a shout and we’ll be happy to talk through all the ins and outs of what makes for a well-built app for everyone.                                                                                                                                                                                                                                 

Resources

https://sopa.tulane.edu/blog/why-accessible-technology-important

https://it.wisc.edu/learn/guides/accessible-content-tech/what-is-accessible-technology/

The post Why Accessibility in Tech is Vitally Important appeared first on Big Nerd Ranch.

But there can be a downside to incorporating new product design ideas or features as you’re working on a software development project: design debt.  

Wait, what’s Design Debt? 

Design Debt is when new design elements are added to an application without considering how all these individual elements will eventually fit together. The end result is an app that has some great features and might look nice but lacks a design pattern or clear path of usability for the user. That usually means that important items might be hidden behind too many tabs or that the overall UX is just clunky.

You’ve probably heard of technical debt—the idea that choosing the easiest (rather than best) software development solution now causes headaches down the road as new code is added in.

Design Debt is similar, but while technical debt is a pain for other developers working to untangle cobbled together code, Design Debt has some pretty serious and negative implications for the end-user. Bottom line—your app will need some help. 

Why is Design Debt so dangerous? 

The worst part about design debt is that it’s not something that happens all at once. It creeps up on you, building and building until it’s big enough for you to notice. By that time, it’s a massive headache and a big mess to clean up. 

We recently partnered with a client whose work fits this design pattern perfectly. Prior to working with us, they had worked to further refine their app and to make it as useful as possible. And they were going about that in the right way. They were asking the right questions of their users and understood the problems their customers faced when using the app. 

The design issue was that they never fully mapped out how to best integrate the new features and functions in a holistic way. So, instead, they added a feature here and a functionality there. The end result was that the app contained all that the users wanted and needed, but was visually confusing. No one really knew where to look for the things they needed. The design debt had mounted up, and their users were paying the price.  

How can I avoid Design Debt? 

Plan time in your product lifecycle for designers to take a step back and look at all the individual feature components and see where they might be regrouped or reorganized. Don’t neglect to also plan for the time needed to refactor and move things around. Streamlining or removing feature components can help pay off Design Debt early before too much interest has built up and you’re looking at a rewrite. It’s cheaper to fix it in smaller increments rather than 3 years down the road and it’s a major rewrite for a development team. 

One great way to head off design debt is to take your app through a design audit, something that is a part of our Customer Experience offering. If you’re curious about what other benefits Customer Experience offers, get in touch.

Now, this is great if you’re just starting on your app and have the time to build all these processes into your design. What if you’ve found that you’re already in debt with your current app? Stay tuned for Part 2 – How to best manage design debt. 

The post Design Debt: What They Don’t Tell You About Design Thinking appeared first on Big Nerd Ranch.

• How and where will someone use this tool?
• What problem are they trying to solve with it?
• How do they currently solve this problem?
• Will the tool reduce the number of steps involved?

From there, you begin to ideate on the best way to structure a helpful experience for them through technology. (For a more detailed exploration of the phases of Design Thinking, click here.)

Of course, when laid out in this order, Design Thinking seems like the obvious choice. Certainly, it’s the one we recommend – and always use to develop digital products. But when faced with intense time-to-market constraints, the technology-focused approach often wins out. After all, an unfinished product with a thoughtful development process does nothing to advance your company’s bottom line. 

Yes, your app needs to function before anything else can happen. But what if you don’t have to choose between a carefully designed user experience and hitting aggressive business targets? 

Upon further examination, Design Thinking offers you the fastest route to a successful digital product – one that can help you meet your business goals through, rather than at the expense of, superior useability and creativity. We would even go so far as to argue that you simply can’t build a successful digital product without Design Thinking. 

Let’s examine why:

In today’s competitive environment, user experience IS the product.

The fact of the matter is, the market for digital products is a crowded one. Gone are the days that users will settle for an okay experience when they could be having a great one. And the constant introduction of new technologies compounds the pressure: 73% of customers reported that one extraordinary experience with a company raises their expectations for others, according to Salesforce.

Beyond individual budgets, a bad experience with a digital product can do even greater intangible damage to your brand. Sixty-seven percent of customers believe that the way a company uses technology is a reflection of how it operates in general. Even seemingly small features updates can undo the hard-won confidence users have in your company’s ability to deliver value.

 In this competitive atmosphere, the user experience is the product. 

The best way to create a good one? Empathize – which just happens to be the first stage of Design Thinking. Often, teams actually interview users to gain these insights. By understanding the user’s specific situation and challenges, you can engineer an experience that’s truly beneficial and easy for them – so they don’t immediately abandon your tool and create an alternative solution.

You can keep technical and design debt to a minimum.

Typically, two types of pressures force development teams away from a user-first mindset and into two versions of debt, both of which deprive an organization of its return. First, the race to release an application often drives technical debt. Technical debt accrues when a programmer opts for a faster solution over building out a more involved one that is less likely to incur bugs down the line. 

Technical debt describes the weight of all these shortcuts as they transform into complicated, expensive messes that take extended time (and budget) to fix. A 2018 report from the Consortium for IT Software Quality indicates that software developers spend 42% of their time fixing bugs, with the task constituting 80% of IT budgets. If you’re in a regulated industry, a web of buggy code can have even larger consequences in the form of HIPAA and PCI violations – which can cost up to $1.5 million apiece. 

Once an app has been released, there’s also the pressure to introduce new features. But when programmers don’t take the time to consider how a new feature might function in relationship to existing ones, they take on design debt. As a result, the feature comes out on schedule (and it looks fantastic) but people can’t easily take advantage of it – or worse, it interrupts the user flow entirely. The time saved on the front end ultimately creates added effort, expense, and brand damage later. 

Design thinking helps development teams avoid both of these pressures from the start. First, by putting the user’s needs into context, development teams can balance the must-haves from an experience perspective with the business goals of a particular project. Most importantly, as solutions pass through the prototype and development stages, teams have a low-stakes way to quickly determine whether the product or new feature will thrive out in the world (and where bugs threaten success). From there, they can put their focus on exactly what needs adjustment and what’s not serving the user before creating a full-scale version of the product or update. 

You have a set process with flexibility – that yields the strongest solution.

Leaving room to imagine multiple solutions to a problem doesn’t mean you have to abandon all sense of efficiency. Design Thinking, like any other structured approach, introduces a set process with clearly defined phases. Yes, there’s ample room for ideation, but a faithful approach progresses steadily to prototyping, development, and testing – saving you ample time in the long run with a product that performs well at the start.

And thanks to the inherent flexibility of ideation and prototyping, your team still considers multiple solutions and configurations, ensuring your final product has maximum creativity and functionality from day one. 

In conclusion, technical functionality without useability is ultimately a wasted expense. 

Or, to put it more plainly: just because it turns on, doesn’t mean it’s working. Design Thinking is the ideal method for staying on schedule with a digital product that can meet real-world needs under real-time pressures and constraints.

At the Ranch, we’re always looking for new ways to make Design Thinking enhance digital product development. If you’re ready to give Design Thinking a test drive, or apply it to a great new idea, we’re here for support, guidance – or just a friendly chat. Want more information? Check out what our digital product agency can do for you. 

The post Why Design Thinking Is a Must-Have for Digital Product Development appeared first on Big Nerd Ranch.