Arranging experiential information can be a challenge, especially if you’re trying to describe a system. A perfect example is the “Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System” — an eye chart developed by the Pentagon to describe how the military delivers complex weapon systems.

However, as in many other aspects of good design, we can seek inspiration for clever solutions to issues like these through analogous concepts. Take, for instance, Otto Neurath’s International System of Typographic Picture Education (Isotypes) which used rule-based pictograms to represent socio-scientific data. As a child, Neurath was captivated by the Egyptian exhibits at Vienna’s Museum of Art History and how they conveyed complex narratives without words. They broke language and accessibility barriers. These would eventually give rise to what we know today as infographics, though few people credit him for them.

You may also be familiar with Sankey diagrams as a representation of data flow. Captain Matthew H.P. Riall Sankey originally developed them as a way of showing the flow of steam and energy efficiency in steam engines, but scientists and engineers later adapted these for a variety of diagrammatic explanations. We see them now in visualizations of product lifecycles, user flows, and customer journeys.

The Circuitboard and the User

If we reduce user flow diagrams to a network of interconnected components, arranged in a logical, efficient layout to terminate at a specific outcome or goal, we effectively have a circuit board. And, much like a circuit, you want to make sure the energy (a user’s reservoir of goodwill) reaches the output (the goal, outcome, or completed task) without encountering a short (uncontrolled, unintended, and dangerous results). Treating user flows like circuitboards is not only a more empathetic approach to experience design — it’s also easier to socialize and understand. The clarity this analogy affords can improve maintenance, troubleshooting, and onboarding for new team members, whether they’re engineers, designers, or decision-makers.

Here are some ways to think about user flow diagrams as circuits that will make your stakeholders happy to review them.

Components and Pages

Just as circuitboards have a variety of components, your design has a variety of pages (in atomic design vernacular). In circuit designs, each component has a specific purpose. Because each component has a tangible cost, circuits are designed to be spatially and materially efficient. We might see an abundance of pages or features because they are simply less tangible. But, if we evaluate these to make sure that they “pay their rent” on the diagram in the same way we’d evaluate a circuitboard before it goes to manufacturing, we might find there’s a more sane and manageable information architecture to be had by eliminating waste. It’s less to develop and less to ask of your fellow builders and users when applying this metaphor.

Guidance: Imagine your pages have tangible costs like material electronic components and make sure your user flow’s “bill of materials” is worth the cost.

Traces and Connections

The paths that connect components of a circuit are called “traces.” We use traces in user flow diagrams to connect key experiences in a specific sequence in the same way: to outline the clearest, shortest path between an origin and an outcome-centric destination. In circuits, traces are designed to avoid sources of noise or interference. Longer traces also lose voltage over the distance, meaning the components might not work as intended by the time they get power. We would want to do the same in a user flow to avoid cognitive overload, distraction, or fatigue.

Guidance: Keep an eye on the distance between the user’s origin and goal by acknowledging their energy and cognition shed like voltage flowing through a circuit.

Short circuits and Error prevention

People test circuit boards and their diagrams for failed connections or misplaced components at the design, manufacturing, and post-production stage. They test these behaviors virtually before printing or etching the board. We could scrutinize user flow diagrams in the same way: trace the paths and look for components that show logical flaws or missing connections so users don’t become confused or abandon the experience entirely. The cost of errors for both are substantial once they go to development.

Guidance: Users behave like electricity: once they short-circuit, their energy is practically impossible to reclaim, so treat your user flow like a circuit diagram that’s going to manufacturing and ensure the logic is sound.

Scalability

Some circuitboards (not all) intentionally support growth and scalability without needing replacement or redesign. They may be modular, expandable through peripherals, multi-layered, or reprogrammable. In general, they may be designed to handle more than they need at first. User flow diagrams — especially for immature experiences like prototypes — need to accommodate these same ideas in the case the design is successful and its functionality expands. You can rely on the product roadmap to help you plan for scale: for example, if you’re building a wellness app that allows for daily reflection, you might build coaching and insights into your user flow even if it’s not part of the MVP. Circuitboards are designed with a “whole product” approach, and user flows should be, too.

Guidance: Take strategy into account when you design your user flows. Like a first-generation electronic product, your organization (or even user customizations) may augment the experience in the future and you don’t want to design yourself into a hole.

Where the analogy differs

Humans are unpredictable, electrons are not.

We can think of a user flow diagram as a hypothesis about a user’s mental model. However, users will naturally deviate from the “designed” path and make seemingly irrational choices. They may use your product in ways you didn’t imagine, and this can be illuminating! A user experience circuit can never capture all of the pathways users may actually take, and that means the user interface that supports the flow needs to be flexible and accommodating.

Humans have feelings, electrons do not.

Circuit diagrams are deterministic and predictable. User behaviors are neither. They will take seemingly irrational actions. They will act differently based on their emotions, motivations, and context. A user flow diagram typically doesn’t capture this type of information, but when paired with a user journey, they can start to take into account moments of satisfaction, trust, and delight. Circuitboards and user flows don’t capture the qualitative aspects of the experience, so don’t rely on them to illustrate chaotic human factors.

Circuitboards have strict symbols, user flows do not.

Circuit schematics have a specific, symbolic language that allows readers to interpret them with technical and logical precision. If you’ve been in the field of UX long enough, you know that every organization has their own flavor of diagram. This is generally mitigated with a legend, but be sensitive to your audience’s memory: use high-contrast colors, obvious icons, labels on connectors as needed, and a limited number of objects. If your diagram grows complex and risks frustrating the audience, consider breaking it up or aggregating objects.

Circuitboards are static, user experiences are not.

Manufacturers eventually produce the circuitboard, and it doesn’t change unless someone redesigns the circuit. User flows, however, change and adapt to user behaviors or product strategy. While using circuit metaphors as a means of creating high-quality user flows can be helpful, they will inevitably change and that must be considered in their design.

The Takeaway

Inspiration for good information design is all around us, and circuit diagrams can be a great extended metaphor to make your user flows even more powerful when you design efficient paths with the right components to turn on your user’s lightbulb. And, while they do differ in some regards, this lens can really raise the bar when applied properly.

Lastly, if you know anyone at Figma that can make connections raise on overlapping intersections in Figjam, hit me up.

Imagine you are involved in a project to ensure workers in your company’s factory are wearing the correct Personal Protective Equipment (PPE), but the PPE they’ll be using has yet to be produced — it exists only as a design. You want to be able to detect this with a connected camera outside of the hazardous area that sends images to the cloud for inference (the resulting output of a Machine Learning or “ML” model). This has to function on day one — your worker’s safety is at stake.

Natural follow-up questions might include:

• How might we train a model to recognize something in the physical world that currently exists purely as a design?
• How might we define the responsibilities, skills, and considerations required to execute against this problem?
• How does this sit within the overall design process?

This problem presents an opportunity to propose new design discipline — one that designs situations for prior artifacts to exist within.

To understand the differentiation of disciplines and the evolution of design artifacts, one can look to Design Thinking. More specifically, Professor Richard Buchanan’s 1992 paper “Wicked Problems in Design Thinking” where he describes the “Four Orders of Design”:

1. Signs & Symbols: typically the domain of a Graphic Designer within a two-dimensional space
2. Objects: useful artifacts of a three-dimensional nature; usually described by an Industrial Designer
3. Activities & Organized Services: experiential design that considers time and space; commonly served by Service, UX, and Interaction Designers
4. Complex Systems or Environments: poly-dimensional design that encompasses all prior orders and considers the influence of change on the system; more likely to involve urban planners, organizational, and other system designers.

Technology has reached a point where it is now possible to simulate complex Fourth Order design proposals with the artifacts produced by its ancestors. One can model a complex system or environment virtually to better understand its function: either to realize flaws or to transfer that understanding to a machine, which can — in turn — continually refine its own understanding. Two recent technologies provide great examples of Fourth Order design simulations:

Digital Twin

A digital twin is a virtual analog of a material object, system, process, or environment that allows one to simulate, modify, test, or monitor designs of the Fourth Order. In the cases that forces are included in the environment, this may also be referred to as a physical twin. An example may be a virtual representation of a factory line that is mechanically accurate and responds to simulated physics.

Machine Learning Model Training

Machine Learning (ML) models are computing systems that are capable of learning and adapting an understanding they themselves create without specific instruction. They create mathematical algorithms that analyze input data and make inferences about it based on detectable patterns. A virtualized design of the Fourth Order can be used to generate labeled data for an ML model to understand systems and environments that do not have sufficient real data. This data insufficiency can surface in a few ways, one being that the environment or system doesn’t have enough sense to build a model with observable data (e.g. photogrammetry, video, or image data). It may also be insufficient in the case that the design simply does not yet exist, as described in the scenario that begins this article.

For the sake of brevity, this article will focus on the ML example, but the interests and fundamental properties of both use cases are highly similar. Though an oversimplification, one could consider a Fourth Order design to be paused for the purposes of ML training and playing for the purposes of Digital Twins.

Considering the swim lanes for this theoretical PPE scenario, we can make a few reasonable assumptions about the roles and responsibilities in this process:

In short, a Design Researcher and a specialized Designer (in this case, an Industrial Designer) collaborate on the research and development of a prototype (for our scenario, PPE) up to the point that it needs to be simulated or visualized as influenced by a system prior to training. Neither of these roles are suitable for the studio artist-type work required to produce synthetic image data, nor is a studio artist necessarily familiar enough with Machine Learning to produce usable data.

This gap suggests the need for a transitional role: a practitioner with a skill set dedicated to describing the factors that influence a design’s virtual representation for the purposes of training and simulation. From this, the Situation Designer (SD) is born.

Earlier Methods

Situation Design, at its core, is a visual approach to data synthesis. All types of data synthesis rely on continuous data — measurements that can be infinitely varied over time. Data synthesis for ML in itself is not a new approach, but synthetic image data generation requires photorealistic, parameterized, visual and spatial design tools to create this data — tools that have historically been less accessible. Prior to the recent spike in tooling, synthetic image data looked like this:

If you’re familiar with Adobe Photoshop, imagine this as a batch process that applies various image manipulation techniques in a pseudo-random fashion. One can use this to take a conceptual product design (e.g. a new soda bottle label) and manipulate the image in a variety of ways to train a model that can determine if the design is present in many real-world environments. This is good but not great. In order to build a model with higher confidence for a situation that may not yet exist, the realism needs to be substantially improved.

Advancements in Design Technology

We can make some simple human inferences to understand the advancements in tooling by looking back at 2017, when the Amazon SageMaker service was launched as part of the AWS cloud offering. This service allows developers to create, train, and deploy models in many computing environments.

Curiously, Blender — the open source 3D design suite — started to spike in popularity around the same time following a series of substantial UI updates. This is strictly correlation and not necessarily causation, but it would be challenging not to speculate toward a trend. And, in fact, there is a trend.

Bespoke tools may be nascent, but they exist and are likely to become more popular and specialized. UnrealGT, a third-party synthetic image data plugin for Unreal Engine, was released in October 2019. In April 2021, spatial computing industry giant Unity somewhat quietly began promoting the use of their game engine for synthetic image data generation. NVIDIA released their enterprise Omniverse later that same year, enabling remote spatial collaboration for 3D design teams. These are the foundational tools an SD can use to bring the ‘perfect’ designs of any Order into a virtual representation of real world circumstances.

Circumstantial components of a Situation

The magic of this process is realized by the parameterization of environmental and situational factors that are otherwise very tedious to describe without procedural design: a rule-based system for describing 3D scenes. Situations may be influenced by (but are not limited to):

• Objects: objects of interest, structures, people, things
• Materials: exterior material finishes, natural distress
• Lighting: natural, synthetic, temperature, brightness, placement
• Camera: lens type, focal length, aperture, depth-of-field, orientation
• Occlusion: foreground and background elements that influence visibility of the objects of interest
• Orientation: proximity, location, rotation, and scale of the objects
• Fidelity: image dimensions, model complexity
• Physics: gravity, weight, turbulence, rigidity, softness, fluidity

Reflecting on a Theoretical Situation

Consider the early prompt in this article: you need to use technology to intelligently detect the presence of PPE that is not yet in use. To do so, you need to take an inventory of the conditions that will influence the resulting image so that you can construct a 3D scene rooted in reality. You need to have your virtual worker in uniform, in a variety of shapes and sizes, in a virtual factory, with virtual things surrounding them. Then, it needs to be optically convincing. You are now acting as a very intentional and specific type of spatial studio artist — you are designing situations.

Output

When an SD decides to render their Situation, they’ll likely generate thousands of images that are totally different from one frame to the next, though this is dependent on the frequency and amplitude of the parameters. If using a bespoke tool like Unity, the SD may also visualize the bounding boxes and label data in context.

Outcomes

Armed with a theoretical set of occurrences, captured in time frame-by-frame, machine learning engineers can use most of these images (some may be reserved for testing) to train a model that can understand a new reality. The applications range from the mundane, like ensuring the consumer packaged goods in the above example are placed according to their contracts with retailers, to the critical, like ensuring that aircraft inspections are being performed accurately.

Impact on Design

This may sound curiously similar to emerging tools for image generation like Stable Diffusion, Dall-E, or Midjourney. However, synthetic image data for training ML models needs to be consistent and specific — two problems that these tools struggle to overcome.

This article proposes that Situation Design is an emerging branch of Design Technology. As in more common design scenarios, a Design Technologist (DT, sometimes referred to as a UI or UX Engineer) can translate a design into something more functional. For example, when building a digital product, a UX Designer may work with a DT to realize the proposed design as a prototype to gain a better understanding of its function before realizing it through engineering. This process of realization is just as true for a Situation Designer.

Designers who are interested in synthetic image data generation might consider expanding their skills into spatial design, machine learning, and procedural design. With the business interests in artificial intelligence in mind, becoming a Situation Designer might be a prescient thing to consider sooner than later. Perhaps it’s time to design your next situation.

Free Learning Paths

• Machine Learning Basics
• The Infamous Blender Donut Tutorial
• Beginner’s Guide to Photorealism
• Parametric Design (via Blender’s Geometry Nodes)
• Intro to Unity

Caveats

This title and role description is a proposal for classification within the field of design, but there may be nuances and existing roles that overlap. Please feel free to mention so in the comments.

Additionally, it is worth noting that learning does not always require a high volume of data. Depending on the purposes of the model, methods like zero-shot, one-shot, and few-shot learning can achieve good results and would likely not require a Situation Designer. It’s also worth noting that models trained with fully-synthetic image data may leave some precision to be desired and may not result in confidence scores that are always acceptable.

Again, this is just a proposal. I would love to know if this resonates, if I articulated something incorrectly, alternate or adjacent roles, etc. I would especially like to hear from readers who may already be doing this type of work. Thank you for reading.

As of 2021, there are hundreds of millions of Alexa-enabled devices in households around the world. This estimate alone is convincing enough for many industries to experiment with developing voice-driven services. With a natural language user interface sitting on the kitchen counter, we have an opportunity to expand healthcare services to outside a hospital or care center setting.

While we are still perfecting how our assistants can handle things like complex queries, accents, context, and silence, there are still some known fundamentals to designing conversations that improve a user’s quality of care. This guide is intended for designers of all types who may be curious about some facets of conversational UX for patients and assumes this is your first rodeo.

Emergency / 911

It’s important to get this out of the way first: in a health conversation, no assistant is equipped to handle emergencies. Your users may build a mental model that substitutes your automated conversation for a medical professional. Every time they interact is an opportunity to reinforce that this conversation is not designed to provide connections to emergency services. Most home assistants devices can’t call 911 due to regulatory reasons, anyway.

You can simply mirror the same kind of message you might get when you schedule an appointment with your doctor:

Welcome to ____________. If this is a medical emergency, please call 911. How can I help you today?

Privacy and Authentication

Depending on the nature of your conversation, you may need to abide by certain privacy measures for a given country. This can be pretty murky, particularly in the USA where the laws are deliberately written to be non-specific in regard to the technical implementation of security. For the purpose of this guide, we’ll focus solely on factors that impact the user experience.

Basing this guidance on a document circulated by the Department of Health and Human Services, we can see there are a few methods for authentication of a person or entity. We can call this the “Three Ms” approach to user authentication: Memory, Material, and Metric:

• Memory: something the user knows (password, PIN, etc.)
• Material: something the user has (smart card, USB key, etc.)
• Metric: something the user is (voice, fingerprint, any biometric)

For VUIs, a good pattern might consist of:

• A web-based, one-time configuration of a username and password
• A PIN that can be remembered and uttered, constructed in the one-time configuration above
• A voiceprint for seamless verification of a given speaker / user

Options

You can toss out Miller’s Law right now. Even short interactions can fill your user’s short term memory with a lot of contextual information to compensate for the lack of visual feedback. Because we are looking at VUIs for healthcare, we may also assume that this is not an opportunity to test the limits of a digital assistant’s comprehension. It’s best to simply state the possible commands that will yield a response from the system. The recommendation is to provide up to five options. If you have more than five, first reconsider if that’s necessary. Otherwise, start chunking and reserve the fifth option as an opportunity to request more options. This is more inline with Nielsen’s recommendation of having 3 +/- 1 options.

Later in this exchange, consider repeating the selection or directive after the user has responded. It’s good practice outside of a healthcare context, too, but the consequences here are potentially more dire. Things like symptoms and medication names need to be accurate; imagine a voice assistant placing an order for the incorrect medication. Even if this is a user error, that user may live or die based on the accuracy of the medication request. If you think this is an exaggeration: the NIH estimates that approximately 250,000 deaths may be attributed to medical errors annually.

Language

If you are designing this interaction, there is a possibility that you and your collaborators are speaking different languages: plain versus clinical. It is important that we don’t make assumptions about a user’s reading level or clinical literacy. Therefore, a VUI that is intended for patient interactions needs to accept plain language inputs and produce plain language outputs. Let’s look at a possible example where our assistant will be confounded by a user response.

User: Alexa, ask __________ if stomach ache is a side effect of Alazopram.

This is more than likely what is returned from the query:

"results": [
    {
      "term": "DRUG INEFFECTIVE",
      "count": 65714
    },
    {
      "term": "NAUSEA",
      "count": 50157
    },
    {
      "term": "FATIGUE",
      "count": 48880
    },
    {
      "term": "PAIN",
      "count": 44892
    },
    {
      "term": "DYSPNOEA",
      "count": 40019
    },
    {
      "term": "HEADACHE",
      "count": 39439
    },
    {
      "term": "DIARRHOEA",
      "count": 38078
    },
    {
      "term": "DIZZINESS",
      "count": 35537
    },
    {
      "term": "ARTHRALGIA",
      "count": 32024
    },
    {
      "term": "VOMITING",
      "count": 30893
    },
    {
      "term": "ASTHENIA",
      "count": 27200
    },
    {
      "term": "FALL",
      "count": 26464
    },
    {
      "term": "MALAISE",
      "count": 25439
    },
    {
      "term": "PAIN IN EXTREMITY",
      "count": 25075
    },
    {
      "term": "OFF LABEL USE",
      "count": 24877
    },
    {
      "term": "RASH",
      "count": 24199
    },
    {
      "term": "MYOCARDIAL INFARCTION",
      "count": 23085
    },
    {
      "term": "PNEUMONIA",
      "count": 22168
    },
    {
      "term": "PRURITUS",
      "count": 22150
    }

This is a truncated result from a query to OpenFDA that returns adverse events and their reported quantities from a given drug. Notice terms like “myocardial infarction” and “pruritus” are present in these results. There are plenty of clinical terms that are components of a stomach ache, but that term itself is not present.

If this is a potential interaction you’re designing for, there is good news and bad news for you. The bad news is: you may need to support a dictionary of synonyms for these entities. The good news is: this may be tedious but it is relatively simple technically. You can also save yourself some effort by simply testing your prototype and observing how users already translate clinical terms to plain language. You can do this without any development effort through the Wizard of Oz method, and you can set up your tools for this style of testing in less than five minutes.

Pain Scales

If you haven’t designed patient interactions through a VUI before, you may be surprised to learn that you don’t have to invent your own measurements for seemingly subjective things like pain. Plenty of research has gone into understanding the usefulness of pain scales, and for VUIs we have one obvious choice: the Verbal Numerical Rating Scale (VNRS). This is simply a scale of 0–10 in relation to Activities of Daily Living (ADLs):

0 = No Pain

1–3 = Mild Pain (nagging, annoying, interfering)

4–6 = Moderate Pain (interferes significantly)

7–10 = Severe Pain (disabling; unable to perform)

These self-reported conditions are often considered the “fifth vital” and are surprisingly helpful to clinicians. Because of their apparent simplicity, users don’t need the same breakdowns of the pain brackets as described above. You can simply say:

VUI: On a scale of 0–10, with 0 meaning no pain, how much pain are you experiencing?

The added benefit here is speed. Voice interactions typically take longer than visually scannable experiences, so the fact that the VNRS can be administered in less than a minute makes it particularly effective.

Bedside Manner

Bedside manner is a ubiquitous term that has its roots in describing the expectations of a doctor-patient relationship. The conversations your interface is having with a patient should be upheld to the same standards as it is a surrogate clinician in the eyes of the user. If you’re a UX Designer, this is a great opportunity to exercise your empathy muscle. Put simply, this is important in our patient experience for two reasons:

1. It humanizes the experience
2. It reinforces that the system has collected the information correctly

Let’s look at our pain scale dialog to see how our VUI can support good bedside manner with our theoretical patient:

VUI: On a scale of 0–10, with 0 meaning no pain, how much pain are you experiencing?

Patient: I would say 9 right now.

VUI: Sorry to hear that you are experiencing pain. Would you like me to connect you to a nurse?

Multi-Modal Interactions

This is our Back Button or Escape key in the VUI experience for healthcare. There are a number of reasons why this may be useful to patients:

1. The VUI has simply not yielded the results expected by the patient.
2. The user has suffered physical or cognitive impairments that reduce the usability of a VUI.
3. The system requires inputs that are not possible or inefficient to collect via voice alone (e.g. taking a photo of a dermatological side effect to a medication during a clinical trial)
4. The situation requires immediate human intervention or response (keeping in mind that a VUI is unable to call emergency services).

This is probably the most complicated and ambiguous part of designing an effective, voice-driven patient experience as there are a number of technical approaches to switching modes of interaction. You can use an architecture that enables your various modes to seamlessly handoff to each other, or consider building your interaction on a platform that already offers multichannel support.

That’s it!

Just kidding. There are many more nuances to patient care via Voice User Interfaces. I hope that this short guide is helpful to people who are looking to quickly prototype a new healthcare VUI that at least has a solid foundation. In addition to this article, I recommend reading this excellent article about NN/g’s classic usability heuristics as applied to Voice. Are you an expert on the topic? Please comment below!

I decided to tackle the problem of time management, as much of my time now is compromised. The little time that I do have to get into deep work or a state of flow needs to be handled pretty strictly. I had used the Pomodoro Technique in the past with great results. I even use it at home. I’m using it right now to write this article.

What I really hated about it was the workflow of starting a timer. I have purchased and used several Pomodoro-inspired apps to manage my time and they all suffered from the same problems:

Apps can be over-designed.

Fundamentally, I just need a timer. There are many ways to do this. I could do this on my phone, of course, but I’m not working on my phone. I’m on my computer. The idea of going to my phone or watch also irked me as I am 100% likely to get sucked in to a notification or curiosity. So, let’s look at staying in-the-box for now.

This is a lot. If I want to just start a timer and stay focused, I don’t need settings. I also started to dislike the idea of a countdown because that just pressures me to get into a flow state and I’m too cognizant of the clock running out. It’s another distraction. I’m sure some people might find this useful, but if I want to get the fundamentals right this is not the solution.

Naturally, I started sketching.

Three screens in and I realized this was becoming a vanity design and not about solving a problem. I am reminded of a quote at this point.

World society has throughout its millions of years on earth made its judgements upon visible, tangible, sensorially demonstrable criteria. We may safely say that the world is keeping its eye on the unimportant visible 1 percent of the historical transformation while missing the significance of the 99 percent of overall, unseen changes. Forms are inherently visible and forms no longer can “follow functions” because the significant functions are invisible …
- Buckminster Fuller (source)

I was designing for the unimportant, visible 1%.

So I took a step back. Let’s place the constraint of keeping my hands on the keyboard. There’s an interesting thread here about the advantages of this approach and I also like the idea of not having to switch modes between UIs. I don’t want to re-learn a timer UI when I’m trying to focus on working on just one thing.

My first bit of research was to integrate it into the environment I spend much of my time in: Slack.

What worried me about this was how it manages interruptions. I now have to get out of my focused state to give notes inside a platform that encourages distraction. This is not cool.

A revelation: leverage the OS.

Solving the distraction problem was now as intriguing as designing a timer app. This is when I started to frame this more as a “Jobs To Be Done” scenario to get a good idea of what I actually wanted. For instance, when a consumer goes to the hardware store to buy a drill, they are likely not shopping for the drill itself. They actually want to buy a hole.

My own issue was similar. I was “designing a drill” when I really wanted to find a way to mute distractions for an interval of time. The countdown is really irrelevant when framed this way.

Knowing that I can leverage my OS, I began crafting a really simple Alfred workflow. It sets a 25 minute interval, enables Do Not Disturb, and then re-enables notifications after the interval ends while sending its own little congratulatory message. The best part being able to trigger it by typing just one word: “umami”.

Why umami? It’s the flavor essence of the pomodoro, which is Italian for “tomato.” It’s also short and memorable. It’s embodies the fundamentals of the Pomodoro Technique.

You can download the Alfred Workflow here. Feel free to modify it.

What I learned

I don’t think my epiphany is unique. However, designers as a community will always need to be reminded of valuing functionality and pragmatism. All too often, I’ll interview a designer and they’ll tell me they get inspired by Dribbble. That’s great. There are some truly brilliant people on that platform.

I just get really tired of seeing things like this:

It’s beautiful! It has so much character. But, how effective is this? What consumer wants to learn this peculiar UI to buy a shoe? Is this interaction creating friction when a user wants to be gaining momentum toward their goal? Think about the form following the function.

Ask yourself “does this even need a UI?”

Thanks for reading.

I decided to write this article after departing from a now-defunct startup that struggled to adopt Design Thinking and Sprints in a productive way. Our founder was there for the birth of every T-Rex of a feature we designed. Ultimately, we should have been asking:

“Is creating another T-Rex something the world needs? Is there a way we can improve on the existing T-Rex to make it more useful and perhaps less bloodthirsty?”

With the hindsight of about 20 years of design process innovation, I can safely say that Jurassic Park could have avoided about 80% of its crises if they had conducted a Design Sprint to work out the kinks. But, it was the 90’s and the idea that anything was intentionally designed is hard to believe.

The one caveat to this being that John Hammond should be optional.

Now, that’s not true for every organization. I’m sure there are some people who really embrace product prototyping and validation. In my experience though, having a founder decider is something that should be avoided in some scenarios. We’ll dig a little deeper into what can go wrong, why it happens, and ways to work with these scenarios. And also there will be dinosaurs.

The founder doesn’t have the patience to invest in this process.

Congratulations! You may regret this, but getting the founder to accept an invite to a minimum three-day meeting is a big accomplishment. No matter how much prep work you did in persuading your organization to apply this process, you may likely be met with skepticism at best. The founder doesn’t always adhere to your rules either, so be prepared for some possible frequent interruptions bookended by uninterested smartphone usage.

Solution: Highlight deliverables and never forget, money talks. If you can make the results of a sprint feel tangible and attach some dollar amounts to how much money these processes can potentially save (or generate!) you are more likely to hold their attention.

The founder is too attached to their own vision and unwilling to change based on prototype feedback.

This is one of the keystones of Founder’s syndrome: any challenges tend to underscore their own beliefs and act as an imperative to take greater control of the minutiae of the product. In a sprint setting, this is usually results in dismissive reactions to your testers. Founders can be quick to subscribe to the Faster Horse ideology, but underestimate the real-world learning curve between their vision and the status quo.

Solution: When you conduct testing, ease the blow to your founder’s ego a little by asking for “advice” and not feedback. This frame of mind helps the tester feel like they are partnering with you (and they are) to improve your product.

The founder considers themselves to be the authority on technical decisions.

This is where you might encounter the founder ignoring the sentiment of specialized attendees (design, engineering, marketing, etc.). They may also take this a step further and criticize or — in extreme cases — remove the offender from the exercise. They might cite other products that “went viral” or had allegedly short-lived beta versions as proof enough that these experts are less integral to the org. Having these people on staff is sometimes a checkbox for investors in their mind.

Solution: Be transparent about what your role is and what your department has been up to. It’s likely that they don’t know what you do on a granular level, so speak in terms that are in plain language, too. Once they gain a fundamental understanding, they’ll trust you a bit more and feel proud when they do reference something technical properly.

The organization has structured the sprint to include people loyal to the founder.

Much like the lawyer in Jurassic Park, the “Donald Gennaros” of your organization are people who have worked with the founder in the past and are there to reinforce the founder’s own beliefs. No matter how many things go wrong, they will always sit on the toilet of loyalty (a loyalet?) until the Tyrannosaurus they created eventually consumes them whole. This will make voting during sprints particularly difficult as they will gravitate to the founder’s solutions or the founder may only endorse theirs.

Solution: Become an expert. SME’s that have little experience in product design can still be very useful. They are often happy to share their experiences and sources of knowledge around an industry or topic that is foreign to you because hey, we all feel good when someone considers us an expert.

It’s important to remember that John Hammond is not the villain.

He had a lot of great qualities that enabled him to act on his vision and he was sincerely interested in being involved in every aspect of the creation of a product. Don’t let the founder’s behavior skew your Design Sprints into meaningless, sisyphean tasks. Cure them of their syndrome.

Or this may happen to you.

What is the Blob?

The Blob is an amorphous, pseudo-organic shape that’s commonly used to anchor landing pages visually. It usually serves as a mask or backdrop for an illustration. About 90% of the time the Blob is filled with a gradient and sits on the lowest layer of a design. Its relationship to the brand or product is usually ambiguous, but it’s an easy way to transition between different types of information without being too blocky.

Here’s my Dribbble bucket-o-Blob that I’ve curated. It’s not comprehensive and I don’t count blobs that are: a meaningful part of an illustration (foreground to background layers of landscape), waves, or other specific intents (like actual graphs).

Where did the Blob come from?

It’s hard to say. I have a few theories, though:

1. The Blob is a compromise or passive rejection of the Flat UI craze.

The rigidity and coldness of iOS 7 (and even Windows’ Metro UI) has become unbearably mundane. While we may embrace flat and solid elements, they need balance with organic shapes that feel welcoming.

2. The Blob exists as a substitute for illustration.

Not everyone can afford or execute illustration in their design. Trendy brands like Dropbox and Intercom have blob-ular elements as part of their illustration style and designers want the handmade quality without the effort of developing an entire system. It’s an investment that will need new assets for every occasion.

3. The Blob is here because it feels like it’s data-driven and that means your company is smart.

There’s some design psychology involved here, but put simply: when we see rising actions from left to right, we feel comforted and likely place more trust in what we’re interpreting. It’s also really suggestive of things we look at regularly that we associate with being insightful. For instance:

Some examples of AI that we interact with in our daily digital lives are also embodied as Blobs (to varying degrees).

In practice, it’s more likely to appear as a static “graph” element. The intent is virtually the same though. They want to suggest that this product is thinking about how to provide insights and growth.

4. Blobs are more convenient in Responsive Web Design.

Anyone that regularly incorporates photography with human subjects into their design knows that the cropping of a photo and the geometry of its layout can become a chore to control at different breakpoints. Too much forehead here, cropping the smile here, text across the eyes here, etc. It’s hard to predict behavior across multiple devices without a lot of specificity. Blobs solve that problem really well because they have the qualities of organic shapes and textures we crave, but they don’t have eyes and smiles so we don’t care if they’re obscured or cropped in a less predictable way.

There are many species of Blob out there. Some are really thoughtful and work really well, tonally. Others are arbitrary, unnecessary and at times complicate the UI. Have you spotted a Blob in the wild? Do you think they’re pointless adornment or do they help balance your design? Tell me about it.

Update 3/19/19:

It seems like some of the clever folks at Prototypr.io have adapted my research for the development of a blob-building tool (Blobmaker). My hat goes off to Richard Zimmerman for his work. Thanks for the shout-out Richard!

In the last month, I have dedicated a portion of my free time to volunteering with high school entrepreneurs who are interested in receiving mentorship and assistance from professionals in their area. This was all in preparation for the FedEx Junior Business Challenge, to be held in Atlanta in late September of 2017.

On September 21, the winners were announced. The $75,000 donation from FedEx was awarded to a group of high-school-aged, aspiring women entrepreneurs from New England with a product called LO-K8 (pronounced “locate”).

Yes, that means my students lost. Was I surprised? Not particularly. My team had decided to take their business in the non-profit direction in order to solve a social problem. It was also a sensitive subject, difficult to scale, and likely wrapped in bureaucratic red tape. That also means they hadn’t sold a physical product (though they had healthy initial fundraising). They knowingly narrowed their chances of a win for a fundamentally entrepreneurial judgment.

LO-K8 on the other hand had already sold a substantial amount of their product and were, as I’m told, “working with a manufacturer in China.”
OK, now they had my attention.

What does LO-K8 do?

LO-K8 is a bluetooth device used for locating belongings, finding your phone or taking a photo remotely. If it sounds familiar, it should. The technology is about four years old and it was likely purchased from Alibaba.com.

Why innovation matters.

Regardless of your political leanings, I think most Americans can agree that innovation is important to our society. Important enough even to have an entire office added to the White House in its name.

And it’s important to encourage our young people to be makers. They need to move fast and break things, as they say. As “maker” culture and even Design Thinking starts to become part of our education system, the workforce will have greater expectations around the technical and creative abilities of our high school graduates. That’s why we have things like Girls Who Code that blend technical concepts with creative problem-solving. (It’s worth noting that the LO-K8 site was produced on Wix, so they didn’t even get the opportunity to learn much technically about their own marketing media.)

So who told these young women that being an entrepreneur is ordering cheap electronics from China and repackaging it as a new product?
Did they learn about order fulfillment? Social media marketing? Which fundamental entrepreneurial concepts were born of this endeavor?

“The FedEx Junior Business Challenge has provided JA students with another opportunity to develop a product or service, create a business plan, and produce and market their innovation, while also continuing to develop their presentation skills,”

— Asheesh Advani, CEO, JA Worldwide

LO-K8 in a global society.

Based on the criteria outlined, it bothers me that their mentors skipped three of these five goals and still qualified for this challenge. The product was off-the-shelf and the ethics are debatable.

The obvious issue around overseas manufacturing of electronics is the worker quality-of-life in these plants. This product is too inexpensive to be subject to the strict guidelines that a company like Apple can mandate. It is even possible that their product was assembled by someone their own age or younger. If my sleuthing is correct and LO-K8 is in fact produced by Innovast in Guangdong, that means they are also likely perpetuating it’s reputation for containing the largest electronic waste site on Earth.

And it’s easy to dismiss these problems because they are not domestic. So let’s talk about the domestic problem with businesses of this nature: it actually destroys uniquely innovative products. How? Manufactures in China will routinely manufacture more units than ordered (this can be a domestic product or an overseas one) and sell the remainder without the branding for a lower price. Buying unbranded knock-offs and selling them as a unique product is nearly as criminal as counterfeiting. Some would argue that it’s not different at all.

There is a part of me that thinks we are not the caricatures we create. I want to believe in the hopeful, post-millenial generation that represents a diverse landscape of empathetic, conscientious beings. And despite my pronounced cynicism, I volunteered to mentor them. I hope this article inspires you to do so as well. We can’t afford to let corporate social responsibility be some box to check.

And if FedEx continues down this path, they might have to update their logo.