As New York Public Radio, like many other organizations, have shifted to working remotely over the last year, we saw a need to rethink how we collaborate in order to increase productivity. Like many design teams before COVID-19, we already used tools like Figma and Miro that made passive or asynchronous communication possible but once we removed the in-person aspect, a few things changed.

What does the format convey?

When we were at the office, it was easy to convey the fidelity of the design work using the format and wording of the ask itself. For instance, a product designer may have asked a product manager and an engineer to pop by her desk to review some work-in-progress. Not only was the Figma wireframe clearly a work-in-progress, but the environment (casually stopping by someone’s desk to look over their shoulder) also conveyed this message.

Fast forward well into remote-only world and a casual work-in-progress convo could easily get confused with a higher-fidelity demo (where there is less time to integrate feedback) because we are now using the same format for both informal and formal meeting-types, Zoom. We noticed that even if we stated the agenda in the meeting invitation, we received feedback from teammates who they felt like they were being brought too late into the design process and weren’t sure of their role or the kind of feedback expected. What went wrong?

Create clarity

How do we clearly communicate the product design narrative? How do we let the broader product development team know where we are? The product design narrative includes every step of the design process: discovery, research, product strategy, direction, frameworks, tactics, and most importantly, conclusions (what did we solve for? why?). A lot of the conclusions or solutions part of the narrative is represented in Figma or in Storybook (the Radial design system library) or in Slack threads. How do we better document this narrative in one place? Is one-stop communication even feasible?

The product design narrative includes every step of the design process: discovery, research, product strategy, direction, frameworks, tactics, and most importantly, conclusions (what did we solve for? why?).

Map it out

Where were we having conversations? Where were decisions being made? Who needs to weigh in? If we have the same kinds of meetings, can we create some shape or clear structure around this? Without removing the creative (conversation) aspect?

After bringing up the topic with the design team, one person surfaced Figma’s meeting framework. We liked how this provided some definition to the type of design meetings but didn’t handcuff the team to a particular process. We too wanted to create something malleable as design is about exploration. The Figma model was great inspiration.

In October of 2020, we ran a design team workshop using Miro and Zoom to determine how we communicated, why, with whom, roles, responsibilities and pain points. We framed it as “An open-ended dialogue and workshop on design team responsibilities, communication, tools and process connectivity.”

We started with some free-form post-it dropping. Which started to take shape when we themed the notes, and then noticed that we could sequence the themes or major needs in an order that aligned with the design team process. Notice that we were able to put shape around the pain points (on salmon-colored stickies) and sequence things in an organic fashion.

We were then able to map out the types of design conversations we were having, again with pain points (on salmon-colored stickies). I’m purposely not showing the detail but the visual is good context because you’ll see how much structure we dissect from this later.

The key elements we were able to parse out from this step were:

1. Discussion format
2. Participants (who and why)
3. Input types desired
4. Expected outcomes
5. Timing (when to run the meeting during our process)

Which provided a holistic view of design-related conversational inputs.

Pro design leader tip: Keep these design-related conversations very open-ended or risk losing the chance to capture ideas from your team . Beware of narrowing scope too early! Designers need room to explore, test, see and then re-check themselves to arrive at a collaborative solution.

The new design meeting framework

We took the team’s knowledge share and synthesized the insights into a framework. One that brought together the 5 key elements (format, participants, inputs, outcomes, timing) from the last step. When would we run a pair design vs a check-in vs a review?

We begin the design conversation with a Kick Off to discuss a project vision and get early alignment with other disciplines. This could also be the pre-work to product discovery. From there, we typically run Pair Design sessions to ideate with a small group where we create visual artifacts or discuss data and research. Check-ins are informal and a space to discuss work in progress and keep everyone in the loop. Reviews are done with design management to ensure that the work is aligning with product and design strategies. The key difference between Check-in and Review is that the Review is where the design head provides detailed design direction, normally in a group setting so everyone can benefit from the feedback.

This meeting framework was then shared with the broader digital team. It was helpful to align on expectations, vernacular (check-in vs review), and when these meeting types would pop up during the product design process. This framework is meant to be a guidepost and not something we dictate from project to project. It’s need-based and built for clarity.

One of the biggest benefits to the team and our process has been the ability to capture the product design narrative. This narrative includes the reasons why we made certain decisions, our design direction, how it may have adjusted over time and product descriptions. It is the responsibility of the design team to capture the feedback and outcomes that shape the product design narrative and this framework makes it clearer on when to do that and why.

Our new framework 🎉

The meeting types

Kick-off: Discuss scope of project and initial design approach. Input: Information from other disciplines in order to accurately give design estimates. Why: To create a shared understanding of goals, success criteria, stakeholders, and set roles & responsibilities. When: Beginning of process.

Pair Design: Ideate with small group to gather ideas and synthesize together. Some sketches, inspo or data gathering may be done ahead of time to get convo rolling. Input: Deep, expansive dive on subject. Keep open ended to gather as much info and ideas as possible. Why: Flexible and hands-on meeting required to get early alignment and inputs. When: Very early in design process.

Check-in: Informal conversation to discuss work in progress, show options, get other’s perspectives (e.g. Dev, Product, Content, Marketing) and to keep everyone in the loop. Input: Focused input on artifact type and within scope and theme. Looking for others to provide input from their expertise. Feedback is recorded. Why: To discuss the design work and get feedback in order to move project forward. When: Middle of process.

Review: Design direction and alignment with design management. Small meeting within the design team to discuss work, strategy, output and next steps. Why: To ensure that the work is as expected, meets goals, adheres to design direction and standards. To get feedback and approve work as complete or design done. When: Beginning, middle and/or end of process.

Demo: Formal presentation with scrum, digital, cross-department or external groups to share work. Input: Feedback is welcome and captured (but not integrated) as this meeting occurs late in the product design process. Why: To ensure a shared understanding of what is going to be built. When: Nearing the end of the process.

So what replaced that use-case of people popping by a designer’s desk? The check-in. This can happen asynchronous or synchronously (typically over Zoom) but it is now clear that there is a space to discuss work in progress AND a place where the designer is responsible for capturing feedback, mentioning that feedback in the project Slack channel and showing up at a later point with visuals that reflect team inputs. The goal is to ensure that everyone on the Digital team knows the progress stage of the work, who to go to with questions or suggestions, and where to access the latest visual files or mockups.

One final takeaway from this process and our lived experience working remotely for more than a year: you have to communicate MUCH more often in a remote-only environment. Repeat yourself. Threads disappear in Slack and in email, bookmarks to links you need can get lost. You have to capture that product design narrative and share it with the team. The NYPR design team utilizes radical transparency in everything we do. We ask the team to over-communicate. That can be a burden and you do need to set limits (and time off of Slack) but in a remote-only world, giving your teammates a heads up, note-taking and providing minutes in an open channel, all lend themselves to a more informed and better-aligned team.

A New Design-Centered Meeting Framework: Better Capture the Product Design Narrative was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m very lucky to have the opportunity to study design in a formal educational setting, and my curriculum has taught me invaluable lessons about leveraging design thinking, research, and graphic design to craft meaningful visual solutions to all kinds of problems. My time at NYPR has been equally invaluable in showing me how my education translates into product design work outside of the classroom. Here are how some of my conceptions have changed during my time interning with NYPR’s Product Design team.

1. A Design System is just a Style Guide, right?
Short answer, no. When the Product Design team here at NYPR first introduced me to the idea of a design system, I imagined it to be a glorified, extensive style guide that lives in Figma. To be more specific, I imagined it to be a collection of type styles, color palettes, and logos, similar to how branding agencies typically display the visual identity for a project.

Like a style guide, design systems are created to ensure visual consistency across products and brands. However, they cover more than typography and colors; I learned, design systems contain reusable components that are organized by atomic breakdown. These components — including, but not limited to buttons, type styles, image treatments — act as building blocks for designing UI so that not every design has to be created from scratch. I like to think about the design system as a huge library for all of NYPR’s visual elements, their respective code, and documentation about how to use it.

Furthermore, a design system serves a greater internal purpose than I had previously thought. It allows the team to work quickly and efficiently. The NYPR digital team is small (but mighty), and they have a multitude of brands to work on. Having a design system speeds up the design process while maintaining visual cohesiveness and code cleanliness. Because all components are documented in this library, designers can combine individual library elements to build designs. In theory, it’s as easy as choosing your favorite Lego blocks to build with. (For a more thorough explanation, check out this talk by Yesenia Perez-Cruz)

2. So a Design System is more complicated than I thought. But, still, it’s just a collection of visual elements, code, and documentation.

At its core, the design system is a tool that helps designers, engineers, product managers, project managers, and even external teams like marketing or editorial. So, it can be more than that. It can include the design philosophy, best practices, and even personas (which I was able to work on myself).

3. Aren’t personas outdated, or just a gimmick-y thing you learned at school?

In my research-based studios, I had created personas, too, as an exercise. The personas I created were fictional characters modeled after a potential user. They had a fake name, fake photo, fake age, accompanied by other stats about their needs, goals, and behaviors. In my studies, these personas weren’t as helpful as I hoped they would be. After I created them, I didn’t reference them again in my design process.

At NYPR, I came to learn that personas aren’t inherently unhelpful, but can be tailored to better fit UX/product needs. As a UX designer, a users’ mindset and behavior are much more important than what they look like, what their race is, or what their age is. Stripping those demographics away can allow a persona to feel more focused and relevant. Rather than giving them photos, attaching them to an abstracted illustration that alludes more to their role rather than their appearance can be more helpful.

4. Cool, that makes sense. But aren’t product designers supposed to make apps, or websites for the general public to use?

Yes, that’s true! Product designers do make apps, websites, and other digital products. But what I didn’t understand before my internship was the distinction between internal and user-facing products. In design academia, I spent so much time prototyping all kinds of products for users that aren’t myself. Like a scientist studying an organism, I had to take myself out of the equation. However, in organizations like NYPR, designers have to think about creating products not only for the end user or NYPR audiences, but also for themselves. The team created the design system to address issues they were facing in their workflow, and to better communicate with teams external to Digital. Internal facing work is just as important as end user facing work, so don’t be surprised if you end up designing something to help yourself and the people around design or execute more efficiently.

Addressing Misconceptions from a Design Student was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

An Expanding Problem Set

Nowadays, we’re demanding more from design systems than ever before. As design systems become more commonplace and standard, their problem set expands. The ol’ PDF style guide won’t cut it anymore. Design systems need to be flexible, accessible, customizable, available in different languages, successful across different platforms, and able to fold our socks.

The definition of a design system is changing. The idea of one brand = one design system, this-is-all-you-need set of components and rules, is being pushed aside for something far more flexible and far more integrated. There are several reasons why this is happening.

The scenarios we’re designing for are growing. There are more users on more platforms consuming content in more ways than ever before. There are even design systems for cars now.

Accessibility considerations also have design systems adding to their list of requirements. Whether it is large text, low-light, mobile-friendly, or dark mode, companies are pushing to make their products usable to the broadest possible audience.

We also see use cases expand internally. Companies might house multiple brands but use one core design system. Read how Harry’s is making this work.

A Growing List of Grievances

With all the evolution and leaps in advancement design systems have made in the past five years, it seems like the same problems remain. All those “Why Our Design System Failed” articles still sing the same tune: hard to integrate, harder to maintain, hard to follow, over-standardized, and creatively stifling. Google “why design systems fail” when you have a moment; it’s a pretty morbid page of search results.

The common thread that connects all these grievances is a long-held belief that design systems work best when the rules are followed and when consistency is king. There’s a natural inkling to lean into compliance when design systems scale as a way to make sure you don’t end up back where you started, with 15 shades of Lyft pink and a potpourri of submit buttons.

When we started creating a new design system at New York Public Radio, a non-profit organization with seven unique brands, our key value was flexibility. Our brands span a wide range of media, from talk radio and news to podcasts and music. And as you can imagine, a wide range of user personas and a wider range of use cases.

Designing for Variables

In our case, complete consistency would almost be the anti-goal. Each brand needs to have its unique expression and content experience but tie back to a larger organization. Each component we build is designed to flex to the properties and use cases of multiple brands. This gives a designer options when designing and a developer consistency when developing. I love Ken Skistimas’s example here about a car manufacturer’s family of cars.

“A family of cars addresses multiple use cases but carry common traits across to make them identifiable as belonging together.”

We can customize the car however we’d like, but what’s under the hood should stay predictable.

Flexibility was also a requirement for us to be able to pull off an effort like this. Like most real-life design systems, we didn’t start on a blank page. We began our new design system with tech debt, pre-existing components, and, sadly, a previously failed design system. Taking a piecemeal approach to developing a design system requires a little wiggle room as you straddle both the current and future state of your components. In this case, both an audit and component status log helped us maintain a clear standing of where we currently were, and where we wanted to be.

As design systems grow more complex and their uses more diverse, it’s important to build in a little flexibility, so when things do eventually change, you’ll have designed for them.

Hopefully, I’ve made a pretty good case on how and why you should be thinking about your design system’s flexibility. How can you build in flexibility but stay within predictable bounds? In the following article, I’ll run through methods and tools we use at NYPR to create genuinely adaptable components.

Flexible But Focused, Designing Systems for Adaptability. was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Digital team at New York Public Radio builds software for most departments in our business, including podcast creators, music, and news. We used the Scrum framework for product development for at least 5 years, but by summer 2020, our long-time Scrum approach to software development started coming under strain. We craved focused time to work, and spending almost a full day in total every two weeks to prepare, refine, and ingest a new sprint backlog became untenable.

After a thorough examination of the issues we were experiencing and working through numerous process optimizations, we transitioned to using the Kanban framework. Below I’ll get into some of our reasoning, some tips for process facilitators considering a similar change, and a few anecdotes about how it’s going for us here at NYPR.

Step-by-Step Reasoning for a Framework Change

As you may know, human brains typically struggle with change. This is why at the inception of a framework change idea, process owners and participants must fully understand the benefits and drawbacks of each framework in consideration.

Key questions we asked, as a starting reference:

1. What problems are we experiencing?

This first step should be easy — find out from your team what isn’t working.

2. What are the root causes? Are the issues process-agnostic, or actually resulting from the process itself?

Dig deeper with your team and understand the root causes behind any issues they brought to your attention. Try “5 Whys” or another root cause analysis exercise to reach the true underlying problems.

When you understand them, you may find that it takes less effort to fix difficulties within your existing processes — through adjustment of your tactics, re-education of team members and rule-setting with stakeholders surrounding the team, or a novel approach to any necessary activities. Give these possibilities added consideration and make improvements to your existing frameworks where it makes sense.

If the problems truly do stem from the process itself, bring your takeaways into the next step…

3. Define what you are optimizing for.

Scrum and Kanban, as two examples, were created to facilitate workflows in different businesses, industries, and contexts. This means they (and all process frameworks) intrinsically create different benefits and drawbacks for teams using them.

Here’s a summary of our thinking:

Scrum allowed us to set short-term goals with a time-bound period to complete them and a built-in cadence for inspecting and adapting. But in this new working world full of uncertainty, Scrum cadences were too difficult to match to the availability of new information from the business and the daily changes in peoples’ working-from-home lives. It seemed like the timeboxes were too top-heavy, as we put in all the effort up front to create and agree upon sprint goals that were almost immediately the wrong choice due to new information or unforeseen circumstances. We wanted the ability to shift focus as more information became available and were ready to leave behind the practical and emotional effects of mid-sprint shifts in goals or the need to carry over work from one sprint to the next.

Kanban permits a leaner way of working by focusing on the efficiency and optimization of the workflow itself. It necessitates the efficient preparation and prioritization of the system’s inputs, and it suggests (though it doesn’t require) frequent digestion of how things went, and feedback-gathering from the outputs to inform future work brought into the system.

Since typical cadence meeting activities happen on an ad-hoc, as-needed basis in Kanban, team members must take responsibility for intentionally communicating about their work and staying focused. When we removed artificial timeboxes with Kanban, we also experienced an equalization of the prep work to ready inputs to our workflow.

A side note on tracking:

Changes like this tend to cause anomalies in metrics tracking, both in terms of the numbers on paper and the procedures you’ll undertake to capture them. Know that it may also take practice for people to develop a muscle memory for the interactions and activities a new framework involves. Expect that this may impact your predictability for a time, until things equalize.

We decided to track throughput in terms of a straight count of completed backlog items, noting the grand total and the items completed in specific areas, like design and product research. We also decided to pay attention to median and average Cycle Time.

4. Does your current working environment (both physical and cultural) support a new framework or way of working?

Think about “support” from every possible angle. At the risk of answering this question with more questions, I’d suggest that you start by asking yourself, your team, and your stakeholders:

• Are you receiving sufficient business and product development guidance to inform the work you take on?
• Are you able to limit Work In Progress?
• Do your engineering practices and standards enable quality code, and are they efficient enough to support flow?
• Do you have enabling software to keep everyone organized and track your progress?
• Does your physical office space accommodate pairing activities, support remote worker connectivity to meeting rooms, and otherwise have the space for team activities? If everyone works from home, do they have adequate internet connectivity and the digital tools to meet and collaborate when they need to?
• Do managers know what you’re trying to achieve, and do they have the tools to mentor their direct reports to be successful in this new modus operandi? Will managerial roles and responsibilities change?
• Does your culture support failing fast and learning from mistakes?

If you answered “No” to any of the above starter questions, make an action plan for any changes needed to make the answer affirmative.

5. Always remember, process is not a miracle cure.

A process, framework, or methodology sets basic ground rules and recommends good practices to ensure they’re reflected in actions. But choosing one framework over the other won’t miraculously cure what ails you.

In fact, a change in process may address some previous issues while causing or leading to others! Prepare for these new issues when you can. But when you can’t, be honest about them and collaborate with your team to tackle them together.

How It’s Going

We’ve been using Kanban since just before Thanksgiving 2020. Some takeaways so far:

Going Well!

We may have removed the cadence layer from our schedules, but estimation has still proven critical! We typically estimate the effort, risk, complexity involved using the Scrum concept of story points, because we’d used Fibonaci scale for sizing for so long that everyone had that “scale” as a ready reference for pointing. We do this at “the last responsible moment,” during a short daily refinement session, as a last step before including it in the To Do column of our board. We try to spend as little time as possible on this to minimize waste — and we refine in the mornings to leave as much of the day uninterrupted as possible.

We’re a relatively small team of software engineers, and the demands on engineers’ time and effort are always tight. When we first approach an upcoming high-priority project, we list out the general features and sit with a small group of engineers to arrive at a best-guess time estimate for each feature, in weeks.

Then project management uses the time estimates to map out a rough answer to the question, “How long will this take?” We label all of these timeline estimates as “SWAGs” and communicate that we fully expect Actuals to be different, but this exercise still gives us a rough idea of upcoming dependencies, work sequencing, duration, and anything we’ll need to communicate with our stakeholders. We visualize this info using Miro or Roadmunk.

Still Working On It…

We’ve learned that force ranking is harder than it looks!

For a small team, we have a vast purview across all our owned and operated brands, platforms, and infrastructures. There’s a lot of nuance and priorities change quickly. We’ve gotten better at having open conversations with Product Management and Engineering leadership to articulate the reasoning for our priorities and adjusting our short-term focus as needed.

We use a “To Do” (meaning “Ready for Dev”) column to indicate work that has been refined and understood, and we reprioritize the work in that section frequently to match our latest information.

If you’re working to become more Agile, you’ve heard the advice to break down silos within your team — but in a framework like Kanban, it’s a necessity. A beautifully-organized and prioritized “Ready for Dev” column isn’t helpful if the next available team member lacks the knowledge or exposure to a given application area. We have a healthy culture of pair programming and synchronous and asynchronous knowledge sharing between engineers, and also between functional areas, so engineers and product designers (as one example) approach work jointly. Even so, this is a habit we’re working to strengthen.

Making the Move: Our Transition from Scrum to Kanban was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thanks for the scribbles, Mariam Garibov!

Component-based development centers around the creation of flexible, reusable components that will drastically improve many aspects of the development process. Read on to learn how moving to a component-based approach can benefit you and your team!

The LEGO® Analogy

1. Reusability

Think of each component as a single lego piece. You can reuse the same piece many times over many projects. Each individual piece is self-contained. It doesn’t need to know what the other pieces do and it doesn’t depend on the structure of the whole. You can choose the piece you want, fit it together with other pieces, and build something really cool!

2. Testability

Testing components individually is much more manageable than testing an entire system all at once. If you select a single lego piece, it’s simple to test and make sure it works. Likewise, if you develop self-contained components and individual pieces do what they are supposed to do, you can be pretty confident that they will fit together with all of the other pieces without any issues.

3. Efficiency

Using a component-based approach will speed up every step in your process. When components live in a central library, team members can use, add, or update them at any time during the process. As your component library grows, the rate of delivery will also grow as your cost and time-to-market go down. Eventually, project managers won’t have to write requirements, designers won’t have to worry about UX or functionality, developers won’t be building from scratch, QA testers will already be familiar with what to test, etc. Everyone benefits! Check out these design principles to learn how to get your team on the same page.

4. Consistency

Having a robust component library ensures user experience consistency across all of your projects by acting as the source of truth. You are all building from the same box of legos! Over time, your team will know exactly what is in the box and which pieces are best for the job.

5. Maintainability

Last but not least, component-based websites are easier to maintain and less risk to evolve. Let’s say you want to replace a red lego piece with a blue one of the same size. All you need to do is take the old one out and pop the new one in. You wouldn’t worry about your lego masterpiece crumbling to the ground afterward. You know it will fit and do its job. That’s exactly how it works with components! Using self-contained components makes it easy to change one thing without affecting the rest of the system.

Radial Design System

At New York Public Radio, we use our design system Radial to build, iterate, and optimize digital experiences, as well as to extend brand identity, deliver consistent UI/UX patterns, and optimize processes across disciplines. With Radial, our team was able to set up a new website and give it a brand-specific UI within 1 sprint (2 weeks) and they can continue to iterate on it at any time.

Moving Forward

If you’re ready to move forward with component-based development, start building your own library that is tailored to your specific needs within whatever framework your organization uses.

Alternatively, there are a few popular libraries you can use right now to get started:

• Material UI (React): https://material-ui.com
• Vuetify (Vue): https://vuetifyjs.com
• Angular’s Official Component Library: https://github.com/angular/components

There’s also Foundation (https://get.foundation) and Bootstrap (https://getbootstrap.com), and Storybook (https://storybook.js.org) is great for viewing, organizing, and developing your components.

5 Benefits Of Component-Based Development was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sometimes as developers, we start a bit of work thinking it will be easy. Sometimes it turns out to be not easy. The natural thing to do is to reach for our trusted tools, those reliable methods and strategies for digging ourselves out of holes. Sometimes, those tools are missing.

So we roll our own.

Some time ago, I wanted to update NGINX configurations. I was new to NGINX and figuring it out. Their documentation (though lovely) can be impenetrable. I grokked the NGINX config language by mimicking existing configurations. If I had a specific question about how NGINX might behave in a certain situation, it was hard to discover the answer on my own. NGINX does not support a usably interactive local environment or rapid feedback of any kind. If I wanted to learn how NGINX executes an arbitrary idea, I would need to deploy my NGINX idea to the Staging environment and then grab curl and log on to AWS, waving around my DevOps Dowsing Rod to try and sense if things are both working and not broken. This method was tediously slow and unreliable.

When I write software, there are many ways to ask a question about how things work or about how they might work. Sometimes I go to Stack Overflow or to a smarter coworker, but I love to ask a computer first. There are many ways to ask computers questions. A great one is Test Driven Development. TDD is lit! We can ask many questions quickly, and once a question is asked, we can be confident it will remain answered. Given a question on how something works, write a test to describe the behavior. Run the tests and make them green. Great stuff. If there is a corner case, a test case can expose it. When code turns red, iterate and improve.

I hacked at this particular NGINX task without my usual tools, i.e. TDD, until I started scratching around the corners of an edge case within NGINX itself… I couldn’t figure out what on Earth was going on. Things that I thought to work one way were behaving another. Questions that had already been answered became confused. Things were inconsistent from one Staging deploy to the next. It was impossible to get a definite answer about how things were or were not working.

Until I wrote unettest.

The Monolith and the Microservice

Here at NYPR, we have a Monolith that does many things. We are excising a part of it to turn into a discrete Microservice with the goal of eventually recycling enough parts to put the whole Monolith down.

We also have a playout system used by our radio team that sends us an update every few minutes. These requests come in through an NGINX server and are routed to the Monolith. For now and into the foreseeable future, we want to simultaneously support the Monolith and the Microservice. As a DevOps engineer on staff, I was asked to write a rule in our NGINX configuration to mirror the requests: they should go to both the Microservice and the Monolith. This way, the Monolith would continue to work while the Microservice was under development.

Seems easy. Referencing the NGINX docs, we could take the existing rule and add a mirror directive to a special internal location block.

location ~* /api/v1/impotant_update/([^\/]*) {
         proxy_pass $monolith$request_uri; # original behavior

         mirror /microservice_mirror/$1; # NEW LINE!

         ...some other configurations
}

and then define the mirror route like this

location ~* /microservice_mirror/(.*) {
         internal;
         proxy_pass $microservice/new/api/update?value=$1;

         ...some other configurations
}

I fulfilled the requirements (or at least tried to):

• send incoming request to two servers, ($monolith) and ($microservice)
• slightly reconfigure the incoming request to fit the API difference

With that done, I committed my NGINX changes and deployed to Staging. But… it did not work. The requests were not being mirrored correctly. The NGINX documentation, through complete and easy to reference, is not beginner friendly. I thought my conf files were malfunctioning due to my own ignorance. While it turned out to be a bug(?) or undefined behavior(?) in NGINX itself, I did not know this at the time. Lacking my familiar toolset that I use to learn unfamiliar technologies (tests!), I tried to fix the conf files with that classic fallback development strategy— guess and check.

As I guessed and checked, NGINX’s behavior became stranger and stranger.

A major hurdle to my progress was the slow process of iterative networking development. It was not user-friendly. It was user-hostile. The cost of making a single guess at a solution was high. I had to:

• Commit a change
• Deploy to Staging (~15 minutes wait)
• Run my manual tests (curl)
• Wade through CloudWatch logs to find the recorded behavior

Searching CloudWatch is not an easy or reliable way to detect subtle nuances in configuration changes. Often, the test results would not appear at all, I would be searching old time frames, or old tests would be mixed in with the current tests. I was flooded with unrelated logs.

It was a bad way of asking questions. This development cycle was kludgy. I was able to suss out WHAT the behavior was but not WHY. Not even WHAT EXACTLY.

An NGINX Corner Case

The strange symptom I observed was that my Microservice was getting requests that look like $microservice/new/api/update?value=$1. What? NGINX is supposed to INTERPOLATE the money variables?? I should be getting ?value=mycrazyvalue not ?value=$1. Even stranger, I found that if I swapped the mirror, it worked.

That is, when mirroring [a -> b], the values do not get parsed. Mirroring [b -> a] would successfully parse the route. Weird. However, if I wanted to verify that [x -> y] worked or did not work, it would be a 15 minute deployment’s wait to learn the answer.

I wondered, if [a -> b] has a functional $request_uri but a broken $1, does [b -> a] fix $1? Does [b -> a] break $request_uri? Or does $request_uri still work? Does $1 and $request_uri break in the same context? What conditions cause $1 to break? Are there conditions that similarly break $request_uri? These questions were too numerous, too interconnected, and too subtle to wait 15+ minutes between each time I ask. [1]

I kept coming back to the question, “Why?” Why is NGINX behaving like this? NGINX was not giving easy answers. The answers I got were half-answers (for one, mirrors go unlogged by default) and they were hard to find. By the time I found an answer, I had forgotten my question (“was $1used here or was it being redirected in this one?”). The differences were slight, the moving pieces were myriad, and I was getting frustrated.

A Better Way to Ask Questions

How to answer these questions? How to ask them in a less painful way?

How to experiment iteratively and usefully on an NGINX configuration with a learner’s mindset? How to do so quickly? One option would be to load changes directly into the Staging NGINX server. Another way could be adding a dummy/test NGINX server to the network. These are not good solutions — they muck up the nonprod environment too much. More importantly, they do not give better logs or analysis or insight into what is happening.

Another idea would be to run NGINX locally. This seems like a prime candidate for a Works On My Machine certification. It is a dubious solution. NGINX is server software and should be running on servers.

This sounds like it might be a great fit for docker! But if we shove the NGINX files into docker, how would NGINX talk to services on the internet?

I was sick of trying to hook into real-world networks and real-world services. There were too many complications, side effects, and fragile bits. I wanted to rigorously isolate the NGINX files, as a unit. They wanted to squirm away. I was bent on pinning them down for interrogation.

Looking at the internet from NGINX’s perspective, the Monolith and the Microservice are referenced abstractly, as interfaces. It does not matter what these services do when they have been sent the correct request (that would be a side effect). The crucial piece of information to know is that they have been sent the correct request. When they have, they will return a certain response. The internet is abstract, the servers on it conform to an interface.

Why not mock those servers?

The relevant detail regarding Monolith is that it is called with /api/v1/important_update/mycrazyval and the only important detail about Microservice is that it is invoked at the same time, but with /new/api/update?value=mycrazyval.

If we were writing test driven code, we would mock those external systems. Why should network rules be exempt? Let’s Mock these services!

services:
  - monolith:
      routes:
        - name: mirror_me_please
          route: "/api/v1/important_update/<crazyval>/"
          method: "GET"
          status: 200
  - microservice:
      routes:
        - name: place_to_mirror_to
          route: "/new/api/update"
          method: "GET"
          status: 200
          params:
            - crazyval

This yaml config conforms to a standard I created for the test framework I wrote called unettest, a test harness for NGINX, APIs, and online services.

This yaml config tells unettest what the network looks like: what services are on the network and what their interfaces look like. Now we can develop confidently against them.

Things that do not matter:

• that Monolith does 10 million other things
• what Monolith or Microservice does when these particular endpoints are invoked
• that Microservice is a Lambda or that Monolith is a legacy pile of spaghetti
• what Monolith’s dependencies and requirements are
• that these might be black-box services that cannot be controlled or might (!!) be only available in Production environments

Under the hood, unettest parses that valid and complete configuration file and creates two little local containerized web services conforming to their definitions. They are not functional, but they behave as if they were and their behavior is surveilled by unettest. Their ports are exposed on localhost. More interestingly though, unettest spins up an NGINX server. It must be configured with your own NGINX conf files. NGINX is exposed on localhost:4999.

If I invoke

localhost:4999/api/v1/important_update/mycrazyval

I can see in my terminal immediately which services are called and how they are called. If I want to switch [a -> b] or [b -> a], I can edit the NGINX files on my laptop, refresh unettest, and immediately see what happens when I curl this little network.

Unit Tests

The Mocks we defined above are Spies; they can be used to observe the network’s behavior.

tests:
  - test_mirror:
      send: "GET"
      target: "/api/v1/important_update/urgent/"
      vars:
        crazyval: urgent
      expect: 
        - microservice.place_to_mirror_to:
          called_times: 1
          method: "GET"
          return_status: 200
          called_with:
            params:
              - crazyval
        - monolith.mirror_me_please:
          called_times: 1
          method: "GET"
          return_status: 200

This is a definition of a test that can be run against the network of Mocks.

It will curl "/api/v1/important_update/urgent/" against the configured internal NGINX server and then assert that the route defined in the monolith server block and microservice are called in the ways they should be called. This information is collected from the within the Mocks themselves so we can feel safe knowing that when we run these tests, they have run all the way into and out of the NGINX scripts under test. If the Mocks are correctly configured, the route is guaranteed to work as it says it does. It is now under test coverage. You can run this unettest script in your CICD pipelines.

Takeaway

unettest was born as a tool for me to put my untested network rules under locally runnable tests. But I see many ways unettest can help you develop confidently on your own computer, understanding how things will work in the strange twists and turns of the Internet. Networks, servers, nonprod and production environments can be made into configurable interfaces to be worked against.

You could easily write a lambda plugin (or ask me! I take feature requests!) to run lambdas locally on your laptop. AWS has announced SAM Local, but from what I’ve read, it looks too heavy for what I need. It does not work well with our existing CI setup. I don’t want to replace my deployment infrastructure in order to run a lambda on localhost. But it is also annoying to write around the specialist AWS infrastructure (hello, lambda specific request json — statusCode, body, content).

unettest can jack up a Lambda or an NGINX configuration or anything else you can fit on a container into a test harness. Now you can easily get under the hood of your network. You can see how things work in the cloud from the isolated safety of your local dev environment. u got a network? u net test.

If you want to get started with unettest, check out the website and documentation at unettest.net. There is a tutorial! Please reach out to me personally if you have trouble or questions. unettest is a high-functioning beta so send me bug reports! Feature requests! Whatever you need!

[1] So… what’s the verdict on that weird NGINX behavior? I isolated things in unettest and it looks like if you pass a $1 to an internal mirror, it will not evaluate/expand it. However, $request_uri works from both the mirror and parent block. Always.

$1 cannot be accessed directly from the mirror as if it is in scope, $request_uri can be accessed as if it is in scope.

You can pass a literal into (.*) in the location line--it will receive that value and parse it into a local (mirror) $1. That is, mirror /microservice_mirror/LITERAL will be received by location ~* /microservice_mirror/(.*) and parse out LITERAL into the $1 value.

But if you try to pass in $1 from the parent block, it remains $1 in the mirror, as if you passed it the string literal "$1". I think. Like I said, I am still an NGINX beginner.

Network Rules as (Tested) Code was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

I interface with a lot of people at New York Public Radio in my role as a Digital Systems Support Analyst. These systems include, but are not limited to, a CRM for our membership database and four different content management systems for producers to publish their news stories and podcast content to our websites and apps. I monitor our internal user support queue and work super closely with people who submit all types of feature requests and bugs, which I then relay back to the Digital team. And because of this, I want to make sure I’m providing an excellent support experience to my colleagues.

Here are several tips I’ve learned along the way that help me be the best advocate and support provider for my colleagues who use these systems day in and day out.

1. Leave all prejudices behind

The users I work with are my colleagues and peers that I see almost every day, not members of our audience. These are the same people I work with outside of support needs to partner on new show launches, marketing and project initiatives, and brainstorming workflow improvements. I have found that in situations where there may be friction or other issues, it’s always best to approach the support request with a fresh perspective. Leave behind any past contentions and you’ll simply have a better interaction.

Assume best intentions! Remember that not everyone has the same background, experience, or even access to systems and training. It sounds obvious but there are times when that can be easy to forget. If you’re able to teach someone to be self-sufficient or help them find ways to improve their workflow, it can be a tremendous help to their work and in turn, your work. Instead of being surprised that there’s something they don’t know how to accomplish, provide them with the tools they need in order to be successful.

2. Be authentic and empathetic

Always remember that they’ve come to you for help and that they may be frustrated. Understand that they either don’t have the tools they need to do their job, that a feature isn’t working as expected, or that a tool could be created to improve their workflow. This will put yourself in their shoes and allow you to become sympathetic to their needs. If you are providing an authentic experience, the exchange will be more pleasant for everyone involved. If your end users are also your colleagues, they probably have a good understanding of who you are as a person. This also means that they will easily pick up when you are not being authentic and transparent.

3. Have their backs and go to bat for them

They have come to you with things that are real blockers to their workflow. They are trusting you to bring their concerns and ideas to the rest of the team. Listen to what they are saying and even better, try to shadow them as they are working.

There was an additional feature in our CRM that would improve user workflow and provide a more efficient way of bringing in donations. This feature wasn’t seen as particularly useful to some people because their day to day responsibilities didn’t rely on this feature. Once I sat down with the requestor and shadowed their workflow, it helped me see what was missing and how this feature would improve their job. Because I took those steps, I was able to really understand why this feature was needed and better advocate for the user’s needs with the rest of the team.

Earning and maintaining trust with end users and your colleagues will allow for a better work experience for everyone involved. Plus, it always feels good at the end of the day to know that you’ve worked your hardest to get a bug fixed or made it easier for them to do their job.

Of course there is always room for improvement and not every day is perfect. It’s important to be open to receiving constructive feedback from managers and peers. At New York Public Radio we believe it’s important to celebrate excellence. Knowing that you’ve incorporated these tips into your work ethic, you can start the next work day with confidence of a job well done.

Things I’ve Learned In Order to Provide Better Support to End Users was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

Teams that follow Agile development principles know that retrospectives are an integral part of the process for continuous improvement. The digital team at New York Public Radio has been doing retros for years now as part of our product strategy and agile software development process. But what about the other non-agile teams at the New York Public Radio? We have a ton of projects and initiatives happening at the organization that are not using any Agile frameworks. Do these editorial and business teams have the tools they need to properly reflect on their process, learn from their mistakes, and highlight opportunities for change? The answer is, sort of, but not easily.

I got really excited when an idea was floated in a CEI (the Culture, Equity and Inclusion Council) meeting to introduce a culture of retrospectives across all departments at New York Public Radio. This was a great opportunity to test Agile tools in an organization that, outside of our Digital team, does not formally use Agile methodologies. Nor does it, for the most part, have a good understanding of what the Agile mindset is.

We formed a small working group of five people from the Council representing different parts of the organization (Digital, Content, Legal, and Listener Services) with varying degrees of experience with Agile. Two of the five had never attended a retro before. The goal for this team was to create and launch an informal initiative to promote a culture of retros across New York Public Radio in order to foster an environment of continuous improvement.

The working group came up with a couple tactics, outlined here:

1. Draft a one-sheeter guide that explains what a retro is and what it’s used for.

The one-sheeter contains all the basics of what a retrospective is, what it’s used for, and why it’s such an important practice for our organization to adopt.

In the guide, we provide recommendations on the sorts of projects that would benefit from retros. For instance, after a fundraising pledge drive or a podcast launch, teams should regroup to celebrate what worked well and identify areas that did not. What learnings were gained by the team? What changes can they make for the next time they launch a podcast, or even a new episode of a podcast?

The guide includes best practices and foundational ground rules. We ask that teams embrace a positive spirit of continuous improvement and be open to share in a safe space. We include ground rules (from Atlassian’s Team Playbook):

• Don’t make it personal, don’t take it personally.
• Listen with an open mind, and remember that everyone’s experience is valid (even those you don’t share).
• Set the boundary of your discussion — is it that last sprint? the last quarter? since the project started? Be clear how far back you’re going to go.
• Retros are BLAMELESS…encourage the team to embrace an improvement mindset, away from blame.

We recommend that they come out of the retro with clear action items. Most importantly, we ask that they incorporate this feedback into the next iteration or project.

We also include suggestions for retro formats next to each type of project: Use the Sailboat or Easy as Pie after a launch, or the Superpowers activity for team resets.

2. Socialize and evangelize

We have a guide, now what? How do we let other teams know about it and how do we help them put these tools into practice?

Here are some tactics the working group agreed to try:

• Hold lunch-and-learns to socialize retrospectives, provide examples and outcomes
• Form a volunteer coaching group to facilitate retrospectives across the organization and coach individuals who are interested in holding one
• Create a slack channel for retro facilitation and information-sharing
• Attend various department standing meetings and introduce the concept of retros to those teams

The first thing we did was hold a retrospective with the CEI council members as many had never attended one before. The subject of the retro was the EVA’s (Employee Value Awards), an initiative that was led by this council and had taken place a few months back.

We kicked off the retro with an overview of what a retrospective is and set some ground rules. I used the 4L’s format, an activity that is simple and easy to grasp.

The conversations were lively and participants were engaged. We surfaced a few key issues and aligned on concrete next steps to improve the EVA process for the next round in the fall. The retro was a success!

An added win was that a colleague who attended this retro (it was her first time) was very inspired by the whole thing. A few weeks later she planned a retro for her team on the fall membership fundraiser that had just completed. She made sure to include members representing four different divisions within the larger membership department who don’t normally get together after a fundraiser. As a result, the retro gave a forum for open discussion amongst the divisions and helped create more empathy for co-workers in the other disciplines.

”Because of the inclusive format, people who normally don’t speak up felt compelled to share their thoughts and pain points,” she commented. “You could tell there was an appetite for learning and understanding the challenges everyone faces during the membership drive. Many people chimed in with possible solutions or suggestions even if it was not their area of work. And because so many questions surfaced, there were opportunities for the leaders in the room to shed light on decisions. We were able to explain the why!”

So is it OK to ask teams to do retros when they don’t otherwise practice Agile?

The answer is a resounding YES. We realize that we can only take this initiative so far in an organization that is not fully adapting Agile. Without the infrastructure to support and operationalize the Agile process and framework holistically, we will face challenges in formalizing this practice in a meaningful way. Nevertheless, we can encourage managers and team leaders to include this activity as part of their toolkit to improve the way we work at New York Public Radio. Yes, there are shortfalls to this approach, but ultimately we feel this is one big step in the right direction. It is, after all, instilling a culture of introspection and self-betterment.

Additional Resources

Sprint Retrospective ideas on FunRetro.com
How to Run an Agile Retrospective — Atlassian.com Team Playbook

Every Team Should Do Retros, Agile or Not was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

At New York Public Radio (NYPR), we have a variety of brands and digital products such as WNYC, WQXR, WNYC Studios, etc. This year, our digital team is updating the experiences of our brands with a more consistent UX to better serve our diverse audiences. In order to do that, we are looking at the data to understand how our users interact with our digital products today.

Why Make a Data Dashboard for Designers?

It is important to look at how your digital experiences perform to identify patterns and trends. This is not meant to take away from the value of generative user research which is valuable if you want to understand your user’s journey and identify those underserved user needs. With data, we can get a sense of what users are actually doing and how they use our digital products. Keeping track of these behaviors and patterns and how they evolve over time can help inform new ideas for user research.

“To design an easy-to-use interface, pay attention to what users do, not what they say.”

~ Jakob Nielsen

For our team, designing for multiple brands within a large media company can be challenging when data and insights on user behaviors can easily be siloed amongst individual teams rather than shared broadly. Additionally, having a four person design team means that we need to be able to draw relevant insights in a way that enables quick decision making.

As a design team, we strive to be human-centered and data-driven. As much as we love spending our hours mining Google Analytics for information, we need a better way of keeping track of how users are finding us and interacting with our experiences. Having something tailored to our team’s data needs would save us time, confusion, and maybe a few tears. Also, it would provide us with visuals using the latest data for any spur-of-the-moment proposals or presentations. Luckily, most of our team has prior experience with dashboards. For these reasons and with the help of my prior experience, I created a UX Data Dashboard and took an iterative approach to this process.

Process for Making the Dashboard

Surprisingly, there are not many articles around creating a data dashboard for Design and UX teams. Below is the process I followed for the creation of the dashboard.

1. Define: What are the goals, objectives, and data points that the team wants to track? What questions typically come up when you start a new design project? This will help you think about what data you need and how to format it so that you can quickly extract these insights. This is also a great way to make sure you are incorporating your team in the process and starting to get feedback on the final output. Keep in mind, you might not answer all the questions in the first design of your dashboard and that is okay!
2. Research: Once you have questions that you want to answer, figure out where and how you can access the data you need. For this, I collaborated with our data team, engineering team, and product managers. In some cases, I reframed our original questions as we discovered gaps in the available data.
3. Select a Medium: Determine the best medium for creating a UX Dashboard. There is no right answer here, but it is important to think about what will work best for your team. You do not want to create more manual work in the future so find something that will automatically update and be ready to use when it is needed. We use Google Data Studio because it seamlessly pulls from Google Analytics (GA) and our data warehouse. We also add links to our qualitative studies for quick reference.
4. Explore and Experiment: Take time to experiment with the data and see what you can do with it. We have multiple properties that we track via GA and we need a way to holistically view performance. After a few tries, I was able to get a view of how the number of sessions vary overtime for 5 different brands.
5. User Testing: After creating your first “design” of the dashboard, do a quick user test. See how quickly your teammates can extract insights from the data and ask if there is any additional data that is needed for better context. Some of my teammates pointed out redundant information or gave me tips on how to better structure or visualize the information to support our team’s needs.
6. Validate your data: Collaborate with other teams such as engineering or data & research to make sure you know exactly what your data is telling you and that it is the right information. For example, thanks to our engineering lead, I learned that ‘Search Queries’ in GA are actually just what users search within our sites. To get the search terms that bring people to our sites, I had to access Google Console data. From our data team, I now know that it is better to look at some of our data by ‘sessions’ rather than ‘pageviews’ due to how each one is counted in GA.
7. Share it out!: Make sure you give your team an onboarding to the final design and make it easily accessible.

Our Result From This Process:

Many of the questions from the first step made it clear that our team wants a quicker way to compare data across different brands. While GA provides a lot of data for each of our properties, it is difficult to do comparisons between two or more.

To address this need, the first page on the dashboard is an overview of key data points across our 9 different digital properties. At first glance, we can quickly see and compare the following:

• Session durations
• Bounce rates
• Top search terms
• Popular days/times
• Traffic sources
• And more

Following the overview page, there are additional pages for each brand. For brands that have mobile apps, I consolidated that information onto one page. For each brand page, the information is the same as above, as well as:

• Pages per session
• Number of pageviews by new and returning users
• Top articles
• Landing pages
• Exit pages
• Devices
• User demographics

This is just the start and we are continuing to iterate on the content and structure of the dashboard based on the team’s needs.

Some things to consider:

• Build upon what exists and works for your team: We already have a repository where different teams are documenting any new surveys and qualitative studies. Rather than reinventing this, we incorporate links to the repository into our dashboard.
• Start with an MVP = Minimum Viable Product: An MVP is the lowest effort product you can build that can deliver the most amount of value. Of all the questions and data points identified by the team, which ones are the most needed and easy to answer? This helps ensure you do not put in too much work to then have to completely rearrange the dashboard.
• Keep it Agile: Do not try to make it perfect the first time and keep it agile by iterating as you get feedback. We made an MVP and will see how this works for a few months. As we go along, we will keep track of what works and what needs improvement. I have already made a few updates in the past month based on requests from the team!
• Beware of research paralysis: It is easy to get hung up on the data and spend a lot of time making it “perfect”. There are many ways to look at the data and many edge cases to consider. At some point, you need to start with just enough to provide value and add as you go.

Hopefully this helps your team get started on a UX Dashboard. We are constantly iterating on ours and it has been really helpful for our Design team thus far. Happy dashboarding!

How to Make a UX Data Dashboard for Your Design Team was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR The secret to getting a team to create design principles they understand and care about is to connect them back to individuals’ values, things everyone can relate to.

A Google search of “design principles” results in many beautiful examples of tenets forged within the hiveminds of today’s design-driven tech companies. They’re succinct. They’re powerful. They’re “carve-into-marble” worthy.

I’m assuming if you’re reading this article that you have read another preachy explainer on design principles before, but for the sake of comprehensiveness, a quick refresher. Design principles are a set of statements that offer a point-of-view on best practices. They are guidelines for work, values a team can all agree on, and in this case, qualities of the successful design system we are building at NYPR.

It wasn’t until I took on the task of creating a set of principles that I saw my position (we’ll call it Point A) and the far off target of awe-inspiring axioms (Point B) and thought, “How?”

Moreover, how do you bring an entire team from Point A to Point B with you? Design principles have always seemed like a religious icon pedestalized by designers. How could a group of us (product managers, engineers, scrum masters, and designers) develop a set of principles we all agree on?

The answer, as I figured out, is connecting in what we cared about.

The first step in creating these principles is getting people in a room to think. In modern terms, this is called a workshop.

Connecting to Principles

I did a lot of soul-searching and googling to visualize what the workshop could be. Explaining what design principles are can be confusing and if done too “hand-wavy,” might even sound a bit fluffy.

“I used to be the biggest skeptic of the whole “list of principles” thing. Whenever somebody would begin their design presentation to that effect, I’d lean back in my chair and think, “great, a barrage of words designed to induce head-nodding.” — Julie Zhuo

“Principles” is not a very human term. The average person doesn’t have principles. The average person has values, goals, motivations, hopes, and fears. Principles are statements tied to things bigger than yourself, but for them to mean anything, you need a tie to them as well.

I figured it would help to get everyone on the same page. I came across a workshop activity from Atomic Object called Hopes & Fears. The exercise itself is pretty self-explanatory. Everyone receives sticky notes, a Sharpie, and 10 minutes to jot down their hopes and fears around the project in question. In our case, it was building our white label design system, Radial.

Creating a safe environment is essential for doing Hopes & Fears. Giving permission to give honest answers helps, even if it seems gratuitous.

The last step of the activity requires the most vulnerability, putting your hopes and fears on the wall and talking about them. When we took this step in the workshop, people immediately started to connect. They found they shared a lot of similar aspirations and doubts about the project. This became even more evident when our facilitators started clustering the stickies around overarching themes.

Brainstorming Together

With our big, beautiful wall of shared hopes and dreams in front of us, we started into the principle-brainstorming activity united around values we all shared. I had a soft framework in place to help us filter things down.

Good principles are…

• Direct, Memorable
• Help make decisions
• Aren’t truisms
• Explainable, ownable

We had some great ideas come out of our brainstorming session; ideas that protected our hopes and accounted for our fears. We tweaked them, dot-voted, and developed some tenets of our own.

After our team’s success, I still had some lingering fears. Our principles were there, but would anyone use them?

A developer on our team quickly extinguished the thought a few days later when I overheard them say, “We could build it that way, but that’s pretty rigid, and one of our principles is flexibility.”

Principles as a decision-making tool? Check.

If you ever have the opportunity to create design principles with a group of people, take the time to get on the same page, understand the why behind design principles, and learn each other’s values. Our Hopes & Fears activity was productive, but it’s not the only one of its kind. Getting a team around design principles can be tricky, but once established, can be a source of shared understanding that is inclusive to everyone involved.

Our principles provide a litmus test for every critical decision around our design system, Radial. They might adapt and evolve along with the project, but with any luck, they’ll get carved into marble eventually.

Principles Workshop Activity Ideas:

https://spin.atomicobject.com/2020/03/03/design-thinking-your-radar/
https://www.funretrospectives.com/telos-thinking/
https://spin.atomicobject.com/2018/04/03/design-thinking-rose-bud-thorn/
https://www.ibm.com/design/thinking/page/toolkit/activity/prioritization

Design Principles Everyone Can Understand was originally published in New York Public Radio Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.