Entries by admin

Hidden vs. Disabled In UX

/0 Comments/in /by

Original Source: https://smashingmagazine.com/2024/05/hidden-vs-disabled-ux/

Both hiding and disabling features can be utterly confusing to users. And for both, we need very, very good reasons. Let’s take a closer look at what we need to consider when it comes to hiding and disabling — and possible alternatives that help enhance the UX.

This article is part of our ongoing series on design patterns. It’s also an upcoming part of the 10h-video library on Smart Interface Design Patterns 🍣 and the upcoming live UX training as well. Use code BIRDIE to save 15% off.

Show What’s Needed, Declutter The Rest

You’ve probably been there before: Should you hide or disable a feature? When we hide a feature, we risk hurting discoverability. When we disable it without any explanation, we risk that users get frustrated. So, what’s the best way to design for those instances when some options might be irrelevant or unavailable to users?

As a rule of thumb, disable if you want the user to know a feature exists but is unavailable. Hide if the value shown is currently irrelevant and can’t be used. But never hide buttons or key filters by default as users expect them to persist.

Unlike hidden features, disabled features can help users learn the UI, e.g., to understand the benefits of an upgrade. So, instead of removing unavailable options or buttons, consider disabling them and allowing the user to “Hide all unavailable options.” Be sure to explain why a feature is disabled and also how to re-enable it.

Another thing to watch out for: When we allow users to switch between showing and hiding a feature, we also need to ensure the switch doesn’t cause any layout shifts.

For both hiding and disabling, we need very thorough considerations of available alternatives, e.g., enabled buttons, read-only state, better empty states, hide/reveal accordions, error messages, and customization. We need to show what’s needed and de-clutter the rest.

Whenever possible, I try to keep buttons and features in their default state — enabled, accessible, and legible. When a user interacts with that feature, we can explain why they can’t use it, how to enable it, and how to keep it enabled. Possible exceptions are confirmation codes and loading/processing states.

Hiding vs. Disabling Roadmap

As Sam Salomon suggests, if you’re unsure whether hiding or disabling is the best option for your use case, ask yourself the following question: “Will a given user ever be able to interact with this element?” Depending on your answer, follow the steps below.

✅ Yes

→ Disable it (as disabled buttons or read-only state).
↳ For temporary restrictions or filter incompatibility.
↳ When a value or status is relevant but not editable.
↳ When an action isn’t available yet (e.g., “Export in progress…”).

🚫 No

→ Hide it (remove from a toolbar, collapse in accordion).
↳ E.g., due to permissions, access controls, safety, and security.
↳ For inaccessible features: e.g., admin buttons, overrides.
↳ Hide such controls by default and reveal them once a condition is met.

Key Takeaways

Hiding important features hurts their discoverability.
Disabling features is frustrating without an explanation.
But some options might be irrelevant/unavailable to users.
Users might expect a feature to exist but won’t find it.
We need to show what’s needed and de-clutter the rest.
Avoid disruptive layout shifts as you show and hide features.
Don’t remove unavailable options or buttons automatically.
Instead, disable them and allow it to “Hide all unavailable options.”
Allow users to hide sections with a lot of disabled functionality.
Explain why a feature is disabled and how to re-enable it.

Hidden vs. Disabled In Design Systems

The design systems below provide useful real-world examples of how products design their hidden and disabled states.

Carbon (disabled state)
Carbon (read-only state)
Unity
Vaadin
SAP
Motif
Emplifi

Useful Resources

Disabled Buttons And What To Do Instead, by Adam Silver
Hidden vs. Disabled States, by Maria Panagiotidi
Making Disabled Buttons Inclusive, by Sandrina Pereira
Hide or Disable, by Sam Solomon
The Disabled State In UI Design (Sketchnotes), by Krisztina Szerovay
Usability Pitfalls of Disabled Buttons, by yours truly Vitaly Friedman
Alternative Design Patterns For Disabled Features, by Katie Jacquez
Designing Filters UX That Works, by yours truly Vitaly Friedman
UI Traps: Disabled Buttons and Inputs, by James Carleton

Meet Smart Interface Design Patterns

If you are interested in similar insights around UX, take a look at Smart Interface Design Patterns, our 10h-video course with 100s of practical examples from real-life projects — with a live UX training later this year. Everything from mega-dropdowns to complex enterprise tables — with 5 new segments added every year. Jump to a free preview.

Meet Smart Interface Design Patterns, our video course on interface design & UX.

Jump to the video course →

100 design patterns & real-life
examples.
10h-video course + live UX training. Free preview.

Printify Versus Printful for Bulk Orders

/0 Comments/in /by

Original Source: https://ecommerce-platforms.com/articles/printify-versus-printful-for-bulk-orders

Currently, Printify and Printful are the two main online platforms that offer print-on-demand (POD) services. So, if you’re eager to kickstart your POD dropshipping business, these platforms may be the best place to start.

Like many POD platforms, Printify and Printful offer bulk order policies to accommodate clients who wish to purchase large volumes of printed items.

Printful has a slightly lower monthly subscription fee and can create more than 330 product mockups for bulk orders, whereas Printify can offer up to four mockups per product.

This is why it’s important to compare Printful versus Printify features as well as their order processing and shipping times.

For example, research shows that Printful processing shipping times are shorter than those of Printify by at least two days. Printful takes two to five business days, while Printify takes two to seven business days.

In this article, we’ll dive into the key differences of how Printful and Printify complete bulk orders.

How Does Printful Fulfill Bulk Orders?

Printful fulfills bulk orders through its vast network of printing facilities and fulfillment centers around the world. Here are the key steps the platform takes to fulfill large orders:

Order Placement

You will place your bulk orders through the Printful platform, specifying the quantity and customization details for each item. Because the platform is responsible for dropshipping, you have to provide the shipping details of your orders.

Production

Printful will forward your order to one of its printing facilities. The platform will most likely use the printing facility that’s near the customer for faster delivery. The facility will then produce the custom items according to your specifications.

The POD platform for Printful offers various printing methods like direct-to-garment (DTG) printing, embroidery, and cutting and sewing. The method used for your order depends on the type of item ordered.

Quality Control

Printful has put quality control measures in place to ensure all its products meet the required standards. Each item is inspected for print quality, color accuracy, and any defects before it is approved for shipping.

Packaging

If you’re satisfied with the quality of your products, they’ll be securely packaged for shipping. Printful offers standard packaging options as well as custom packaging solutions for bulk orders, such as branded packaging or custom enclosures.

Shipping

Printful delivers bulk orders through various shipping carriers. The choice of the carrier depends on the destination and your customer’s preferences. You can also choose from the various delivery methods offered by Printful, including economy, standard, and express shipping.

Your bulk order will then be delivered to the customer’s specified address. The customer can monitor the status of their package using the tracking information provided by Printful.

Furthermore, the platform’s customer support team is available to assist your clients with any issues they may have regarding their orders.

How Printify Fulfills Bulk Orders

Like Printful, Printify relies on its POD partners to fulfill bulk orders. It also follows the same order fulfillment steps as Printful.

However, you need to check the platform’s bulk order policies to know what qualifies as a bulk order.

This way, you can provide your customers with the right information when listing your products. It also prevents any publishing error on Printify. According to Printify, bulk ordering is available on select items, including:

Mugs

T-shirts

Tote bags

Tank tops

Towels

Pencil cases

Journals

Note that these items are available for bulk ordering when you order more than sixty items from the same print provider.

Printify has a team of in-house design experts who regularly test print providers for quality control by giving them samples of complex designs.

Any printing service provider whose performance doesn’t meet the platform’s quality standards will be removed from the platform.

Printify passes each order‒including bulk orders‒through three quality checks, starting from the time a blank product arrives at the printing facility to when the final product is ready for shipping.

In Summary

It’s important to keep in mind that the fulfillment process may vary depending on factors such as the products ordered, the print provider selected, and the shipping method chosen.

For the most up-to-date print-on-demand platform comparisons, check out ecommerce-platforms.com today!

The post Printify Versus Printful for Bulk Orders appeared first on Ecommerce Platforms.

Building A User Segmentation Matrix To Foster Cross-Org Alignment

/0 Comments/in /by

Original Source: https://smashingmagazine.com/2024/05/building-user-segmentation-matrix-foster-cross-org-alignment/

Do you recognize this situation? The marketing and business teams talk about their customers, and each team thinks they have the same understanding of the problem and what needs to be done. Then, they’re including the Product and UX team in the conversation around how to best serve a particular customer group and where to invest in development and marketing efforts. They’ve done their initial ideation and are trying to prioritize, but this turns into a long discussion with the different teams favoring different areas to focus on. Suddenly, an executive highlights that instead of this customer segment, there should be a much higher focus on an entirely different segment — and the whole discussion starts again.

This situation often arises when there is no joint-up understanding of the different customer segments a company is serving historically and strategically. And there is no shared understanding beyond using the same high-level terms. To reach this understanding, you need to dig deeper into segment definitions, goals, pain points, and jobs-to-be-done (JTBD) so as to enable the organization to make evidence-based decisions instead of having to rely on top-down prioritization.

The hardest part about doing the right thing for your user or customers (please note I’m aware these terms aren’t technically the same, but I’m using them interchangeably in this article so as to be useful to a wider audience) often starts inside your own company and getting different teams with diverging goals and priorities to agree on where to focus and why.

But how do you get there — thinking user-first AND ensuring teams are aligned and have a shared mental model of primary and secondary customer segments?

Personas vs Segments

To explore that further, let’s take a brief look at the most commonly applied techniques to better understand customers and communicate this knowledge within organizations.

Two frequently employed tools are user personas and user segmentation.

Product/UX (or non-demographic) personas aim to represent the characteristics and needs of a certain type of customer, as well as their motivations and experience. The aim is to illustrate an ideal customer and allow teams to empathize and solve different use cases. Marketing (or demographic) personas, on the other hand, traditionally focus on age, socio-demographics, education, and geography but usually don’t include needs, motivations, or other contexts. So they’re good for targeting but not great for identifying new potential solutions or helping teams prioritize.

In contrast to personas, user segments illustrate groups of customers with shared needs, characteristics, and actions. They are relatively high-level classifications, deliberately looking at a whole group of needs without telling a detailed story. The aim is to gain a broader overview of the wider market’s wants and needs.

Tony Ulwick, creator of the “jobs-to-be-done” framework, for example, creates outcome-based segmentations, which are quite similar to what this article is proposing. Other types of segmentations include geographic, psychographic, demographic, or needs-based segmentations. What all segmentations, including the user segmentation matrix, have in common is that the segments are different from each other but don‘t need to be mutually exclusive.

As Simon Penny points out, personas and segments are tools for different purposes. While customer segments help us understand a marketplace or customer base, personas help us to understand more about the lived experience of a particular group of customers within that marketplace.

Both personas and segmentations have their applications, but this article argues that using a matrix will help you prioritize between the different segments. In addition, the key aspect here is the co-creation process that fosters understanding across departments and allows for more transparent decision-making. Instead of focusing only on the outcome, the process of getting there is what matters for alignment and collaboration across teams. Let’s dig deeper into how to achieve that.

User Segmentation Matrix: 101
At its core, the idea of the user segmentation matrix is meant to create a shared mental model across teams and departments of an organization to enable better decision-making and collaboration.

And it does that by visualizing the relevance and differences between a company’s customer segments. Crucially, input into the matrix comes from across teams as the process of co-creation plays an essential part in getting to a shared understanding of the different segments and their relevance to the overall business challenge.

Additionally, this kind of matrix follows the principle of “just enough, not too much” to create meaning without going too deep into details or leading to confusion. It is about pulling together key elements from existing tools and methods, such as User Journeys or Jobs-to-be-done, and visualizing them in one place.

For a high-level first overview, see the matrix scaffolding below.

Case Study: Getting To A Shared Mental Model Across Teams

Let’s look at the problem through a case study and see how building a user segmentation matrix helped a global data products organization gain a much clearer view of its customers and priorities.

Here is some context. The organization was partly driven by NGO principles like societal impact and partly by economic concerns like revenue and efficiencies. Its primary source of revenue was raw data and data products, and it was operating in a B2B setting. Despite operating for several decades already, its maturity level in terms of user experience and product knowledge was low, while the amount of different data outputs and services was high, with a whole bouquet of bespoke solutions for individual clients. The level of bespoke solutions that had to be maintained and had grown organically over time had surpassed the “featuritis” stage and turned utterly unsustainable.

And you probably guessed it: The business focus had traditionally been “What can we offer and sell?” instead of “What are our customers trying to solve?”

That means there were essentially two problems to figure out:

Help executives and department leaders from Marketing through Sales, Business, and Data Science see the value of customer-first product thinking.
Establish a shared mental model of the key customer segments to start prioritizing with focus and reduce the completely overgrown service offering.

For full disclosure, here’s a bit about my role in this context: I was there in a fractional product leader role at first, after running a discovery workshop, which then developed into product strategy work and eventually a full evaluation of the product portfolio according to user & business value.

Approach

So how did we get to that outcome? Basically, we spent an afternoon filling out a table with different customer segments, presented it to a couple of stakeholders, and everyone was happy — THE END. You can stop reading…

Or not, because from just a few initial conversations and trying to find out if there were any existing personas, user insights, or other customer data, it became clear that there was no shared mental model of the organization’s customer segments.

At the same time, the Business and Account management teams, especially, had a lot of contact with new and existing customers and knew the market and competition well. And the Marketing department had started on personas. However, they were not widely used and weren’t able to act as that shared mental model across different departments.

So, instead of thinking customer-first the organization was operating “inside-out first,” based on the services they offered. With the user segmentation matrix, we wanted to change this perspective and align all teams around one shared canvas to create transparency around user and business priorities.

But How To Proceed Quickly While Taking People Along On The Journey?

Here’s the approach we took:

1. Gather All Existing Research

First, we gathered all user insights, customer feedback, and data from different parts of the organization and mapped them out on a big board (see below). Initially, we really tried to map out all existing documentation, including links to in-house documents and all previous attempts at separating different user groups, analytics data, revenue figures, and so on.

The key here was to speak to people in different departments to understand how they were currently thinking about their customers and to include the terms and documentation they thought most relevant without giving them a predefined framework. We used the dimensions of the matrix as a conversation guide, e.g., asking about their definitions for key user groups and what makes them distinctly different from others.

2. Start The Draft Scaffolding

Secondly, we created the draft matrix with assumed segments and some core elements that have proven useful in different UX techniques.

In this step, we started to make sense of all the information we had collected and gave the segments “draft labels” and “draft definitions” based on input from the teams, but creating this first draft version within the small working group. The aim was to reduce complexity, settle on simple labels, and introduce primary vs secondary groups based on the input we received.

We then made sure to run this summarized draft version past the stakeholders for feedback and amends, always calling out the DRAFT status to ensure we had buy-in across teams before removing that label. In addition to interviews, we also provided direct access to the workboard for stakeholders to contribute asynchronously and in their own time and to give them the option to discuss with their own teams.

3. Refine

In the next step, we went through several rounds of “joint sense-making” with stakeholders from across different departments. At this stage, we started coloring in the scaffolding version of the matrix with more and more detail. We also asked stakeholders to review the matrix as a whole and comment on it to make sure the different business areas were on board and to see the different priorities between, e.g., primary and secondary user groups due to segment size, pain points, or revenue numbers.

4. Prompt

We then promoted specifically for insights around segment definitions, pain points, goals, jobs to be done, and defining differences to other segments. Once the different labels and the sorting into primary versus secondary groups were clear, we tried to make sure that we had similar types of information per segment so that it would be easy to compare different aspects across the matrix.

5. Communicate

Finally, we made sure the core structure reached different levels of leadership. While we made sure to include senior stakeholders in the process throughout, this step was essential prior to circulating the matrix widely across the organization.

However, due to the previous steps, we had gone through, at this point, we were able to assure senior leadership that their teams had contributed and reviewed several times, so getting that final alignment was easy.

We did this in a team of two external consultants and three in-house colleagues, who conducted the interviews and information gathering exercises in tandem with us. Due to the size and global nature of the organization and various different time zones to manage, it took around 3 weeks of effort, but 3 months in time due to summer holidays and alignment activities. So we did this next to other work, which allowed us to be deeply plugged into the organization and avoid blind spots due to having both internal and external perspectives.

Building on in-house advocates with deep organizational knowledge and subject-matter expertise was a key factor and helped bring the organization along much better than purely external consultants could have done.

User Segmentation Matrix: Key Ingredients

So, what are the dimensions we included in this mapping out of primary and secondary user segments?

The dimensions we used were the following:

Segment definition
Who is this group?
Define it in a simple, straightforward way so everyone understands — NO acronyms or abbreviations. Further information to include that’s useful if you have it: the size of the segment and associated revenue.
Their main goals
What are their main goals?
Thinking outside-in and from this user groups perspective these would be at a higher level than the specific JTBD field, big picture and longer term.
What are their “Jobs-to-be-done”?
Define the key things this group needs in order to get their own work done (whether that’s currently available in your service or not; if you don’t know this, it’s time for some discovery). Please note this is not a full JTBD mapping, but instead seeks to call out exemplary practical tasks.
How are they different from other segments?
Segments should be clearly different in their needs. If they’re too similar, they might not be a separate group.
Main pain points
What are the pain points for each segment? What issues are they currently experiencing with your service/product? Note the recurring themes.
Key contacts in the organization
Who are the best people holding knowledge about this user segment?
Usually, these would be the interview partners who contributed to the matrix, and it helps to not worry too much about ownership or levels here; it could be from any department, and often, the Business or Product org are good starting points.

This is an example of a user segmentation matrix:

Outcomes & Learning

What we found in this work is that seeing all user segments mapped out next to each other helped focus the conversation and create a shared mental model that switched the organization’s perspective to outside-in and customer-first.

Establishing the different user segment names and defining primary versus secondary segments created transparency, focus, and a shared understanding of priorities.

Building this matrix based on stakeholder interviews and existing user insights while keeping the labeling in DRAFT mode, we encouraged feedback and amends and helped everyone feel part of the process. So, rather than being a one-time set visualization, the key to creating value with this matrix is to encourage conversation and feedback loops between teams and departments.

In our case, we made sure that every stakeholder (at different levels within the organization, including several people from the executive team) had seen this matrix at least twice and had the chance to input. Once we then got to the final version, we were sure that we had an agreement on the terminology, issues, and priorities.

Below is the real case study example (with anonymized inputs):

Takeaways And What To Watch Out For

So what did this approach help us achieve?

It created transparency and helped the Sales and Business teams understand how their asks would roughly be prioritized — seeing the other customer segments in comparison (especially knowing the difference between primary vs secondary segments).
It shifted the thinking to customer-first by providing an overview for the executive team (and everyone else) to start thinking about customers rather than business units and see new opportunities more clearly.
It highlighted the need to gather more customer insights and better performance data, such as revenue per segment, more detailed user tracking, and so on.

In terms of the challenges we faced when conducting and planning this work, there are a few things to watch out for:

We found that due to the size and global nature of the organization, it took several rounds of feedback to align with all stakeholders on the draft versions. So, the larger the size of your organization, the more buffer time to include (or the ability to change interview partners at short notice).

If you’re planning to do this in a startup or mid-sized organization, especially if they’ve got the relevant information available, you might need far less time, although it will still make sense to carefully select the contributors.

Having in-house advocates who actively contributed to the work and conducted interviews was a real benefit for alignment and getting buy-in across the organization, especially when things started getting political.

Gathering information from Marketing, Product, Business, Sales and Leadership and sticking with their terms and definitions initially was crucial, so everyone felt their inputs were heard and saw it reflected, even if amended, in the overall matrix.

And finally, a challenge that’s not to be underestimated is the selection of those asked to input — where it’s a tightrope walk between speed and inclusion.

We found that a “snowball system” worked well, where we initially worked with the C-level sponsor to define the crucial counterparts at the leadership level and have them name 3-4 leads in their organization, looking after different parts of the organization. These leaders were asked for their input and their team’s input in interviews and through asynchronous access to the joint workboard.

What’s In It For You?

To summarize, the key benefits of creating a user segmentation matrix in your organization are the following:

Thinking outside-in and user-first.
Instead of thinking this is what you offer, your organization starts to think about solving real customer problems — the matrix is your GPS view of your market (but like any GPS system, don’t forget to update it occasionally).
Clarity and a shared mental model.
Everyone is starting to use the same language, and there’s more clarity about what you offer per customer segment. So, from Sales through to Business and Product, you’re speaking to users and their needs instead of talking about products and services (or even worse, your in-house org structure). Shared clarity drastically reduces meeting and decision time and allows you to do more impactful work.
Focus, and more show than tell.
Having a matrix helps differentiate between primary, secondary, and other customer segments and visualizes these differences for everyone.

When Not To Use It

If you already have a clearly defined set of customer segments that your organization is in agreement on and working towards — good for you; you won’t need this and can rely on your existing data.

Another case where you will likely not need this full overview is when you’re dealing with a very specific customer segment, and there is good alignment between the teams serving this group in terms of focus, priorities, and goals.

Organizations that will see the highest value in this exercise are those who are not yet thinking outside-in and customer-first and who still have a traditional approach, starting from their own services and dealing with conflicting priorities between departments.

Next Steps

And now? You’ve got your beautiful and fully aligned customer segmentation matrix ready and done. What’s next? In all honesty, this work is never done, and this is just the beginning.

If you have been struggling with creating an outside-in perspective in your organization, the key is to make sure that it gets communicated far and wide.

For example, make sure to get your executive sponsors to talk about it in their rounds, do a road show, or hold open office hours where you can present it to anyone interested and give them a chance to ask questions. Or even better, present it at the next company all-hands, with the suggestion to start building up an insights library per customer segment.

If this was really just the starting point to becoming more product-led, then the next logical step is to assess and evaluate the current product portfolio. The aim is to get clarity around which services or products are relevant for which customers. Especially in product portfolios plagued by “featuritis,” it makes sense to do a full audit, evaluate both user and business value, and clean out your product closet.

If you’ve seen gaps and blind spots in your matrix, another next step would be to do some deep dives, customer interviews, and discovery work to fill those. And as you continue on that journey towards more customer-centricity, other tools from the UX and product tool kit, like mapping out user journeys and establishing a good tracking system and KPIs, will be helpful so you can start measuring customer satisfaction and continue to test and learn.

Like a good map, it helps you navigate and create a shared understanding across departments. And this is its primary purpose: getting clarity and focus across teams to enable better decision-making. The process of co-creating a living document that visualizes customer segments is at least as important here as the final outcome.

Further Reading

Data-Driven Personas for Enhanced User Understanding: Combining Empathy with Rationality for Better Insights to Analytics, Bernard J. Jansen, Joni O. Salminen, Soon-Gyo Jung (Data and Information Management, 2020)
“Most Effective Ways To Segment Your Users,” Ilia Lotarev (Adapty.io)
“The 6 Types Of User Segmentation And What They Mean For Your Product,” Pavel Malos (UX Collective, Medium)
“Understanding Users By Going Beyond Personas, Demographics, And Affinity Groups,” Kate Matesic (UX Magazine)
“The Difference Between Customer Segmentation And Customer Personas,” Simon Penny (UX Collective, Medium)

Transforming The Relationship Between Designers And Developers

/0 Comments/in /by

Original Source: https://smashingmagazine.com/2024/05/transforming-relationship-between-designers-developers/

In the forever-shifting landscape of design and technology, some rare artifacts surprisingly never change.

Throughout the last two decades, we have witnessed the astonishing evolution of creative tooling, methodologies, and working practices. However, after all of this advancement, we still have clients asking to make the logo bigger, designers despairing as their creations are built with not quite the exact amount of bottom-margin, and developers going crazy about last-minute design changes.

Quite frankly, I’ve had enough. So join me in a parenting-style-hands-on-hips pose of disdain, roll up your sleeves, and let’s fix this mess together, once and for all!

Why Is This Still An Important Topic?

Ultimately, the quality of your designer-developer relations will have a vital impact on the quality of your product. In turn, this will impact customer experience (be it internal or external).

Customer experience is everything, and these days the smallest of chinks can create an even bigger dent in the business itself.

It may not even be an obvious or noticeable issue. Over time, those moments of misunderstanding in your team could result in a series of micro-inconsistencies that are felt by the customer yet sneak underneath the radar of quality assurance.

Perhaps you’ll catch these things during user research, but in this scenario, you’d be playing catch-up instead of advancing forward.

To cut a long story short, it could be slowing you down in the race against your competitors and costing you more money in the process.

So, with that in mind, let’s get stuck into the techniques that can steer us in the right direction and inspire everyone on the team to deliver the slickest of user experiences together.

Working Culture

In my opinion, process improvements may only get you so far. The working culture in your organization will heavily influence the output of your digital teams. Whilst the subject of culture is incredibly vast, there are a few key elements that I think are hugely important to foster a greater level of collaboration between design and developers:

Alignment on the goals of the project and/or business.
Encouraging a more “robotic” attitude to feedback. Of course, you can be passionate about what you do, but when it comes to feedback, I always try to encourage people to respond with logic before emotion.
Communication: Ultimately, you have to trust people to be proactive. You can have a great process, but the gaps and edge cases will still slip through the net unless you have people who are open and ready to prod each other when issues arise.

This may seem like common sense to many of us, but many organizations (big ones, too!) still operate without this crucial foundation to motivate and support their teams.

However, it is essential to be honest with yourself and consider the role you play within your team. Even if you think you have already fulfilled these criteria, I’d encourage you to investigate this further to ensure everyone feels the same. It can be as simple as having a 121 discussion with each member of the team, or you could even send out short questionnaires to gauge your workplace’s suitability for an optimal designer and developer collaboration.

You might be surprised by what you hear back from people. Treat any criticism as gold dust. It’s an opportunity to improve.

Once you’ve created this foundation within your organization, it’s important to maintain and protect it. Keep reviewing it regularly, and make sure that anyone joining the team will be able to fit in. This leads us nicely on to…

Hiring

If you’re scaling your team, maintaining quality can always be a challenge as you grow. Despite the challenges, it’s important to continue hiring people who have a positive and empathetic attitude to ensure you can maintain this foundation within your workplace.

In order to gauge this, I would like to include the following interview questions.

Developer

Begin by showing a sample screenshot of your product or a specially crafted concept design:

“You’ve just built X, and the designer wants to change Y. How do you respond?”

Follow up:

“The designer and PM reject your suggestion because of ___. How do you respond?”

Designer

Begin by showing a sample screenshot of your product or a specially crafted concept design:

“The developer says, “We can’t build X quickly; can we do Y instead to deliver faster?” How do you react?”

Follow up:

“The product owner says they are then disappointed with the design. How do you react?”

I recommend asking these kinds of questions in the middle or towards the end of the interview so you have already built rapport. If the candidate is at ease, they are more likely to let slip any negative attitudes that lurk beneath the surface.

I’ve asked interview questions like these to many designers and developers, and every so often, they will openly criticize and stereotype each other with a smile on their faces. I’ve even seen some candidates become visibly frustrated as they recount real-life scenarios from their own experiences.

How you score this is more difficult. Ultimately, skills and work ethic are the most important things, so concerning answers to these questions may not necessarily lead to an outright rejection but perhaps flag something you may need to work on with the candidate if they do later join your team.

Hopefully, in most cases, the stronger candidates you speak to will naturally provide balanced and conscientious responses to these tests of character!

Process

We talked a bit about hiring, but I’d imagine many people who need this article are more likely to be in the midst of a designer-developer flame-war as opposed to trying to prevent one in the future!

So, what can we do process-wise to keep things flowing?

Provided that there is plenty of early and ongoing collaboration in your workflow, there is no absolute right or wrong answer. It’s about what fits your team and your product best. Ultimately, you need to discard the silos of the past and start working together as a team early on.

Developers would typically be the last people to get involved, but they should be involved from the start to guide technical feasibility and provide their own ideas.
Designers are often more involved in the beginning but can often drift away before the end of a release. However, we need to keep them onboard and get them to play with the product so we can keep making it even better!

It’s important to be open-minded about the solutions. Alas, I have even worked in organizations where different teams have different approaches. Bearing that in mind, here are some good places to start in terms of exploring what might work for your workplace.

Scoping

When new features are on the horizon, getting everyone involved in these discussions is crucial.

Sometimes, it can be difficult for developers to detach from the current sprint and think ahead, but it’s important that we have their guidance, and it is ultimately going to save them (and the whole team) time further down the line.

Scoping can appear in many different forms across the spectrum of agile methodologies out there. It’s not my intention to cover any of these and discuss all the positives and negatives of each (that’d make this into a book, and not one that anyone would like to read!); in fact, I am deliberately not mentioning any of them. This article is ultimately about people, and the people we need at this early stage are not just the stakeholders and a product manager. We need designers and developers shaping these early discussions for the following reasons:

They will bring their own ideas.
They will visualize the idea very quickly and assess its feasibility.
They will connect the concept with other parts of the domain.
They will also (albeit rarely!) prevent an impossible dream or daft idea from growing on the face of the business like a festering wart.

Another Perspective On Scoping: SquaredUp

In order to take a deeper dive into the subject of scoping, I spoke to Dave Clarke, product manager at SquaredUp.

“Developers are looped in during the design stage, and we’ll test interactive mockups with the engineering team as well as other internal stakeholders before going out to external audiences for feedback. This means that when a feature is ready to be built by an engineer, they’re already really familiar with what we’re building”

— Dave Clarke

Back in late 2018, I met the SquaredUp team at an open day in their UK hub in Maidenhead. I was impressed by the quality of their product, considering it was a very technical audience. It looked beautiful, and you could tell that they went the extra mile in terms of collaboration. Not only do they involve developers in the design phase, but they get them involved even earlier than that.

“We send engineers to events so they can talk to customers and hear their pain points first-hand. This helps foster a real appreciation and understanding of the ‘user’ and ensures designers/developers/PMs are all coming at a problem with a solid understanding of the issue from the user’s perspective.”

— Dave Clarke

This brings us back again to that all-important foundation. Alignment on goals is key, and what better way to reinforce that message than by getting everyone involved in hearing directly from the end users of your product?

Design Presentations

Once the wheels are in motion on the big new thing, many teams like to have the designer present their work for forthcoming iteration(s) to the team. This allows everyone to have a say and get excited about what is coming up.

Once again, there are many organizations that would simply agree on the design between stakeholders and designers alone. From the developer perspective, this is incredibly frustrating. Not only will it result in a lower-quality output, but it will also make developers feel as though their opinion doesn’t matter.

With my developer hat on, though, I absolutely love these kinds of sessions. They allow us to question the details, suggest alternatives, and consider how we slice stuff up into smaller bundles of value that can be released faster.

With my design hat on, it caters to my need to think about the bigger picture. It’s not always practical to design iteratively, but in these sessions, we can all get together and appreciate the end-to-end experience.

Typically, we allow the designer time to talk through everything, allowing for questions throughout, and give everyone a chance to dive in and bring their ideas to the table. However, do what works for your team. If you have a designer who wants to present, take all questions at the end and then make changes afterward, do that. If you have one who likes handling lots of questions throughout and makes changes live, go with that.

Perhaps even give it your own identity, too. In my current workplace, one of the squads calls it Design Time and in our squad, we decided to open the name to a poll, and thus (with one cheeky addition to the poll from a colleague) the Itty Bitty Refinement Committee was born!

Managing Conflict

However, these kinds of sessions do have the potential to get sidetracked. So, as with any meeting, it is essential to have a clear agenda and ensure that good facilitation prevents things from going off-piste. If there are conflicts, I always try to find resolutions by considering where we might find the answers. For example,

Can we look at our analytics?
Which option is a better fit for our company goals?
Could we do an A/B test to see what is more effective?

When people bring ideas to the table, it’s always important to acknowledge them positively and seek further exploration. Sometimes, we can agree on an approach quickly, and on other occasions, we can defer the discussion to a later refinement session.

Sharing Responsibilities

In my opinion, there is also a gray area between designers and developers, where it often isn’t clear who holds responsibility. This is a big risk because, in many organizations, essential aspects can be completely forgotten.

From my past experience, there are two key areas where I see this happening often. So this may not be exhaustive, but I encourage you to think about these and then ask yourself: Is there anything else — specific to my organization — that could have fallen into this void between our designers and developers?

See if you can identify these risks and agree on a way of working together to ensure they are tackled effectively.

Animations

Nowadays, many dev teams are working on JavaScript-heavy applications, and most of us will have the power of CSS transitions at our disposal. Yet, I frequently land on new projects where they aren’t being leveraged to enhance the customer experience.

Animations can be quite time-consuming to create using many design tools. In particular, I often find that loading states are quite fiddly to prototype in some cases.

In my recent work at Floww, I collaborated with designer Hidemi Wenn on an animated progress bar. For the first version, Hidemi had begun with an idea crafted in After Effects. I replicated this in a CodePen and suggested adding some bubbles to highlight the changes in the numbers.

Note: Of course, CodePen is just one example of this. There are many other tools out there, such as Storybook, that can also allow us to build and collaborate on ideas quickly.

See the Pen Bar Chart of Destiny [forked] by Chris Day.

This allowed Hidemi to see her creation working in the browser early — before it had been fully implemented into the product — and we then collaborated further to make more enhancements.

“Working together like this was awesome! We could easily bounce around ideas, and tweaking the animation was a breeze.”

— Hidemi Wenn, Product Designer at Floww

Pairing is often between developers, but why not jump on a call and pair with a designer whilst you write the CSS? This gives them full transparency, and you can collaborate together.

Nowadays, we have amazing tools at our disposal to collaborate, and yet still, so many designers and developers elect to operate in silos.

Accessibility

One of the first things I do when joining any existing digital project is to spin up Wave (an accessibility testing tool) and subsequently slump into my seat in despair.

Accessibility is something that always suffers as a result of a designer/developer standoff. Some might say it’s the realm of design, while others would argue it’s quite a technical thing and, therefore, lives in dev land. The truth is it is a shared responsibility.

Take something like :focus, for example. Whenever I review code, this is something I always check and often discover it’s missing. Ask the developer, and they’ll say, “We didn’t have designs for it.” Well, perhaps, ask the designer to create them, just as I’d expect the designer to query an unimplemented state they had designed for.

We should scrutinize each other’s work and continue to channel our inner robot to respond with logic when it comes to constructive criticism. Keep encouraging everyone to embrace feedback because that is the gold dust that makes our product shine brighter.

During Implementation

Having steered our way together through the implementation of our features, at some point, we begin to approach the time to release our features into the wild. We are on the final stretch, and thus, it’s time for developers to stage a reverse-design presentation!

Whilst mentoring developers on this subject, I always remind them not to take the feedback personally.

Likewise, I ask designers to never hold back. Be persnickety (in a kind way!) and ensure all your concerns are addressed.

It’s only natural for a developer to behave defensively in these scenarios. As a result, designers may hold back on some of the feedback they provide in order to prevent upsetting the developer.

Developers are often very vocal, and if you are tasked with delivering a barrage of design feedback to them, it can appear daunting and make designers fearful of a backlash.

Prevent the silo. Perhaps have a third party, such as the product owner/manager, attend the meetings. They can diffuse any situation by referring us all back to the business value.

I’ve also witnessed rare cases where the developer has nodded and agreed with all the feedback and then just hasn’t implemented any of it afterward! So, make sure it’s all captured in whatever project management tools you use so you can follow up on the status. Sometimes, it’s easy to forget to do this when the changes are so small, so often (in my current team), we might create a single ticket on our board to implement all the feedback changes as opposed to creating a work item for each.

Another common issue I’ve found is that I’ve met many designers who don’t actually ever test out the products that they design. For me, they are missing out on the opportunity to further hone their work, and to learn.

If you’re a designer, ensure that you can log in to the app/website. Get a test account from someone, and try to break stuff!

Once all the feedback is in, we can create more work items to give our product those magical finishing touches and ship our masterpiece to the World.

Design Systems

Having mentioned focus states earlier on, you were probably already thinking about design systems before this heading came along! Of course, the design system plays a key role in helping us maintain that consistency, and ensuring accessibility concerns are baked-in to our library of beautiful components.

There are many, many articles about design systems out there already but here, I am going to just consider them in the context of the working relationship.

As the design system encourages reuse, it encourages us to think about other teams in our organization and be more mindful.

If the basic building blocks are covered, we can focus on solving more complex challenges together. I think this is also a really important value to get your teams on board with.

Design systems can also cause friction. Not everyone will get on board with it. Some designers will feel as though it restricts their creativity. Some developers will be frustrated at having to update the design system instead of cracking on with their own features.

In my opinion, these attitudes will not only slow you down but could harm the working culture of your business. Nowadays, I’d say it’s absolutely crucial for any product team (big or small) to have a design system and have the majority of your team buying into it.

I’ve been present at organizations where the design system is neglected, and in these cases, it actually ends up worse than not having one at all. You really need the majority of your team to be committed to it; otherwise, some people will go off-piste and keep reinventing the wheel (probably without those focus states!).

Another Perspective On Design Systems: GOV.UK

The GDS (Government Digital Service) of the UK has built a design system that serves a vast spectrum of different services and tech stacks. An enormous challenge, which is almost certain to be of interest in our quest for knowledge! So, I got in touch with product designer Ed Horsford who has worked on a series of government services that make use of this.

“GDS provides the GOV.UK Prototype Kit, so as a designer, I can create something in the kit, make full use of the functionality of the design system, and point developers towards the prototype.”

— Edward Horsford

Whilst many other organizations are now making use of tools such as Figma’s excellent Dev Mode feature to streamline design handover, this still requires naming conventions to be lined up between the codebase and the Figma component library. What’s impressive about GDS’ approach here is that the provision of their own prototyping tool makes it absolutely clear to developers which components need to be used. However, the availability of a great design system tooling doesn’t always guarantee a smooth outcome, as Ed explains:

“It can be a bit of a mind-shift for developers new to the UK government or using design systems in general — they may default to hand coding the HTML and CSS to match a design, rather than using the components from the design system to match the prototype.”

“If there is a bespoke requirement outside of the design system, then I will always call it out early so I can discuss it with the team.”

— Edward Horsford

Once again, this takes us back to the importance of communication. In a landscape where a design system must be deployed amongst many different teams, it’s up to the designers and developers to scrutinize each other’s work.

It was great to hear that as a designer, Ed was actively looking at the front-end code to assist the developer, ensuring the design system was respected so that all of its many benefits could be embedded into the product.

Crisis Mode

I appreciate that much of the advice in this article requires planning and a fair bit of trial and error. So what do you do if your designers and developers are already engulfed in a mass brawl that needs to be quelled?

In these scenarios, I think it is an ideal moment to pause and simply ask each member of the team: What is our goal? What are we working towards?

If people are angry, in some ways, it’s a good thing because you know they care. People who care should always be open to a bit of a reset. Openly discuss what everyone wants, and you’ll probably be surprised at how aligned people really are; I always go back to this fundamental and work onwards from there.

Sometimes, we get so tangled up in the details we forget what is truly important.

Apathy

For every angry team, there are probably many more that just don’t give a crap. For me, this is a far worse situation.

Every problem described in this article could be present. The designers make mockups, the designers build them without question, and everyone gets paid. Who needs to question anything? It’s just a job, right?

Can we really fix this?

Well, in my opinion, you are going to need a much deeper dive into company culture to try and revive that team spirit. I have worked at places like this in the past, and it is very challenging to try and implement solutions when the people are just not bought into the vision of the organization.

Whether this is feasible or not depends on your role and the organization itself. I have walked away from situations like this in the past because I didn’t feel as though the organization was willing to change or even be able to acknowledge the problem.

Conclusion

The dynamic between designers and developers is a subject that has always been of great interest to me, as I’ve worked in both roles as well as being an agency owner.

I’m confident as the years continue to progress, this will become less of a problem as the world of work continues to gravitate towards greater levels of inclusivity, honesty, and openness. The foundations of great company culture are so crucial to ensuring that designers and developers can unite and take on the world side-by-side on behalf of your organization.

For now, though, in today’s fragmented and divided world, you can gain a true competitive advantage by leveraging the power of a harmonious digital team built on the foundations of your organizational values.

Go smash it!

Why Is My Printify Order On Hold?

/0 Comments/in /by

Original Source: https://ecommerce-platforms.com/articles/why-is-my-printify-order-on-hold

After an order is placed with Printify, the system will provide status updates as the product passes through the pre-production phase to production and shipping–and until it reaches the customer.

When an order is ‘on hold,’ it means production has not started. The hold may be due to the order not being completed and submitted, or that there is an issue that requires attention.

Order Statuses Explained

Any time you place an order on a print-on-demand platform (e.g. Printify or Printful), you can check the platform at any time to confirm the status of the order. With Printify, the possible order statuses you might encounter are:

Pre-production statuses:

On hold: Submit order

Sending to production

On hold: Action required

Production statuses:

In production

Has issues

Canceled: Canceled by Print Provider

Canceled: Various

Shipping statuses:

Ready to ship

Shipped

On the way

Available for pickup

Out for delivery

Delivery attempt

Shipping issue

Return to sender

Delivered

An ‘on hold’ status can happen during the pre-production stage.

A Closer Look at Pre-Production

Before an order is sent to one of Printify’s print providers, the system will verify that all necessary information was entered correctly, payment was processed, the products are available, no claim to intellectual property was filed, and that Printify vendors can deliver to the address provided.

If there is an issue and you have Printify Premium benefits, you can contact Printify Connect. This is a customer-support program that handles issues related to orders connected to your Premium account.

More About ‘On Hold: Submit Order’

Depending on the order approval settings of your account, the order may be automatically submitted or held for a designated period before being sent to Printify.

When you create an order manually, you can also submit it immediately or wait. During either of these scenarios, the order status will show as ‘On Hold: Submit Order.’

When an order is on hold, you can edit it (e.g., quantity, color, etc.) before submitting it. After submitting, the order status should be updated within a few minutes.

If it doesn’t show as ‘Sending to Production’ after thirty minutes, contact the Printify Support Team to ensure it went through correctly.

More About ‘On Hold: Action Required’

If you see this status pop up on an order, there is a problem. Check the sub-status for more information about what the issue is and how you can rectify the situation. Here are the possible reasons for an ‘On Hold: Action Required’ status:

Payment not received: Set up a payment method and ensure enough funds are available. Resubmit the order. If it happens again, try another payment method.

Out of stock: Cancel the order or select a replacement product or print provider.

Discontinued product: Cancel the order or select a replacement product or print provider.

Address issues: Correct the address and resubmit the order.

Canceled – IP reported: This status means your product was flagged as infringing on someone else’s intellectual property. You can remove the product in question and resubmit the rest of the order (if there is more). If your product is unique and you think it should not be flagged in error, submit an appeal with Printify.

Shipping restrictions apply: There are some locations in which Printify vendors can not deliver products.

What Happens Next?

After the ‘on hold’ status is removed, the order will be sent to production. If you are curious about how your experience stacks up against other print-on-demand platforms, read the reviews posted by ecommerce-platforms.com.

We are committed to helping entrepreneurs grow their businesses by rigorously evaluating online software solutions and providing unbiased advice.

Wondering whether Printify shipping is expensive? Be sure to read our latest post!

The post Why Is My Printify Order On Hold? appeared first on Ecommerce Platforms.