Think of it this way: When you communicate, you’re interrupting the person you’re talking to. It just makes matters worse if you need to interrupt them multiple times.
You’ve seen communication examples like this at work—even been the responsible party: when you’re trying to sell your company’s new application to potential customers; or when you’re tasked with changing the way your organization does things (implementing a new safety program, for example); or when your team is rolling out a new application for your organization.
In all these scenarios you are—to be polite—trying to get people to change. Let’s be impolite: You’re asking people to do what you want. If the audience is small (ideally, a single person), you can go and talk to that person (or call them or email them): a “high-touch” solution.
As the number of people increases, though, you’ll need a strategy that’s “lower touch,” probably built around written documents, emails, video communication and/or group presentations. That application you’re rolling out? You need to communicate with the staff using the application, their managers, the people downstream of the application that are affected by it … and probably more. Each of those people is interested in different information and values different things about that application.
If you’re using a “low-touch” strategy, not only do you need to create documents/videos/presentations—you need to create ones that those people will actually read/view/pay attention to. (I’ll just use “documents” and “read” from now on.) That’s not going to happen by accident or luck: You’re going to need, at the very least, some way to decide what documents you need to create (this post) and what you’ll put in those documents (my next post).
Your starting point is deciding what your purpose is.
For that commercial software application, is your purpose to sell a lot of units? Or is your purpose to get users to upgrade to a new version of an existing application? For the safety protocols you’re trying to get people to adopt, do you need people’s “hearts and minds”? Or do you just need token compliance? For an internal app, is using the new app mandatory and, as a result, your purpose to reduce disruption during the migration? Or is using the app optional and you’re trying to drive up the adoption rate?
Once you know what your purpose is, you can select your audiences: Who actually needs to read your document for you to get the change you want?
If you only need one group of people to meet your purpose (i.e., influencers or decision makers), that’s great. More typically, when there are more than a few people involved, you’ll need to communicate multiple messages to multiple audiences (I covered crafting a message for an audience in an earlier post).
Regardless of how many audiences you have, the next step is to recognize when you can intervene in your audience’s lives: When will each audience actually care about your message?
Remember that you are interrupting the lives of your readers and they’re only going to give up their time grudgingly. If you can target your communication to support something the audience is doing, then you’re far more likely get your audience’s attention. You need to identify, for want of a better word, each of your audience’s scenarios.
For example, for the safety awareness program, you want to address scenarios when the user is exposed to risk. When it comes to selling a commercial application, you want to target the scenario where using/acquiring the new application will make the reader’s life easier or cheaper or more efficient—whatever the reader (not you) thinks of as “better.” For the internal application, you want to address the scenario where the user can see that they can no longer avoid using the new application. For people downstream from the new internal application, you want to address the scenario when those people suddenly see the difference in their lives (the “Why is this behaving differently?” scenario).
Once you’ve got a list of audiences and scenarios, you can prioritize the documents you want to create. Prioritization matters because, I bet, you don’t have the time or money to communicate with every audience on every scenario. Even if you do have all the time/money you need (it could happen …) you still must schedule what you need to do first and what can be left to later. You’ll decide what criteria you’ll use to prioritize your documents.
Here’s the bad news, though: While you now know what documents you’ll probably create, you still need to craft those documents so they will get read and acted on. And just because you have multiple audience/scenario combinations, that doesn’t necessarily mean you need to create multiple, separate documents. I’ll cover those topics in my next post (I’ve always loved a cliffhanger ending).
]]>Internationalization, often abbreviated as i18n (where 18 represents the number of omitted letters between “i” and “n”), is the process of designing and developing an application in a way that allows for easy localization to different languages, regions and cultural contexts. It involves separating the user interface and content from the application’s codebase to facilitate easy translation and adaptation.
In a previous article, we discussed the importance of internationalization in web applications and some important steps one can take to get there.
In today’s article, we’ll go through a more practical tutorial of adding internationalization to a small React application with the help of the react-intl library.
React-intl, part of FormatJS, is a popular library used to internationalize React applications. It provides React components and an API to format dates, numbers and strings, including pluralization and handling translations.
It also supports both singular and plural message translation, string substitution and rich text formatting, among other things.
In a React application, we can start by first installing the react-intl
library:
npm install react-intl
# or
yarn add react-intl
To begin introducing internationalization to our app, we’ll first need to define our language messages. This is usually done in JSON format and each language is defined in a separate file.
We’ll create a locales/
folder in the src/
directory. Inside locales/
, we’ll create three files: en.json
, es.json
and fr.json
to represent the English, Spanish and French languages.
src/locales/en.json
{
"app.greeting": "Hello, User!",
"app.description": "This is a simple react application"
}
src/locales/es.json
{
"app.greeting": "¡Hola, Usuario!",
"app.description": "Esta es una simple aplicación de react"
}
src/locales/fr.json
{
"app.greeting": "Bonjour, Utilisateur !",
"app.description": "C'est une simple application React"
}
These files will act as our dictionaries, mapping message IDs (like app.greeting
and app.description
) to the message in the respective language.
Now, we can set up our application to use react-intl
. In our main app file (App.js
), we’ll import the necessary components from react-intl
as well as the different language message dictionaries we’ve just created.
import { IntlProvider, FormattedMessage } from "react-intl";
import messages_en from "./locales/en.json";
import messages_es from "./locales/es.json";
import messages_fr from "./locales/fr.json";
We’ll then create an object to store all our dictionaries:
const messages = {
en: messages_en,
es: messages_es,
fr: messages_fr,
};
Next, we’ll wrap our app in the <IntlProvider />
component, provided by react-intl
, which will provide i18n context to all the components in our app. The <IntlProvider />
component requires two props: locale
and messages
.
locale
is a string value that represents the language locale we want to use in our application.messages
is an object that contains the actual text messages (strings) that we want to display in our application.To start, we’ll default the locale to English ('en'
) and reference the english message dictionary we’ve created.
export default function App() {
const locale = "en"; // default locale
return (
<IntlProvider locale={locale} messages={messages[locale]}>
{/* rest of our app goes here */}
</IntlProvider>
);
}
With react-intl
now configured, we can use it in our app. We can use the FormattedMessage component from react-intl
to display text.
export default function App() {
const locale = "en";
return (
<IntlProvider locale={locale} messages={messages[locale]}>
<FormattedMessage id="app.greeting" />
<br />
<br />
<FormattedMessage id="app.description" />
</IntlProvider>
);
}
When saving our changes, we’ll be presented with “Hello, User! This is a simple react application” in the browser, as we’re currently using the English locale.
If we were to change the value of the locale
variable to a different language like French
:
export default function App() {
const locale = "fr";
// ...
}
We would be presented with the same “Hello, User! …” message but in French.
We’ll want to provide the end user the capability to switch between different languages. To achieve this, we can consider storing the locale
in our <App />
component’s state.
import { useState } from "react";
// ...
export default function App() {
const [locale, setLocale] = useState("en");
// ...
}
We can then add buttons to our app that lets the user switch between the English, Spanish and French locales.
import { useState } from "react";
// ...
export default function App() {
const [locale, setLocale] = useState("en");
return (
<IntlProvider locale={locale} messages={messages[locale]}>
<FormattedMessage id="app.greeting" />
<FormattedMessage id="app.description" />
<div>
<button onClick={() => setLocale("en")}>English</button>
<button onClick={() => setLocale("es")}>Español</button>
<button onClick={() => setLocale("fr")}>Français</button>
</div>
</IntlProvider>
);
}
When we click on a certain button, the locale
state of our app updates to the selected locale, triggering a re-render of the IntlProvider
component with the new locale
value and data. Consequently, the text in our application that’s managed by the react-intl
library updates to reflect the chosen language.
You can see the running application in the following CodeSandbox link.
The user now has a dynamic way to switch between different languages without having to refresh the entire page!
In today’s article, we showed a simple example of introducing internationalization to a React application. There are are more advanced features to explore in react-intl, including handling more complex string translations, number formatting, date and time formatting, and handling plurals and genders, which are important aspects in many languages.
Building an app with internationalization in mind from the outset is generally easier than trying to retrofit it later. So even if you’re only targeting a single language region to begin with, it’s worth considering from the start.
Looking to build with i18n baked into your components? The Internationalization package from Progress KendoReact applies the desired cultures by providing services and pipes for the parsing and formatting of dates and numbers.]]>
When we’re assessing the user experience of a website or application, what exactly are we looking for? What makes a site especially usable—or especially difficult to use? One of the most common models for breaking down this question into a more easily quantifiable and measurable system is Jakob Nielsen’s 10 Usability Heuristics.
The word “heuristic” simply refers to an approach or strategy that works more as a rule of thumb—not necessarily scientifically tested or 100% accurate all the time, but rather a good mental shortcut or helpful generalization. By nature, that also means that there will be exceptions to the rules; a site that “violates” one or two of the heuristics in this list isn’t automatically a bad or unusable site. However, we can feel pretty safe in saying that when when the criteria isn’t met for many or most of these, there’s probably a usability issue (or several) that needs to be examined.
Nielsen’s heuristics were originally created in 1990, then refined down to 10 in 1994. In 2020, they were reexamined and adjusted slightly for clarity—however, the 10 heuristics themselves did not change. As Nielsen says: “When something has remained true for 26 years, it will likely apply to future generations of user interfaces as well.”
That being said, let’s take a look at what these include:
Users always need to know what’s happening and what the current state of the website or application is. Imagine you’ve just completed a form and hit the “Submit” button—but there’s no confirmation dialog or other visual change. Did it go through? Did your internet connection lapse? Do you have an error that needs correcting? Should you resubmit, or will that cause an error?
When users interact with elements and see no change in the system, it can be unsettling and confusing. In Designing Interfaces: Patterns for Effective Interaction Design, the authors describe the user interface as our way of having a conversation with the user—similar to the way that a receptionist might help a user in person at a hotel front desk. If you were to check in at a hotel and make a request for a wake-up call, but were met with total silence … it would be pretty weird, right? You’d wonder if they’d heard you at all or whether you were at risk of oversleeping your morning meeting.
In the same way, we need to make sure that our interfaces include active feedback to keep the user apprised of everything happening “behind the scenes.”
The language, layout and approach that we use within a website or application should always align with the user’s real-world experience. That means that everything from where elements are on a page to the words we use we describe things should be user-centric and tailored to the way that they move through the world. That sounds obvious, but can actually be very challenging—mostly because our own lived experience is often very different from that of our users, and when we design and develop we’re always doing so from the basis (and bias) of our own experience.
It’s very easy to make assumptions about what users know, how they think and what experiences they will have had. Of course users will know what a widget is, that’s a common term … right? Of course users will be able to identify that icon as a drag and drop symbol, that’s an industry standard … right?
The answer, of course, is that it depends entirely on your user base. A younger, more technically-savvy user base might not have any issues with those examples, but an older user base could struggle more. It’s our responsibility to conduct user research and gain an understanding of the people who use our applications and websites in order to more accurately tailor the content and layout to them.
However, it’s crucial to keep in mind that users are not a monolith. You’ll likely have users of many different capability levels, experiences, backgrounds, etc. using your product. It’s often a good idea to build in multiple ways of accomplishing tasks, so users have flexibility in choosing the approach that works best for them. We’ll talk more about this in heuristic #7.
Users are not going to get everything right the first time—that’s just a fact. No matter how wonderful or intuitive our UI is, there will still be folks who make mistakes, forget things and have to go back, or need to undo an action.
Part of what makes users feel comfortable and engaged with a piece of software is the knowledge that they can freely experiment and know that the stakes are low. That means that the consequences for simple actions should be minimal: clicks can be unclicked, navigation can move backward and forward without getting lost, choices aren’t permanent. Changed the color to red—oops, didn’t like that!—click undo. This is referred to as safe exploration, and it’s an important way for users to learn the application interface and functions.
Obviously, there are some situations where users do need to make important, permanent decisions: placing an order, deleting an account or similar. In those situations, we need to clearly communicate to users 1) at which point there’s no turning back, and 2) what exactly will happen afterward. Always allow users an “escape route” or a way back—all the way up until the point at which that’s no longer possible.
This one has two main interpretations:
Both have to do with the concept of mental models. A user’s mental model is the understanding they build and the assumptions they make about their current experience, based on the similar experiences they’ve had up until now. For example, most websites have a logo in the top left corner that will take the user back to the home page when clicked. Linked text in a webpage is underlined. Right-clicking will open a contextual action menu.
When these things don’t happen—or worse, when something else unexpected happens—it throws us off. Our mental models no longer line up and now we have to both learn a new system and remember that the system is different for this particular website / piece of software. That increases a user’s cognitive load, or the amount of mental effort and energy that it takes to complete a task.
By meeting the wider standards of web and application design, we allow our users to carry over everything they’ve learned and all the behaviors that have become second-nature to them from years of tech use. Things “just work” because we’re not forcing them to go against the grain and learn something new in order to use our product.
Mental models also can be (and are) constructed on a product-by-product basis. Maybe our application uses a specific color system to designate different types of information, or maybe our navigation menus are organized in a certain way. If that were to differ between applications in a shared product suite, we’d be disrupting our users’ mental models—and creating a higher cognitive load for the users who have to switch back and forth between those systems regularly.
Errors are inevitable. Whether it’s a system bug, a user mistake or some combination, it’s important that we prepare for the reality of errors in our software. However, even better than error mitigation is error prevention. By making smart choices during the design and development process, we can create products that reduce the likelihood of errors happening in the first place.
For example, users on mobile devices are more likely to misclick or “fat finger” something, especially in a compact page layout. We can help prevent that error by making the clickable areas—or target sizes—larger and more forgiving. We can also be smart about where we place interactive elements on the page, and how much empty space we build in when we need to place them close to each other. Finally, if a user does misclick, we can make it easy for them to go back, undo or otherwise negate the unintentional action (as we discussed in heuristic #2).
This combination of preventative measures means less stress for the user—and for us.
Users have a lot going on, and our software is a comparatively small part of that. Schedules, grocery lists, work to-dos, personal tasks—the details of our particular UI tends to be pretty low on that list. As someone uses the interface more often, over time it will stick in their memory, but that takes time. We can help reduce that time and reduce the amount of effort it takes to use the UI by working based on the assumption that our users won’t remember it.
Practically, that means surfacing relevant information as needed, in the context of the task, rather than expecting our users to recall all the details. It might be visually efficient to just use icons in our menu, but that means we’re placing the burden on our users to remember what they all mean. That burden might be pretty low for common icons, like a house for “home” or a gear for “settings” … but it could also be more difficult. Does a light bulb icon mean “see a tip” or “toggle on light mode”?
Those things could make perfect sense to an established user, but new users will have to wrack their brains to remember, over and over again until it sticks. By adding a label to the icon, we reduce the cognitive load required to use the application.
Remember when I said we’d talk more about the whole “multiple ways of accomplishing tasks” thing, way back in heuristic #2? Well, now it’s time! “Flexibility and Efficiency of Use” is all about creating flexible paths and processes, so that users of different experiences and capabilities can all feel comfortable using your product.
A great example of this is a well-designed and prioritized keyboard navigation experience. Keyboard nav benefits a wide variety of users: from experienced “power users” who appreciate the speed and ease, to visually impaired users who require it for accessibility purposes. By enabling useful keyboard shortcuts and well-designed keyboard navigation, we can allow those users to engage with the software in the method that’s most comfortable to them.
Consider the use case of filling out a long form. A new user might work through the form more slowly, clicking on each input box with their mouse and considering their response. An experienced user (who has filled out this form a hundred times before) might tab between the input boxes and copy/paste the content without ever touching the mouse. A visually impaired user will make use of a screenreader in combination with their keyboard to complete the form. If we’ve built the form to be flexible, all three of these example users will be able to complete it in their preferred way, using their preferred tools.
This is a heuristic with a name that can be a little misleading at first, because “minimalism” can also refer to a very specific, sparse visual style. However, that’s not what we’re talking about here. In this case, “minimal” simply means that every element on the page serves a purpose.
Think of it kind of like the Marie Kondo method—she doesn’t say that you need get rid of everything in your house, she simply asks you to question its purpose and whether it “sparks joy” and discard the things that don't. We should approach the elements in our user interfaces with the same curiosity: What purpose is this serving? Is it making the website or application a better place for the user? If not, can we remove it?
We can vastly improve the user experience by creating designs that are a) visually appealing, and b) not cluttered with elements that don’t further the user’s goals. Every time we place a new element into a layout, we should think: “What is this helping the user achieve?” When we have too many items on one page, it becomes distracting; it makes it more challenging for the user to parse what’s needed vs. what isn’t in order for them to complete a particular task. Often, users refer to this kind of design as “clean”—it feels straightforward, intuitive and easy to understand at first glance.
As wonderful as it would be if we could simply prevent all errors by using the guidance provided in the error prevention heuristic, there will still be cases in which errors do happen. When they do, it’s our job to make sure that users can see that they’ve happened, understand why they’ve happened and know what the next step is.
Recognizing an error means that a user knows the error has happened in the first place. That might seem like common sense, but remember that some errors happen on the system side—bugs, unexpected inputs, connection failures and other things not necessarily related to a user’s mistake. Many times, those errors happen “behind the scenes” but still have implications for the user experience—anything from longer-than-expected load screens to full crashes. Regardless of how the error came to be, we need to make sure the user is aware that something went wrong.
Diagnosing an error means that a user knows why the error occurred. Again, this might be due to their mistake (such as a form validation error) or a system issue (dropped connection). This should always be communicated in user-friendly language, so avoid using overly technical terms or error codes that won’t be meaningful to them.
Finally, recovering from errors means that a user knows what they’re supposed to do next. This could be simply an acknowledgement that the error happened and communication that no action is needed from the user, a prompt for the user to try the action again, instructions on how the user should revise their input, or possibly just the right language for a user to effectively communicate their issue to a help desk. No matter what the follow-up action is, we want to make sure we don’t leave them hanging, unsure of how to resolve the problem.
We talk a lot about intuitive user interfaces as the ideal—wouldn’t it be wonderful if all of the products we created were so crystal clear that you could simply look at them and immediately understand everything? However, that’s not always realistic. Sometimes the systems we build are, by nature, complex systems meant to solve complex problems. Advanced video or photo editing software, applications for banking or money management, specialized healthcare websites—all of these are examples of situations where even the best, most intuitive visual design can only get us so far. Sometimes the necessary complexity of the software calls for written instructions and additional explanation.
When this is the case, we need to make sure our documentation is as thoughtful and intentional as the website or application itself. That means good search capabilities, well-organized content, easy-to-understand language and straightforward steps that users can follow to accomplish tasks.
Now that you have this list of heuristics, how are you supposed to use them? A great way to leverage this knowledge is to use the heuristics as a kind of checklist for internal review. While it’s always ideal to put work in front of users to get their feedback, we can often catch a lot of easy mistakes or UX shortcomings by using these heuristics to evaluate the product ourselves, first.
This also saves time and money—usability testing takes a lot of organization and effort, so you don’t want to “waste” that on catching the obvious mistakes. Ideally, you want user feedback to be the kind of nuanced, contextual, experience-informed stuff that you won’t be able to mimic with an internal review. By using these heuristics to make sure you’ve checked all the low-level boxes, you can concentrate your user interviews on higher-level, more insightful feedback.
Try using this list as a basis for internal review—you might be surprised how much you’re able to improve the product before it’s ever touched by a user!
]]>Lifelong learning sounds painful. Whether you’re just entering the workforce or have been working professionally for a long time, the prospect of constant learning can be daunting. Many organizations operate on tight budgets, which means each employee is responsible for a greater amount of work. When you’re overwhelmed with work responsibilities, the last thing you want to do is learn something new.
Lifelong learning is more than simply learning new job tasks to advance your career.
Lifelong learning is also an opportunity to make working more enjoyable, engaging and fulfilling. Most people work a significant number of hours each day, so making sure your work is interesting, enjoyable and fresh is important to both job and life satisfaction.
The problem is fitting it into an already packed schedule. How can a busy software tester find time for lifelong learning?
This guide describes how to create learning opportunities through micro-learning, leveraging your work environment and other flexible options.
Lifelong learning and software testing are linked in an eternal spiral. How so? Software testing is constantly evolving. Consider the number of software development methodologies, testing techniques and applications under test. For software testers, what and how you test is continuously changing.
Modern software testers need to understand how testing has been done and keep up with what is changing. For example, two decades ago the first forms of test automation tools came into our software testing lives. Some worked well, but most ended up being more work than they were worth, so the ROI was low. However, test automation tools have changed.
Codeless test automation tools like Progress Telerik Test Studio that leverage AI and ML technology create more positive business value. Testers of all levels can learn to develop test automation on the job. The same holds true for learning skills in product or project management, database management or coding. There’s always a use for learning new skills, whether they advance your career or simply make work more engaging.
Micro-learning is education or training taken over short periods of time. For example, automated testing tutorials or short API testing training podcasts or videos. There’s no time like the present for easily accessing education for practical and technical software testing skills. With nothing more than an internet connection, testers can access videos, tutorials, blog posts or even short skill training sessions on a variety of platforms.
Micro-learning when you’re busy easily fits into short down periods, walks or exercise time. Instead of only listening to music, try a day or two listening to a podcast or other audio skill presentation. Micro-learning can also be done within groups. Many software testing teams hold weekly or monthly lunch-and-learns to present training. There are several advantages to group learning including support for questions and assistance with details that aren’t immediately clear.
If during the day never works out due to your work schedule, consider attending a monthly meeting. There are online and in-person events held frequently by professional QA testing groups. You can also find online educational sessions presented by software testing groups on LinkedIn. The easiest way to find groups is by searching for related groups by specialty (software testing) to follow. If you’re looking to use your software testing experience to move into product management or another area, there are plenty of opportunities.
If group meetings don’t work for you, then there are always blogs on software testing and other topics. Blog postings and industry newsletters published by professional testing associations or groups provide valuable tips. Tips may seem small, but they can frequently lead you to more valuable and detailed information.
Raise your hand and volunteer for new projects. Volunteering for stretch opportunities enables learning on the job. Volunteering for new projects like automated test development using a new tool, or a new type like codeless test automation. Learning it first means you’ll not only learn to do it, but you’ll also cement your knowledge by teaching and training your peers.
Companies invest more in QA testing and training when testers volunteer. You can be the one to implement it and move yourself and the test team into the future. Learn it now and you’ll be the one in the know for all things test automation.
Interested in project management? Volunteer to lead the next new project when a new opportunity is offered. Don’t let fear hold you back. Sometimes volunteering is best done by pushing yourself off the cliff and not letting fear keep you from learning new things. Jump in and learn! The ROI not only helps the organization but it builds your skills and knowledge from the ground up.
What if your organization doesn’t offer new opportunities to stretch your skills? Consider finding a mentor in the area you’re working toward. So, if your goal is to be a testing technical expert or a developer, find a mentor to learn from. Mentors are a great way to get access to learning opportunities. Ask around. If you can’t find a mentor within your organization, check your network, LinkedIn or within related groups. Industry or professional conferences are a great way to find industry leaders and possibly a mentor to help guide you.
Another option is signing up for short-term project work as a freelancer. Keep in mind you’ll want to make sure you don’t overcommit. Side or freelance projects help you develop skills and discover new interests, career goals or additional opportunities. Freelancing is a great way to explore other interests without risking your main source of income.
Opportunities often exist within your current work environment but may be harder to find. Consider meeting with company leaders in your area of interest. Offer to take on new tasks as time allows outside your job description. There’s nothing worse than doing the same thing day after day, year after year, and becoming stuck or stagnant. By finding new opportunities to learn within your organization, you increase your skills and stay engaged with your work.
The advantage of learning by solving problems or working outside your job description is you find a new perspective. Solutions provided by outsiders are common because of a new perspective. Sometimes simply expanding your skills can make you a more valuable business asset. As software testers, consider offering to work on product management tasks, technical documentation or even development, depending on your interests.
For example, a popular method of moving from software testing to development is through test automation. By investing in learning how to develop and code automated tests, you’re not only helping the testing team but you are gaining coding experience. Knowledge of automated testing and tools can also lead to becoming a technical test lead or a similar role.
Read! Yes, reading books is still a viable path to lifelong learning. There are plenty of software testing, management and coding books available. Keep the cost reasonable by checking for books at a local library instead of purchasing them individually. Want your own book? Then consider looking into thrift retailers and buy at reduced costs.
You can also take traditional college or adult education courses in a massive number of subjects from local community colleges or universities. Optionally, consider online courses as well. Many online courses can be taken on your schedule. No need to apply, sign contracts or pay high fees.
Check out the following online options:
If you’re a software tester, you may be already trying to squeeze more work into a day than is reasonably possible. Software testing is not for those who don’t want to work hard day in and day out. When not actively testing on a project, testers are reviewing technical information, developing test cases or training coworkers.
Keeping your software testing skills up to date and current is important to your organization and your personal career. There are internal and external opportunities all around you for lifelong learning. Take advantage of opportunities to volunteer for new projects or tasks. Take courses, listen to podcasts, watch videos or find other tutorials. Learning doesn’t have to be complicated. Lifelong learning is a skill in itself. Take advantage of all your opportunities to learn and get more out of your work life.
]]>You know how clients are. They can tell you what they need—“I need a website,” “I need a logo,” “I need a mobile app”—but it takes quite a bit of prodding to figure out what it is they’re really after. For example:
“I need a lead-generating website that keeps me from having to do cold calls all the time.”
“I need a network of blogs built for $1,000.”
“I need a mobile app done in the next month that allows customers to create shopping lists, find items in the store and compare prices at other stores.”
You could wait until the discovery or consultation call to start pulling this information out of them. But how many times have you done that, only to realize you’re not the right designer or studio for them?
By creating a streamlined, semi-automated lead generation process, you can save both yourself and these prospective clients time if you aren’t a good fit. As a bonus, this process will allow you to come better prepared for those first discussions with right-fit clients.
Your website can do so much more for your web design business besides advertise your services or store your portfolio. Here’s how you can set it up to streamline lead generation for you:
In order to directly influence leads to visit your website, you need to meet them where they’re at in Google. So it’s a good idea to familiarize yourself with the kinds of questions they’re asking or the searches they’re doing with relation to their website, app or other digital needs.
When planning out your SEO for lead generation, make sure to cover your bases.
For starters, some leads might cut straight to the chase and do a search like “design studio near me” or “web designer minneapolis.” This is where local SEO comes in handy.
One way to ensure your website ranks in local search and maps results for “near me” queries is to localize the content on your site as well as to add location-specific structured data. This won’t keep you from attracting leads outside of your region. However, if you live in a big metropolitan area, it could be beneficial to tap into that large pool of leads.
Another way to take advantage of local SEO is to create a Google Business page for yourself. That’s how the web designers you see in the screenshot above got listed in maps results. To make yours stand out, you’ll also want to collect client reviews so your star rating pops out at interested leads.
Now, for leads that haven’t quite decided to hire a designer yet, you’ll need to take a different approach to SEO.
For these types of leads, you’ll use informational products (i.e., blogs, videos or even free digital products like checklists or templates) to lure them into your lead generation funnel.
Let’s say you want to attract restaurateurs. What I would suggest is that you take the top questions and concerns you’ve gotten from former restaurant clients and answer them using blog or vlog posts.
For example, when I do a Google search for “does my restaurant website need to be accessible,” one of the top results points to a blog on the website for The Digital Restaurant, a digital marketing agency.
Leads who do this type of search are currently in the information-gathering phase, trying to figure out if they need to build an ADA-compliant website or if they can do it on their own. This post on its own can help them piece together that answer on their own.
However, they might get to the end of that post and decide that it’s just too much work or too difficult to do themselves. When that happens, a no-pressure call to action invites them to schedule a free consultation.
Whether it’s the homepage or header inviting leads to schedule a free consultation or discovery call, or an interior page or post doing it, this is how the lead generation funnel works. You meet the user wherever they’re at on Google (or on social media), convince them to go to your site and then offer a free call.
Before you get to the free call, you have to determine if it’s worth it—for either of you. This is where the prospect questionnaire enters the picture.
Rather than rely on a simple contact form, you’ll ask leads to answer brief questions related to their:
You can ask for more information if you’d like. It all depends on what sort of information you need in order to make a determination about their fit as a client.
The prospect questionnaire can be handled in a couple different ways.
One option is to replace your contact form with the questionnaire. This is how it’s done on the Contact page of the Your Designer Ash website:
Rather than give leads a bunch of open-ended questions to answer, the questionnaire is much easier to fill out. Pre-written answers are provided for many of the questions, some with context too.
For instance, the question about budget offers four dropdown options. Each contains a price range along with the types of services the prospective client can get for each.
This type of question-and-answer is useful as it helps leads to vet themselves. That said, the label above this particular question invites them to complete the form regardless:
“Help me understand what your budget looks like! If we aren’t a good fit, we probably know someone who is, or have a creative solution to offer! Please get in touch, regardless of budget.”
That’s a nice addition. So rather than leave them feeling as though they can’t afford good design services, they’ve found a resource who can put them in touch with a trusted designer who will work with their budget.
Another way to handle the prospect questionnaire is to do as Idolize Design does.
The general contact form remains on the Contact page. Below, however, are links to three Google Doc questionnaires. This will streamline the intake process as leads only have to fill out the questions pertaining to the service they need:
The form for web design services is a three-parter. The first page is all about the business, timeline and budget. My guess is that the others have to do more specifically with the website’s features, technologies and other requirements.
Having a well-built questionnaire is beneficial for a number of reasons.
For starters, prospects who aren’t willing to fill out this form—which takes just a few minutes—aren’t a good fit for you. Imagine how hard it would be to get them to send you their logo in the right format or to provide constructive feedback in a timely fashion if they can’t do this.
So that’s the first way this form will weed out the bad apples.
It will also tell you if a phone call is even worth it. If their budget is $500 and your design services start at $5,000, there’s no point in wasting their time or yours.
Plus, this form will help gather important details about your soon-to-be clients. Rather than spend all that time on the discovery call going through basic questions, let your form take care of it for you. Then you can spend the bulk of the call prepared to talk specifics and maybe even go over an action plan.
I also think these forms instill trust with prospects from the get-go. Having a form that anticipates their needs and clearly breaks everything down is a great way to show them that they’re in good hands.
The next step is to read through the submission and decide if you want to get on the phone with them.
For the ones you want to do a consultation with, you’ll need to do some prep ahead of time. First, put together an email template. Actually, you need to put together two email templates.
One is for the leads that you’re not going to move forward with. Keep the message simple, but do provide a brief explanation of why they’re not a good fit. For example:
Hello Manny,
Thanks for taking the time to fill out my form. While I would like to help with the new app for your business, I’m afraid I can’t. I only design ecommerce websites.
However, I happen to know a designer who does a beautiful job building ecommerce apps. Her name is Shelly and you can check out her portfolio here.
If you have any trouble getting in touch with her or if there’s anything else I can do for you, please let me know.
Ananda
If you can offer an alternative option in your message, that would be nice, though it’s not necessary. Providing a quick explanation of why you’re saying “no” will suffice.
The other email template you should have ready is for the leads you want to schedule a call with. This message will be more straightforward:
Hi Wanda,
Thanks for reaching out and taking the time to fill out my form!
I’d like to have a quick chat about your business, your website goals and how I can help in the long term. I can also give you a bit more information about my process and what to expect if you hire me.
Please use the link below and choose a date/time that works best for you!
Schedule Your Discovery Call
Talk soon,
Jonathan
This one you wouldn’t even need to customize aside from the person’s first name. What you would need to do in advance, though, is ensure your scheduler is set up properly. You can use a tool like Acuity Scheduling, Calendly or Doodle to create it if you don’t have one already.
In the end, you’ll have a page to send leads to that looks like this one for Creative813:
This is a simple scheduler page. It tells the lead who they’ll be meeting with (Mohamed), how long the meeting will be (30 minutes) and what they’ll discuss (website and business goals).
At the bottom, the lead selects the date and time of the call, fills in a few identification questions, and then schedules the meeting on their own. No back-and-forth with you is needed.
The scheduler page for weBOUND Marketing is just as effective:
The setup and process is similar. In three steps, the lead will select the date and time of their meeting with Bettina Wittman, they’ll enter some contact information and then they’ll confirm the appointment.
What this scheduler does especially well is it lays out the next steps for leads. Above the scheduling form it reads:
Please select a date and time that fits your schedule.
After you have scheduled your appointment you will receive an email including a calendar invitation with a link for the application Zoom.
This is the software we are using for all meetings online. You can easily access the meeting by clicking the Zoom-link.
By telling them ahead of time what to expect and how you’ll be meeting, you’ll cut down on last-minute issues where the prospect doesn’t understand what Zoom is or how to get into the room. You’ll also show them that you have things taken care of. From giving them an easy-to-use schedule to setting up the Zoom meeting room, you’ve got it all covered.
After the phone call is through, you are going to have to decide if you want to work with this client. It’s OK if you don’t. While they might look good on paper, the vibe might have been all wrong during the call.
Perhaps they seemed confused and disorganized, unsure of what it is they actually want. Perhaps they seemed pushy and started asking for free stuff already. Whatever it was, it’s OK to follow up, thank them for their time and politely turn them down (if you didn’t do it during the call).
You should have an email template ready to go for this:
Hello Grant,
Thank you for taking the time to chat with me earlier today.
While your website sounds like an exciting project to take on, I’m afraid I have to decline. If what you seek is a website that ranks on the first search engine results page immediately after launch, I’m not the designer you need.
I’d recommend contacting a design studio with a dedicated content marketing and SEO team as that’s the only way to guarantee those kinds of results in such a short timeframe.
Good luck with everything,
Kristin
While there’s no need to go deep into the specifics about why it’s not a good fit before you talk to a prospect, you should give them some details after you’ve had the call. Even if it’s a mismatch of personality, work style or expectations, find a way to soften the reason so it doesn’t come off accusatory.
For the clients and projects you’re excited to take on, you should have a template ready to send to them as well. Before you get to that point, though, you’ll need to get your proposal ready.
Your proposal is a branded document that includes the following details:
If you have a proposal template, it won’t take long to fill in the specifics. Proposal software like Better Proposals, PandaDoc and Proposify help you generate beautifully branded proposals. You can build them from-scratch or start with a template.
Here’s an example of one of PandaDoc’s fully customizable proposal templates:
By the way, some contract software includes an option for generating proposals, so check with yours before signing up for a new app.
Once you’ve built your proposal, it’s time to send off your follow-up email to the lead. Here’s an example of how you might write it up:
Hi Marco,
Thanks again for taking time to chat with me!
I’ve reviewed everything we discussed and here is what I’m suggesting:
View the Proposal
Take some time to look over what I’m proposing. I’ve included a revised budget and timeline based on our conversation as well as some alternative options if you wanted to go with the Website + Marketing package versus just a website.
If there’s anything on here you’re unsure of or want to change, let me know. Otherwise, I’ll draw up a contract and we can get started ASAP.
Looking forward to getting started,
Lila
This is the last step of the lead generation process. It’s now in the lead’s hands. If they decide not to move forward, that’s OK. Hold onto the proposal in case they change their minds later on. And if they decide to move forward, then it’s time to kick off your streamlined onboarding process.
Lead generation doesn’t have to be a time-consuming process. Nor does it need to be one that requires you to spend hours every week, scouring the web for new clients or projects.
Your website is a powerful sales tool. If you set it up right, you can also turn it into a lead generation machine that does a lot of the work for you. Not only that, it’ll help you make a great impression with prospective clients and to start every project off on the right foot.
]]>The Progress Champions program is a recognition for the best in our software industry—for developers, designers, testers, architects, advocates, partners and forward thinkers. We’re transforming our individual “MVP” offerings to a unified program structure. This will allow us to create a stronger, more impactful presence within the developer community. We’re starting off with Developer Tools and Sitefinity, with the ultimate goal to include the entire portfolio of Progress products. This will be an annual program with year-round nominations, evaluations in November/December and inductions/renewals in January.
Progress Software has a big portfolio of products—but modern developers often relate to Progress for a collection of frameworks and tools. This we collectively call Developer Tools—it includes Telerik UI suites for all things .NET, Kendo UI suites for all things JavaScript, reporting products, testing solutions, design utilities, network debugging with Fiddler and other developer productivity tools.
Developers learn from each other’s experiences, and it’s easy to share a love for tooling that makes developers more productive. Progress has always recognized and honored outstanding folks in the software community—influencers who lead with success, share knowledge and drive the developer community forward with empathy.
We’re glad to welcome this year’s group of Progress Champions in the Developer Tools space—you’re all awesome and we’re glad to have you as friends.
Here are the folks who were part of the older Telerik Ninja program—now renewed for 2024 as Progress Champions.
We’re delighted to welcome aboard several new Progress Champions for the year—from all around the world.
And congratulations to the Progress Sitefinity Champions, named on the Progress.com blog.
Progress Champions represent the very best in our community. Their commitment to excellence and collaboration is what moves us forward, and we are proud to be a part of their journey toward continued success.
Like with most honor programs, we recognize all that Progress Champions do and lead with empathy, but we also have a few expectations. As future prospects look to be Progress Champions, we want to be transparent as to what is expected annually—most Champions will easily go above and beyond.
Progress Champions are awesome, deserving of our unending love and adoration—and a few tangible benefits. We celebrate our Progress Champions with a range of exclusive perks and value our continued collaboration.
The Progress Champions program showcases excellence in the developer community and the passion to educate others to be more successful. If you work with Progress technologies, we appreciate the partnership. If you are passionate about Telerik UI suites for all things .NET, Kendo UI suites for all things JavaScript, Reporting suites, Testing solutions, Design utilities, Network Debugging with Fiddler or other developer productivity tools from Progress Software, we want to know. Know someone else who would be great fit to be a Progress Champion—we’re all ears. Nominations are open year-round. Evaluations will be in November/December 2024 for the next calendar year—we want to see your names.
Want to know more about the program? Drop us a line at champions@progress.com.
Upwards and onwards with Progress Champions—cheers.
]]>Browser extensions can be useful when it comes to streamlining various tasks throughout your workday. From securely logging into apps to performing website audits, you’re bound to find a Chrome browser extension that can help.
In this post, we’ll look at eight of the best Chrome and chromium extensions for designers and developers. There are also some tips at the end to help you keep your extensions from becoming as burdensome as a browser jam-packed with open tabs.
Browser extensions can be a huge boon for your productivity. And more often than not, they provide you with free, convenient functionality that takes no more than a click or two to access.
Here are seven of the most worthwhile and free Chrome browser extensions to install:
Note: I’m giving you recommendations based on browser extensions I either use or trust. Feel free to use alternative extensions that serve the same purpose.
There are numerous reasons to track your time. One of the main ones is to figure out how long your tasks take and, consequently, your entire process. This data will help you determine accurate project timelines as well as to set rates that make you a profit.
Regardless of why you track your time, having quick access to it in your browser bar with an extension like Toggl Track is a good idea.
Rather than it becoming another tab that’s easy to lose track of and to forget you’re even tracking your time, it sits up there running until you’re ready to stop it.
As a bonus, this browser adds a “Start timer” function to over 100 popular web apps. When enabled, you’ll have the ability to start and stop timers right where you’re working. For instance, this is what the tool looks like inside of Google Docs for me:
When clicked, it automatically generates a new task based on the name of whatever you’re working on. You can stop and start the timer from inside the app without ever having to open the browser extension.
Long gone are the days when you can get away with using the same password for all of your logins. While it was never a best practice, it was easy to get away with it when you had no more than a few apps and programs you had to long into.
However, you’re now probably using a dozen different apps every day. At least. To keep things safe, each password should be unique and contain a strong combination of letters, numbers, cases and characters.
The only reasonable way to manage this is with a password manager tool and to install its companion browser extension. The one I recommend is Zoho Vault.
When installed, all you have to do is enter your master password to gain access to your secure vault.
Not only does this extension allow you to autofill your login credentials with a single click, but you can create and store new passwords with it too. What’s more, if you generate a password in a new app, for instance, the extension (if still activated) will prompt you to store it in your vault.
Sometimes the best way to communicate what you’re seeing or experiencing in the browser or on your computer is to take a screenshot of it. You could use your device’s “print screen” functionality for that, but you’ll need another platform to edit your image or video.
The better option is to install a browser extension like Scrnli.
This browser extension gives you a variety of ways to capture what you’re seeing on your screen:
And once you’ve taken your screenshot or recording, you’ll have additional editing tools at your disposal.
Before you save the file to your device, the screengrab appears in a new browser tab with a toolbar at the top. You can use it to do things like draw on it, add text, draw shapes, insert arrows, blur sections, crop the image and more.
If you’re ever curious about the font, color or other CSS style used on a webpage, you could use the right-click “Inspect” function in your browser. However, it’s not always quick or easy to sift through all the data you find there.
CSS Peeper will give you a streamlined way to inspect any webpage.
When you first open the browser extension, the first thing it’ll do is give you basic details about:
You also have the option to export these styles.
That’s not the only thing this extension does when enabled. Click any element on the page and a list of styles will appear in the pop-up.
You’ll find information on things like:
This will come in handy when inspecting your own websites for errors or inconsistencies as well as digging into other websites for inspiration.
Whenever I perform an on-page SEO analysis for a new or existing client, one of the tools I turn to each time is the MozBar browser extension.
In order to use it, you need a free Moz account and to be logged into it. When activated, you’ll see SEO details at the top of any website or app you visit in your browser.
The first details you’ll find are the Page Authority (PA) score, Domain Authority (DA) score and the Spam Score. It’s when you open up the tools that you’ll find the really valuable stuff.
The On-Page Elements section, for instance, shows you all the metadata for the page—the SEO title, description, keywords and even alt text.
Under General Attributes, you’ll find the average loading time for the page. Link Metrics will tell you how popular the site is with others (i.e., how authoritative it is). And Markup will tell you if it has any structured data.
If you’re looking for a quick way to audit a website on your own or to show clients and prospects why their sites are underperforming, this browser extension is a must.
Whether you’re testing a newly built site for responsiveness or troubleshooting a buggy experience for one of your users, you’ll need the help of a responsive checker. Even if your design software helps you perform cross-device tests, you may need another tool to help you out.
If you’re not using it already, the Mobile Simulator browser extension is invaluable in this regard.
Once it’s installed, all you need to do is open the website you want to test and then click the browser extension. The page you’re looking at will disappear and this responsive testing screen will take its place. From here, you can:
It’s also worth mentioning that this is an interactive mockup. So you’re not just seeing a static copy of the top-of-the-fold area. You can scroll through the page and interact with it as if it were on your smartphone or tablet.
Checking that your website is compatible across devices isn’t enough to make it responsive. You also need to ensure that it works on all major browsers. It would also be useful to have a tool that enables you to test and debug websites in different browsers without having to install them on your computer.
That’s what the LambdaTest browser extension will allow you to do.
After you’ve created a free account (which will give you a limited number of tests), grab the Access Key from your profile settings and enter it into the browser extension. Once it’s enabled, click the browser icon to open the tool.
You’ll be able to get super specific about which browser you test. If you’ve ever had a client or user report a bug but you couldn’t reproduce it on your end, this should help you find it (so long as you can get that technical info from them).
From this dropdown, choose a desktop or mobile browser type, browser version, operating system, as well as screen resolution. When you hit “Start,” it will launch the testing tool in a new browser tab.
Use this tool to:
You also get access to the full website and app testing tool from here.
If you were to look around the Chrome extension store, you’d find hundreds of them to play with. However, just as you never want to load your digital products up with too many plugins, extensions or integrations, the same is true for your browser.
What I’d recommend you do is start adding new browser extensions one at a time. Use them a couple times and make sure each one improves how you work. Because some extensions conflict with one another and some, unfortunately, can cause issues with other desktop applications to open, you want to take your time with this.
Also, try to keep your active browser extensions to no more than 10. If you have some that you don’t need all the time, turn them off or hide them. That’s what I do with MozBar and Mobile Simulator, for instance. It declutters the extensions bar and also keeps that functionality from popping up when you don’t need it.
This post was prepared by Suzanne Scacca in their personal capacity. The opinions or representations expressed herein are the author’s own and do not necessarily reflect the views of Progress Software Corporation, or any of its affiliates or subsidiaries. All liability with respect to actions taken or not taken based on the contents of this post are hereby expressly disclaimed. The content on this posting is provided "as is" with no representations made that the content is error-free.
]]>One of the reasons why agencies hire project managers is to keep tight control over things. Another reason is so they have someone who can liaise with clients, business partners, upper management, etc. and leave them with a positive impression and satisfying experience.
That’s because a project manager isn’t just good at moving pieces around on a chessboard. They’ve also got a lot of soft skills needed to effectively coordinate and collaborate with others.
Whether you work on your own or as part of a larger product team or agency, it would be beneficial to adopt some of these project management skills and strategies. In addition to allowing you to work more efficiently, they’ll also help you make a more positive impression on anyone you work with.
Sometimes the best way to create better work relationships is to remove any doubts that the other person might have about you. And the best way to keep you from going crazy while doing this is to anticipate what those doubts may be and to proactively keep them from arising in the first place.
Here are some project management strategies that will help you do that:
Punctuality matters a good deal in business. While you may be caught up in your latest project or a huge task, if you commit to meeting with someone at a certain time, you need to be there and be on time. It’s also important to come prepared.
This goes back to the original idea of what kind of impression you want to make. So let’s switch gears here and put you in the other person’s shoes.
Let’s say you schedule a call with your developer. It’s time to hand off your designs to them. But you’re sitting on Zoom alone for five minutes … Then ten … Then fifteen. You’re starting to get antsy and wondering if you should do some work while you wait, but then they show up. And because they showed up 15 minutes late, that means the meeting is going to run longer than expected.
How would you feel about that person? And how would you feel if they were consistently late to your meetings?
You might think that they have no consideration for you or your own workload. You might also worry that if they struggle to get to a meeting on time that they might also have issues with managing their work and what that means for your team being able to meet project deadlines.
This is how things snowball in the minds of others when they’re left waiting and wondering. It’s not just the inconvenience of being late to a call. It’s the implications of what that constant tardiness and unresponsiveness means overall.
As a general practice, you should have a reliable system for managing your punctuality at work.
For example, I have Gmail send me a Daily Agenda email every morning based on my calendar’s appointments. You can set this up from your calendar’s settings page. Scroll down to “Other Notifications” and enable the “Daily Agenda” email.
With this setting enabled, I get an email first thing in the morning that tells me all of the events or meetings I have scheduled. Then I grab my phone and set alarms that wake me out of whatever work stupor I’m in before those meetings.
When setting these alarms, give yourself more than just a minute or two to spare. For some meetings, for instance, it’s beneficial to review your notes or whatever other agenda is going to be discussed. Also, you never know when Zoom or Google Meet is going to require a software update or just not work for you when you need it to.
So I generally aim to set my alarms five to 10 minutes in advance. Find a solution that works best for you. The goal is to be on time and prepared no matter what, but to not carve out so much time that you eat away at your productive hours.
I know that kanban boards tend to be a popular way to manage design and development jobs. The only problem with that methodology is the focus tends to be on project status or task completion instead of on time.
As a project manager, I was obsessed with time. While the end goal (i.e., launching the product) was important, I was also focused on managing our timeline so the job would be finished on time.
I recognized that if just one task wasn’t completed by a certain time, the whole timeline could get thrown off. And missed deadlines don’t just impact one person, they impact an entire team. Not only that, but they impact the other projects everyone is working on.
Have you ever had to go to a client or to your boss and explain that you’re going to be late delivering what was promised because another job got held up? It never feels good to do that. It doesn’t matter how many apologies you make, they’re not going to be happy with that excuse.
It’s kind of like how you’d feel if you scheduled movers to deliver your belongings to your new home by next Friday. Only, they call you that Friday afternoon to tell you they’re running behind because another job took too long. And because they don’t work weekends, you’ll have to wait until Monday to get your stuff moved in.
That’s exactly why a time-based task management system is a must. Here’s how I’d recommend you set this up:
First, do an audit of your tasks and figure out the average time it takes to complete each. You can use a manual time tracker like Toggl to do this or an automated one like RescueTime to do the calculations for you.
Second, create a template for your process in whatever project management software you use. This is what it might look like in Trello, for instance:
You can use the kanban board or checklist layout to document your process. However, I’d advise using calendar or timeline functionality to manage your work day to day. In Trello, I use a Calendar Power-Up for this. However, you can use premium project management tools like ClickUp that come with this functionality built right in if you prefer.
Once you know the average time it takes you to complete each task, add a start and end time or duration to every task in your project workflow. If you can visualize the time commitment you’re making for each task, it will help you more effectively plan your workload.
And if you want to ensure you never miss a milestone or deadline again, add buffers and breathing room around your tasks. These breaks are useful in case something runs long. They’re also great as they force you to take micro breaks throughout the day and workweek. These mini resets will help you return to your tasks feeling refreshed and ready to go.
Being able to demonstrate that you have a good handle on your time and are able to shuffle priorities around like a pro will reflect well on you. And it’ll make those who work with you feel more confident in your other capabilities as well.
Specifically, I’m talking about emails and any other written communication you do with others. There are different ways to improve this type of communication that will not only improve how you’re perceived, but also make your life much easier.
To start, focus on the speed of your responses. As a general rule of thumb, I’d say that every message you receive should be responded to within 24 hours, within reason. If you get an email at 5:05 p.m. on a Friday, you can obviously wait until Monday to get back to them.
And it’s okay if your response is something like this:
“I’ve received your message. I recognize it’s important, but I’m hip-deep in user testing right now. Let me wrap this up and I’ll give you a complete response by tomorrow EOD.”
I know it can be difficult to take time away from work to follow up on the messages that pile up over the course of the week. But, again, I’d urge you to think about this from the other side of things.
Let’s say you emailed a client, asking them for a workable logo file. You wouldn’t be too happy if you had to wait a week for their response, especially if the kickoff of the job were dependent on them getting you certain assets like their logo, style guide, etc.
Another way to improve your communications is to create templates for the most common ones you send. You can store them in an email platform like Gmail. Some project management systems also allow you to save reusable template messages.
For instance, this is how I retrieve a template when composing a message in Gmail:
There are various reasons to do this.
The first is that it makes your response times much faster. All you have to do is some light customization to your template and then hit “Send.”
The second is that it allows you to address common questions and scenarios in a consistent manner. The more consistent you are with how you handle things, the faster you’ll be able to work over time.
The third reason is that it will reduce the number of errors that appear in your messages. When writing templates, you’re able to take your time to craft the right response and to clean up misspellings, grammatical issues, unclear language, etc.
And a final reason to do this is to keep your responses even-keeled.
Let’s say you often have clients asking you to go just a little bit outside the scope. Over time, that sort of thing might eat away at you, leaving you to wonder why everyone’s trying to get free work from you or to test the strength of your contract. A template will allow you to keep emotion out of it and to prepare a message that is professional while firmly putting the matter to rest.
Just as you can anticipate certain risks that may occur in your work, you have a good idea of the kinds of conversations that take place from project to project and person to person. It may take some time to identify what all of those are, but this list of email template examples can help you get started and to fill in some of those blanks.
Once you have a good collection of email templates up and rolling, you’ll find that people are impressed by how timely, well-written and poised your communications are.
I once worked as a project manager for a medical device translation agency. Because we had so many different international standards and regulations that affected the products we were translating for, risk mitigation played a huge role in our workflow.
We considered the risks upfront and the ramifications of what would happen if something was incorrectly translated. We then developed our process and all the checks and balances along the way based on those risks. By being proactive about it, we were able to greatly minimize those problems and keep them from arising at all.
But you don’t need to be dealing with medical, financial or other regulatory compliance for your work to be full of risks. Anything that negatively impacts your productivity, timeline, budget, etc. is a risk and should be considered before you ever begin a job.
Take a look at your process as it stands now. Do you know what the common risks and hurdles are? And do you have processes in place not just to deal with them if they cause you trouble, but processes to keep them from happening in the first place?
Take, for example, the risk that clients themselves pose.
You can’t always predict every bad behavior of clients, coworkers or others on the job. But there are certain things—like the situations above—that you can expect to occur at some point and appropriately plan for.
Like I said above, being proactive is key. For instance, having an iron-clad client contract could help you mitigate the risks involved in those three situations. By setting expectations and reinforcing the rules of engagement upfront, clients will be less likely to act out.
Your process should also remind you to do things that keep risks low.
For instance, if you aren’t in the habit of getting your clients to designate one decision-maker at the start of a job, then you should add that to your onboarding process. Also, adding tasks that require that decision-maker to sign off on every major deliverable and to submit milestone payments before you move onto the next step would be helpful in keeping client-related disruptions low.
Of course, if you’re building digital products for industries with high risk factors—like the financial sector or healthcare industry—then your process should also address these product-related risks. But don’t wait until the prototypes are done or the products developed to start evaluating things. While your testing and quality assurance phases will likely catch major issues, it could be too costly to address them that late in the game.
You should be aware of the risks from the get-go and address them throughout the process.
Bottom line: By proactively identifying and addressing risks, those you work with and for will be impressed with how well-prepared you are and how smoothly things go.
Adopting project management strategies can certainly help you work more efficiently. Some of them can even help you create a more polished appearance.
By anticipating the top worries and doubts that clients, coworkers and others might have about you or your work, you’ll be able to proactively address them in the way you work. By keeping those doubts from ever arising, you’ll find that your work relationships become easier to manage and your projects will run more smoothly.
]]>Have you ever experienced deja vu while writing an email to someone? So what happens next?
You’re almost positive you wrote a similar message to someone else. So instead of rewriting it all over again, you scour your Sent box to see if you can copy and paste the previous one. That probably takes as much time, if not more, than writing the message from scratch.
There’s a more effective way to handle these repetitive communications in your creative business. From the shortest of messages like a “Here’s the link to …” email, to longer ones like a prospecting letter, a lot of this can be templatized.
Below I’m going to break down some common occasions when a template would come in handy and give you some tips on how to create them.
It doesn’t make sense to throw away tons of time or energy on something like email when you’re of more use and value when you’re flexing your creative and technical skills. That’s why I’m all about templatizing whatever you can in terms of administrative work.
Email templates don’t just reduce your administrative workload. They allow you to decrease your response time with clients. More importantly, templates give you a chance to refine your messaging so that every email is concise, easy to read and free from errors.
Before we take a look at which emails you can templatize, I want to make a couple of notes about using them.
First, you’d greatly benefit from saving your templates in the cloud.
If you work on your own, the best way to do this is by saving templates within your email platform. For instance, if you use Gmail or Google Workspace, you can save and access those templates within your email editor.
If you and your team want access to the same template repository, then saving the templates to the cloud will be a better option. Even just putting the templates in a place like Google Drive or your project management platform will make it easy for everyone to work from the same starting point and will allow your creative firm to maintain consistency in messaging across the organization.
Secondly, templates are not the same thing as canned responses.
Canned emails often come off sounding robotic, impersonal and generic. These are copy-and-paste responses that technical support teams use to ensure they handle certain matters consistently and on-brand. While consistency does matter, your clients, coworkers and others expect more from you.
Templates are meant to be customized. Not by a lot, but enough so that recipients feel as though you’re actively engaging with them.
Lastly, make every message sound professional yet personable.
Here are some tips for personalizing your templates:
I’ll provide some more tips in the templates below.
Whether you’re a solo freelancer or you work for a small design and dev shop, you’ll find that there are certain messages you send time and time again. I’ve tried to address the most common ones below.
Depending on the size of your firm, you might not be responsible for finding new leads. If you or anyone on your team does handle client prospecting, however, then having a template ready to go will be a huge help.
While you want to make your best pitch, you also want to address the context in which you discovered the prospect. For instance, you might find prospects by:
Regardless of how you’ve found them, you recognize a need that you can fill. So you should be able to keep some of your template the same from email to email. The rest of it, however, will need to be personalized.
Here’s how you might approach writing your prospecting letter template:
Hello John,
My name is Suzanne and I am a UX design lead with Agency X.
I found Cha-ching the other day as I was looking for investment apps in the Google app store. I installed the app and was impressed by the onboarding process. It does a great job of explaining the benefits of investing.
The reason I’m reaching out is because I found the app itself somewhat confusing to use. For instance:
- Issue #1
- Issue #2
- Issue #3
This is an issue that’s quite common with new fintech products. I’ve been working with mobile app companies like yours for five years and have helped dozens of clients to repair their user experience. Here are some of my recent projects:
- Link #1
- Link #2
- Link #3
If you are interested in speaking to me about Cha-Ching and how Agency X can be of service, feel free to schedule a free 15-minute consultation call with us here.
Looking forward to connecting with you,
Suzanne
Whenever you have something not so nice to tell someone, use the sandwiching technique. This is when you start out positive, throw in the negative commentary and then end on a lighter note. Just make sure the positive pieces of the message feel genuine, even if it’s as simple as closing with “Have a nice day.”
The ideal situation is to have leads chase you down for help. When they do come inquiring about your services, there are various ways to respond to them.
It all depends on what your vetting process looks like. For instance, the first thing I do is ask all interested prospects to fill out a questionnaire. Here’s what that template looks like:
Hi Marion,
Thank you for reaching out.
Before I can provide you with a quote for my services, I’d like to learn more about your needs first. Can you please fill out this questionnaire when you have a few minutes?
I’ll review your responses ASAP and let you know the next steps for moving forward.
Look forward to hearing from you,
Suzanne
Based on the responses, I have a set of templates written that help me quickly respond.
Not every prospect is going to be a good fit, so there’s no point wasting anyone’s time with a call. So one of my templates is a rejection letter, so to speak. I use it to provide a reason for why I can’t help and to suggest alternative providers or avenues to go.
Dear Marion,
Thank you for taking the time to fill out my form. Unfortunately, I won’t be able to help you at this time.
Typically, my website design services start at $2,000, but you indicated having a budget of $250. I’d suggest using a platform like Freelancer.com or Upwork to search for affordable design services. I’ve found some great freelancing talent there, so I’m sure you’ll be able to find someone to help with your boutique site.
If anything should change with your budget, let me know and we’ll schedule some time to talk.
Suzanne
If after reviewing the questionnaire I’ve determined that the prospect is a potential good fit, the next step is to get them on the phone for a consultation. In that case, this is the template I send them.
Hi Marion,
Thanks for reaching out and taking the time to fill out my form.
It looks as though we’d be a good fit. So what I’d like to do is have a quick chat about your goals for the website and to tell you a bit more about how I work.
Please use the calendar link below and choose a date/time that works best for you!
Book Your Consultation.
Talk soon,
Suzanne
Before you write these templates, make sure you have your prospecting and onboarding processes fully fleshed out. You’ll want to keep things moving just as quickly as your email responses have been.
Once a prospect has signed the contract and become your client, it’s time to kick off your project. And it all starts with a welcome email.
What your welcome emails include depends on your onboarding process. For instance, you might want to have a kickoff call with the client before you send them your onboarding questionnaire. Or you might want to send it to them all at once so you can review the questionnaire, client deliverables, etc. during the call.
Here’s an example of how you might frame this request:
Welcome aboard, Alex!
I’m really excited to get started and hope you are, too!
I know what a pain it can be to outsource a major part of your business to someone else. But I assure you that we’re going to make this as painless as possible.
I’d like to hop on Zoom for 30 minutes with you to review the project’s scope and timeline, introduce you to the team, and then discuss the various things we need from you before we get things rolling here.
When you get a second, please schedule the kickoff call on a day and time that works best for you.
Talk soon,
Suzanne
I try to save all the important details for the call. It can be too overwhelming for a client to think about all of those things right after they’ve signed the contract and made their first payment.
In the email after the call is where you can summarize what was discussed and send them a link to your onboarding questionnaire. Even though this message includes a summary, I tend to keep it simple. For example:
Hi Alex,
Thanks for taking the time to meet with us today. The team is excited to get started on your new website!
As we discussed, we’ll begin work as soon as we receive the completed questionnaire from you.
Start the Questionnaire
The questionnaire is stored on our secure server. So all of the business information, brand assets and login details you upload there will be private and protected.
When you’re done, we’ll begin working on your site. Just a reminder:
- Summary point #1 from the call
- Summary point #2 from the call
- Summary point #3 from the call
If you have any issues completing the form or have any remaining questions, please don’t hesitate to reach out.
Looking forward to getting started,
Suzanne
Over the course of your project, you’re going to need to loop the client in to review what you’ve done. The templates below can be used for mid-project milestones as well as when the product is finished and ready for final review prior to launch.
Out of all the templates on this list, these check-in emails will require the least amount of customization. They can be as simple as this:
Hi Yulie,
Our team has completed work on the first set of mockups for your health tech app. We’d like to review them with you in real time over Zoom. Do you have 30 minutes this week to go over what we’ve done and to discuss next steps?
Schedule the Call Here
Talk to you soon,
Suzanne
In addition to these check-in email templates, you should have wrap-up templates prepared. What you include in these will depend on what you require of your clients to move to the next stage. For example:
For any of these that apply, write a separate email template that summarizes what you need and provides a custom link so they can take action right away. For example:
Hi Yulie,
We’re so happy to hear that you’re thrilled with your new app. Once we receive your signature and approval, we’ll consider the project complete and we’ll schedule the app for launch next Monday.
Please review the project closure document and sign it when you’re ready.
If there’s anything else you need in the meantime, let us know. Otherwise, we’re looking forward to getting the Food Scale App into the Apple and Google app stores ASAP.
Suzanne
It’s also a good idea to add a Read Receipt to these messages since it’s crucial that these milestones and approvals get completed in a timely fashion. So knowing that they’ve seen the message will allow you to follow up if you’ve not received a timely response.
The client offboarding process can be just as lengthy and challenging to manage as onboarding. Having wrap-up email templates saved will at least help you coordinate these final steps with your clients.
The first message to send after the product has launched and the client has paid their final invoice is a meeting request. This email should explain the reason why it’s worth it to do one final call. For example:
Hi Ananda,
Congratulations on your new ecommerce site! Now that your shop is up and running, we’d like to meet one last time.
We’ll take you through the backend of your website. Since this is your first time using Sitefinity, we’d like to show you how easy it is to add new products, make content updates, upload images and so on.
We’re also going to review the deliverables package we’ll be sending you after the call. It’ll include the custom logos we designed, your new style guide and more.
As usual, pick a date and time that works best for you and we’ll chat with you then!
Suzanne
The next message you send will be after the wrap-up call and will include a link to the deliverables you owe them. You might also want to attach a copy of the offboarding call or even an instructional video that demonstrates how to access and use their CMS backend as a bonus.
Also, be sure to include a thank-you at the bottom, letting them know what a pleasure it was to work with them and that you hope to work with them in the future. This will close things out on a high note while planting the seeds for re-engagement.
This last set of emails can be sent out at your own pace. Typically, I suggest following up with clients every few months. That way, you stay top-of-mind with them after launch while not overly pestering them.
As for which emails you need to send, it depends on what you want from the client.
For example, you might like to ask them for a testimonial. Here’s what you could send in that case:
Hi Frank,
It’s been a few months since we last spoke and I wanted to see how things are going with your new site. I noticed that it’s now ranking for “top law firms in Houston” and was curious to see how it’s impacting things on your end.
I also wanted to see if you’d be interested in leaving a review for our agency on Google. We had such a great time working with you and your company, and we’d appreciate it if you could let others know what the experience was like.
You’ll find our Google Business page and review link here.
Thank you again for entrusting us with your website and we look forward to working with you again in the future!
Suzanne
You can also use follow-up emails to find out how things are going and to not ask for anything in return. You can send them educational materials like blog posts, YouTube videos or documentation that help them get more out of the product you built for them.
The purpose of these emails is to deliver more value so that when they do need another product built or an old one redesigned, they think of you first thing.
Emailing prospects, clients, team members and others can become a tedious process if you’re having to write everything from scratch every single time. If you take a look at your outbox, I bet you’ll find that you have a tendency to send similar messaging to your contacts over time, too.
Rather than waste your time writing brand new emails every time you need to connect with someone, create a system of customizable email templates that will do a good chunk of the work for you.
By the way, don’t let the list above stop you from creating templates for other common messages you send or from changing up what I’ve included in them. These email template ideas are just a starting point for you to think about ways to templatize and improve your communications going forward.
]]>Caution: This article aims to provoke you to ask yourself, your colleague, your manager or your team some accessibility-related questions that could be crucial for your project. This article wants to make you look at your websites and applications from a different perspective and take action before it is too late.
To make it more interesting, let’s look at the following article as if it is a movie. That special genre of movies where we jump from one scene to another and there is not an obvious relation between each situation, but somehow you know there is. Usually, in these movies, we receive some hints about the further movie development in the form of questions. Sometimes the key is in the text we see. One thing is sure here—everything is revealed at the end of the movie, and we can make a truly informed life-changing decision.
So here starts our story.
Today, everyone is focused on aligning their websites/applications with the Section 508 and WAI-ARIA accessibility rules. The accessibility tests are already a “must-have” in almost every enterprise and non-enterprise company. Many people test their products on different screen readers. There are even businesses that test their applications on all screen readers ever released on the market.
The storyteller: “Meet George, who has a task to make the application he is working on fully accessible. He knows that all of the above is 100% correct, but, still, there is something that bothers him.”
And this is the place where the “rising action” of our story starts building.
Imperceptibly, the first life-changing question in the movie pops and the main character asks himself:
“Is my application accessible if I am covering the Section 508 and WAI-ARIA rules?”
The narration continues…
For some people, the accessibility story completes when your product meets the above-mentioned accessibility rules. For the other part of the companies or developers, to say that a given project is accessible, it should also work on different screen sizes and device types. Although it is not a must-have feature,
“The components’ adaptiveness is already becoming an industry standard when talking about accessibility, usability and general user experience on all devices.”
For those of you who still don’t think that an adaptive design should be implemented in an application, take your phone, open a link with a complex form inside it in “desktop” mode, and try to fill the form in. Now open the same link in “mobile” mode and repeat the previous action. Don’t tell us what your experience was. We know the answer.
We are already close to the climax of the story and our character asks the next fundamental question:
“OK, we need adaptive rendering. I am starting the implementation!”
To make the scene more intriguing, suddenly George finds himself in the past remembering a conversation with an ex-colleague who shares insights, steps and efforts he had to make to implement adaptive rendering in that application back then.
A “short” to-do list of prerequisites and implementation tasks appears on the screen:
To build the tension, the narrator continues:
“The above list can surely be improved, but think about the project management time, the design hours, the development time and, finally, what the financial cost of the whole implementation process will be.”
We are about to go through the turning point of our story. This part is very short but very important. Our character feels confused. He starts doubting himself if the decision about the adaptive rendering is correct and worth it.
- Should I implement adaptive rendering in my next project?
- Is it worth implementing the adaptive rendering all by myself?
The scene ends.
We see George, who tests the usability of a project with some colleagues while discussing what a good decision it was to use Progress Kendo UI for Vue. From the conversation, we understand that there weren’t very specific requirements for their application, and this is how they decided to use the Kendo UI for Vue DropDowns for their adaptive scenarios.
The story continues with a scene where George is awarded for his decision and presents the features of the Kendo UI for Vue DropDown components to other fellow developers:
“The adaptive mode of the ComboBox, DropDownList, MultiSelect, DropDownTree and MultiSelectTree components is easy to configure by using the adaptive and adaptiveTitle properties of each component.”
The presentation continues…
The adaptive property accepts true or false as values and based on this configuration the components will or won’t automatically activate their adaptive design on different screens. The adaptiveTitle property defines the text that will be rendered in the header of the component when it operates in adaptive mode.
When the adaptive mode is active, each of the listed above components has three rendering states:
“Here is a demo of the DropDownList’s Adaptive Rendering. We can see each rendering state of the component.”
For more details about the adaptive rendering of the DropDownList and how it can be configured to work also with grouped data, check this documentation article.
And this is how the presentation continues …
… Stepping into the ComboBox, here is what its Adaptive Mode looks like. The component works both with regular and grouped data in all its rendering modes.
The Adaptive Rendering documentation of the ComboBox provides additional details related to its configuration.
… Here is the MultiSelect Adaptive Mode. This is what its medium screen size rendering looks like:
Details about the adaptive rendering of the MultiSelect and its configuration can be found here.
… Talking about components that handle tree-like data structure, the DropDownTree and MultiSelectTree have their Adaptive Mode options. Here is what the DropDownTree looks like in Adaptive Mode:
… And this is the MultiSelectTree in middle-sized screens:
The documentation of the components reveals more details about each of them. Check it here for the DropDownTree and here for the MultiSelectTree.
The presentation ends with a standing ovation.
We enter the final scene. Everyone is happy and the character makes a recap of the struggles and pains he passed through. The conclusions he summarizes are:
“No. We don’t need to implement custom solutions.”
… appears on the screen and this is how our story ends.
Someone will ask here, “And what about the dilemma mentioned in the topic?” Well, the moral of the story is that the adaptive dilemma is not a dilemma if you use the Kendo UI for Vue Native DropDowns in your applications. The character saved hours of project management, design, development and testing time just by using the Vue DropDown components.
As a final side note, I would add here that the next time you start a project, put yourself in the shoes of our character. If you want your project to be fully accessible and support multiple devices, ask yourself the questions he went through. If you are honest with yourself and don’t have special project requirements, use the Kendo UI for Vue DropDowns and save time, effort and money—both for you and your company.
The above article is a result of our continuous effort to maintain the high level of accessibility and usability in the different Kendo UI for Vue components. More accessibility improvements and usability features are coming. Stay tuned!
Be the hero in your own story: Try Kendo UI for Vue free for 30 days!
]]>A lot of people depend heavily on the internet to get stuff done in their lives and businesses. So what happens when they encounter an app or website that they’re unable to use because of a permanent, temporary or situational impairment?
Some people will simply back out of the site or app and find a suitable and accessible alternative that caters to their needs. Others might not be content with that option. They might leave a bad review online—on Google, the app store, Yelp, etc.—in order to let their dissatisfaction be known and to warn off others.
Then there are those who will take it to the extreme. When it comes to accessibility, consumers now have legislation on their side (like the Americans with Disabilities Act in the U.S.) that enables them to move forward with compliance demands and lawsuits.
As a web designer, what should you do if one of your clients or employers receives a digital accessibility violation notice or if a lawsuit is brought against them? This post will walk you through the basic steps.
Whether you’ve received a complaint from one of your users or your product has been formally accused of a serious web accessibility infraction, time is of the essence. Here’s what you’ll need to do:
An inaccessibility complaint can come from a variety of places and in a variety of manners.
One person might fill out your contact form or feedback widget to let you know something’s wrong. Another might send a notice to inform you of the accessibility issue and a timeframe within which it must be fixed. And yet another might go straight for a lawsuit.
In whatever manner the complaint comes through, it must not be ignored. It’s similar to receiving negative feedback on social media or in one’s place of business. If you ignore it, dismiss it and don’t take it seriously, it’s likely to escalate.
So the second your client or employer catches wind of the issue (if it doesn’t come straight to you), read through the complaint carefully. You want to get a full understanding of where the accessibility issue is and who has been impacted before you do anything else.
The number of accessibility digital lawsuits rises with each passing year. It’s not just because consumers feel emboldened to sue companies over inaccessibility claims.
Websites and apps are getting more complex. This is something that the WebAIM Million tracks from year to year. Between February 2022 and February 2023, homepages went from having an average of 955 elements to 1050.
More elements and greater complexity opens the door for more issues if accessibility remains unchecked. In fact, each of the top 1 million website homepages have an average of 50+ accessibility errors on them.
Having an inaccessible product doesn’t necessarily open you up to the possibility of a formal complaint or lawsuit though. It’s important to check that your website or app is specifically targeted by your local accessibility legislation.
For instance, the U.S. Department of Justice Civil Rights Division explicitly stated in 2022 that the ADA is enforceable when it comes to two types of entities:
The latter category covers any business that offers goods and services to the general public. The DOJ gives the following examples:
Not only do these types of government entities and business establishments need to be physically accessible according to the ADA, so too do their websites.
That doesn’t mean that all other types of websites and apps are safe from accessibility-related lawsuits. Ideally, every digital product should be able to meet Level A compliance of the WCAG.
Once you’ve determined that your product does indeed have accessibility issues that need addressing, it’s time to do an audit.
You can perform the audit internally or hire an external accessibility expert to handle it. I’d say that the severity of the complaint should dictate who handles it. In other words, if a costly lawsuit is involved, outsource it to someone with experience in the matter.
As for what to audit, don’t assume that the consumer’s complaint covers the entirety of the issue. Even if the notice only calls attention to a lack of sitemap or the lawsuit states that a certain feature can’t be accessed by a screen reader, there could be other issues.
It’s best to perform accessibility tests of your entire digital product.
The Web Accessibility Initiative has a helpful list of accessibility evaluation tools that’s worth checking out. When choosing which ones to use, cover as many bases as you can. For instance, you should have tools that allow you to check things like color contrast, broken links, code, responsiveness, screen reader compatibility and more.
Regardless of how the complaint came in, this step is all about remediation.
Your client or employer will need to acknowledge the complaint if they haven’t done so already. This process may take a bit longer if a lawyer needs to get involved. But in terms of engaging with the consumer or end user, that responsibility should fall on them so they can address the issue, acknowledge the fault and also provide a brief plan for remediation (i.e., what will be fixed and how long it will take).
It’s then up to you to go in and repair the inaccessible components of the digital product—ideally, in a staging environment.
First, make a checklist of all the issues as well as all the components and pages impacted. If any of the inaccessible elements play a critical role in the user journey (something like the checkout page or reservation form), you might want to put the site or app under construction while you repair it.
It’s not like you’re going to receive a barrage of accessibility lawsuits in the meantime. However, if you’re in the habit of putting the site under construction whenever you perform any maintenance or major updates, you should do the same with this.
Once you’ve implemented the changes, have another team member step in for quality control. Let them manually review the update and then have them use the same accessibility tools you used to initially detect the issues.
After restoring accessibility, remove the under-construction page and push the updates to the live site.
It should never be the responsibility of your users to report issues with your product. For starters, it does terrible things to the trust and relationship that brands have to work really hard to establish with customers. Secondly, many users won’t report the issues. They’ll simply jump ship and find a product that works.
Customer trust and retention are critical to the success of brands today. Your digital products need to be built for both, so your web design process will need to become proactive if it isn’t already.
First, add a section for digital accessibility to your web design checklist.
Determine first which level of the WCAG 2.1 your product needs to comply with—Level A, AA or AAA. AA is the most common. Then add all the relevant accessibility tasks to your list so that they get addressed every time you design or redesign a product. Again, here’s the list of accessibility requirements and techniques.
Your design process should already have a section for quality analysis and testing. The set of tools you used to detect accessibility issues and audit your product should be added to that part of your workflow.
Next, schedule time for accessibility audits.
If you’ve built a product that will be susceptible to the ADA or other local regulations, these audits are essential.
If this is going to be necessary for your product, it should be determined before you even submit a proposal or contract to a client. It will require ongoing checks and maintenance after launch and, thus, it’ll impact the budget for the job.
One other thing to consider when it comes to audits is usability testing. I’m not saying that this is necessary. However, if you’re already doing user testing to optimize your products post-launch, then start factoring in accessibility as well.
Lastly, stay on top of the subject of digital accessibility.
Version 2.2 of the WCAG came out in 2023, so you’ll want to update your accessibility task list if anything major changed with that.
Outside of official accessibility guidelines and legislation, it’s also a good idea to watch for accessibility-related posts. You’ll find tons of useful guidance on tips and tools as it relates to building accessible digital products.
For instance, the Telerik blog has covered this topic from various angles:
Find sources that you trust and pay close attention to what they’re putting out in terms of accessibility. As the guidelines change and as techniques for building it into products evolve, you’ll be the first to know about it all.
Even if there’s no threat of an accessibility lawsuit right now, that doesn’t mean you shouldn’t take this matter seriously. Accessibility is a critical part of what makes a digital product usable. It also has an impact on how well websites rank in search engines.
Whatever your goals and priorities are when building digital products, usability and rankability are likely high up there. So whether you know it or not, accessibility is a top priority for you as well, and your web design process and strategies need to reflect that.
The information provided on this blog does not, and is not intended to, constitute legal advice. Any reader who needs legal advice should contact their counsel to obtain advice with respect to any particular legal matter. No reader, user or browser of this content should act or refrain from acting on the basis of information herein without first seeking legal advice from counsel in their relevant jurisdiction.
]]>As the internet continues to connect people across the globe, designing and developing web applications that cater to users from different regions and locales has become essential. This process, known as internalization, ensures that our applications are accessible, functional and culturally appropriate for users worldwide.
In this article, we’ll explore the importance of internalization in web development and discuss some steps we can take to achieve it effectively.
Internationalization, often abbreviated as i18n (where 18 represents the number of omitted letters between “i” and “n”), is the process of designing and developing an application in a way that allows for easy localization to different languages, regions and cultural contexts. It involves separating the user interface and content from the application’s codebase to facilitate easy translation and adaptation.
For the rest of the article, we’ll list a few important thoughts to keep in mind when attempting to achieve effective internationalization within an application.
One of the most important things we can do to facilitate easy translation and adaptation of text in our app is to extract all user-facing text strings from our code and store them in external resource files or databases.
For example, instead of hardcoding a text string in our JavaScript code like this:
const greeting = "Hello, World!";
We can store it in a separate resource file like en.json
:
{
"greeting": "Hello, World!"
}
Once we’ve separated our text strings from the code and stored them in external resource files, we can easily create translation files for other languages. These translation files will contain the translated versions of the text strings.
For example, to create a translation file for another language, such as French, we can create a new resource file named fr.json
:
{
"greeting": "Bonjour, le monde !"
}
We can repeat this process for any additional languages we want to support, creating a new translation file for each language and providing the appropriate translations.
es.json (Spanish)
{
"greeting": "¡Hola, Mundo!"
}
de.json (German)
{
"greeting": "Hallo, Welt!"
}
Each translation file follows the same structure, with the same keys as the original resource file (en.json
in this case), but with translated values specific to the target language.
Once we’ve created the translation files for different languages, we can make use of localization libraries to handle the loading and retrieval of translations in our application. These libraries provide convenient methods and tools for managing translations and dynamically switching between different languages.
One popular localization library in JavaScript is i18next. It offers powerful features for handling internationalization and localization, such as string translation, interpolation, pluralization and more. Here’s an example of how we can import and initialize i18next
to handle localization in our application:
import i18next from "i18next";
import en from "./en.json";
import fr from "./fr.json";
import es from "./es.json";
import de from "./de.json";
i18next.init({
lng: "en", // Set the default language
resources: {
en: {
translation: en,
},
fr: {
translation: fr,
},
es: {
translation: es,
},
de: {
translation: de,
},
},
});
In this example, we initialize i18next
and provide the default language as 'en'
(English). The resources
object contains the translation data for each language. Each language is identified by its language code (e.g., 'en'
, 'fr'
, 'es'
, 'de'
) and has a nested translation
object that holds the translated text strings.
With our translation setup initialized, we can then use the i18next.t()
function anywhere in our app to receive translated strings based on the translation key that has been specified and the user’s selected language.
const greeting = i18next.t("greeting");
console.log(greeting); // Outputs the appropriate greeting based on the user's locale
Lastly, we’ll want to provide the end user the capability to switch between different languages. The i18next
library provides the changeLanguage()
method we can use to dynamically switch the language in our application. This will trigger i18next
to load and display the translations for the chosen language.
i18next.changeLanguage("fr"); // Switch to French
Localization libraries like i18next often offer additional features and functionalities to handle complex translation scenarios, such as pluralization, gender-based translations and variable interpolation. Be sure to check the documentation of the specific library you choose for more information on advanced usage.
Dates, times and numbers often have different formats across locales. We should make use of localization libraries or built-in language features available in our programming language to ensure accurate and localized formatting of dates, times and numbers.
In JavaScript, the Intl object provides a set of features for formatting dates, times, and numbers according to different locales. Here’s an example of formatting a date in the en-US
locale.
const date = new Date();
const options = { year: "numeric", month: "long", day: "numeric" };
const formattedDate = new Intl.DateTimeFormat("en-US", options).format(date);
console.log(formattedDate);
// Output: June 30, 2023
Here’s another example of using the Intl
object to format numbers differently between the United States and Germany.
const number = 1004580.89;
const formattedNumberDE = new Intl.NumberFormat("de-DE").format(number);
const formattedNumberUS = new Intl.NumberFormat("en-US").format(number);
console.log(formattedNumberDE); // Output: 1.004.580,89
console.log(formattedNumberUS); // Output: 1,004,580.89
We will provide a more detailed deep-dive into the Intl
object and its features in an upcoming post.
In addition to supporting different languages, it’s essential to consider the layout and text alignment for languages that are written from right to left (RTL), such as Arabic, Hebrew and Urdu. Adapting our application’s layout and text direction for RTL languages is important for providing a seamless experience to users in those regions.
CSS provides a dir property that we can utilize to handle RTL text. By setting the dir
property to rtl
(or auto
, which lets the user agent decide), we can ensure that text and elements within our application are correctly aligned for RTL languages.
<p dir="ltr">This paragraph is in English and correctly goes left to right.</p>
<hr />
<p dir="rtl">
هذه الفقرة باللغة العربية ، لذا يجب الانتقال من اليمين إلى اليسار.
</p>
In the above code example, we align the separate English and Arabic text in the appropriate alignment.
In conclusion, internationalization (i18n) is a crucial process in web development that allows applications to cater to users from different regions and locales.
By separating text from code, utilizing localization libraries like i18next; formatting dates, times and numbers appropriately; and considering right-to-left (RTL) languages, we can create applications that are more accessible, functional and culturally appropriate for a global audience.
In addition to the steps mentioned in this article, there are other considerations for internationalization, such as support for currency and units of measurement and accessibility. In follow-up articles, we’ll go through some of these other considerations that need to be kept in mind as well as a practical exercise of installing and using an internalization library within a JavaScript application.
]]>Software testing mistakes happen as they do in most professional positions. Mistakes happen to everyone at some point during the span of a career. The more projects you test with unorganized processes, poor requirements or ineffective communication, the increased likelihood of one or multiple mistakes.
For example, most Agile teams make a point of team members practicing accountability. Part of accountability is being honest when you make a mistake and working toward a solution to prevent the error happening again in the future.
When testers make mistakes, it’s hard not to feel guilty, nervous about job status or simply horrible for the flub-up. The good news is making mistakes is a fact of life as a professional tester. It’s what happens afterward that determines if you bounce back.
This guide describes the importance of accountability, being honest about mistakes, and how to recover professional credibility and confidence.
Accountability is embracing your mistakes, making them public and experiencing the learning that comes from them. As a software tester, being responsible and accountable requires honesty and professional integrity. Testers must fight the urge to disappear into the background or direct blame elsewhere. The impact of the mistake passes faster when you focus on future prevention and remain open, honest and fully accountable.
It takes professional courage to admit a mistake. Sometimes it’s the mistakes that guide your career path and contribute to your testing expertise. Making a mistake may force you to slow down and concentrate more closely on testing. Mistakes may convince a tester to be bold and ask as many questions as necessary. Regardless of the size or impact of the mistake, the important part is to move forward. During your testing career, you’ll experience management and business process failures more than once. Many of those may be the root cause of the mistake you make. It’s important to acknowledge the mistake and fix it by moving forward. Find a resolution, correct what you can and then create solutions that keep the mistake from happening again.
When that sinking feeling of dread sinks in, and you realize you made a testing mistake take steps to acknowledge it to your peers and development team. When acknowledging a mistake, don’t torture yourself, quit or put yourself down. Just detail the mistake, how it happened and how you intend to address the problem so it doesn’t happen again. Acknowledging and accepting responsibility for mistakes is practicing professional accountability.
Wouldn’t it be easier to attempt to disguise the mistake, run away from it or blame someone or something else? No. Mistakes are normal, even though when we make mistakes at work we feel our livelihood is immediately threatened. Mistakes are a learning opportunity for professional growth when they are acknowledged, accepted and corrected.
If you attempt to be dishonest about mistakes, the truth will eventually come out. How do you think that makes you look as a team member? Accountable? No. Dishonest and possibly conniving? Yes.
Strong and productive software development teams are built on trust between team members including software testers. Effective software testing teams operate more effectively and efficiently where trust between team members exists. Don’t destroy the trust you’ve built up by trying to cover mistakes. Be accountable, learn and move on.
Think of it this way. Why do development need software testers in the first place? To find defects or mistakes before customers experience them. Why do newspapers employ editors? For the same reason—to find mistakes writers make in copy and correct them. Mistakes are part of work life and honesty is the best policy.
Although everyone makes mistakes at work, it still feels terrible when it happens. It’s difficult not to let fear keep you from moving forward or taking on risk. Don’t let mistakes hold you back. It’s important to work toward regaining your confidence and testing credibility.
By moving on, you are working on repairing your testing credibility and the dent in your testing confidence. Testing mistakes may temporarily impact your career path and undermine your confidence. Learn from mistakes and grow your testing experience rather than letting mistakes ruin your work life.
Steps for rebuilding your confidence and testing credibility include:
Rebuild confidence and credibility by moving forward. Mistakes happen frequently in software development, so if the spotlight is on your mistake now, wait a moment and it’ll move to some other lucky soul. One mistake doesn’t have to derail your career. Failure is part of life, as is your response to it. Demonstrate professionalism and resilience and get back to work.
Remember that making mistakes is a fact of professional testing life. Everyone remembers a time when they wished they’d stopped and double-checked a test result or stopped trying to multitask during test executions. Yes, mistakes feel horrible, but as long as you learn from them and move on, you’ll continue your professional growth in a positive direction.
]]>Need a testing tool that can help software testing teams be more productive? Check out Progress Telerik Test Studio and see how it can help organize your software testing and help you prevent mistakes the first time around.
Pull Requests (PRs) are a crucial aspect of the modern development workflow and are a mechanism for submitting code changes to a shared repository. In a previous article, we discussed simple steps one can take to create great pull requests, particularly when working with large teams with multiple developers.
In today’s article, we’ll discuss practical tips you can take to be a good pull request reviewer. Reviewing pull requests effectively helps ensure code quality, promotes collaboration and maintains a healthy development process within a team.
A pull request serves as a formal submission of code changes for review. When one begins the review process of a pull request, it’s important to first briefly understand the purpose of the pull request and what the code changes entail. Is your colleague/teammate creating a new feature, making a bug fix, improving code cleanliness or making some other form of code change?
This context can often be gained by reading through the pull request documentation and gaining a high-level understanding of the code’s intended outcome. Once this context is understood, the following steps listed in the article can help guide the rest of your review process.
Once the goal of the pull request is understood, the next suitable step in the review process is to walk through the code changes.
It can be helpful to first review the code changes on a high level before narrowing down to the specific line changes/additions/deletions that are being made. This entails first understanding what part of the codebase is being changed; which files are being added, modified, deleted; and what pattern of changes the developer is making.
Once the proposed code changes are understood, you can then move to examining how the developer has implemented the code changes while paying attention to items like code organization and adherence to coding standards and team guidelines. This includes looking for things like code clarity, modularity and consistency in naming conventions.
To fully comprehend the code’s behavior, sometimes it can be helpful to pull down the pull request branch and run the proposed code changes locally. When code changes are being run locally, we can utilize debuggers, step through the changes and observe the effects caused by the new code in more hands-on approach.
Running the code locally can enable a deeper understanding of the code and help us identify any potential issues that are more difficult to catch by simply reading the code changes.
Feedback can be placed on a pull request by providing comments on the entire pull request or specific code line changes.
Pull request comments can often be categorized into the following:
Kudos – Comments that acknowledge and appreciate the developer’s work by highlighting the areas where they have excelled and/or done well. Recognizing a colleague’s effort not only boosts morale but also reinforces positive practices and encourages the teammate to continue their good work. It also leaves a paper trail that the colleague can use during performance reviews within their team and organization.
Questions – Comments to gather more context and understanding where needed. This helps both the reviewer and the developer clarify any uncertainties and promotes a constructive dialogue, leading to improved code quality.
Nitpicks – Comments that note minor issues that do not hinder the pull request from being merged but serve as reminders for future improvements.
When suggesting modifications, ensure that comments clearly describe the issue and include specific suggestions for improvement. It’s helpful to be descriptive when providing suggestions, by providing code snippets and pseudo-code where applicable since actionable suggestions makes it easier for the developer to make the necessary changes.
Throughout the review process, it is important to always approach the code review with positivity and empathy. Remember that constructive feedback and collaboration are key to helping foster a positive environment that encourages growth and improvement.
Recognize that your teammates and colleagues invest time and effort into their code, and feedback should be delivered respectfully by focusing on the code and never the individual. By fostering empathy and maintaining a supportive atmosphere, you can help promote a healthy code review culture within the team.
Conducting effective pull request reviews plays a vital role in maintaining code quality and promoting collaboration within a development team. By understanding the pull request, walking through the code changes, testing locally where applicable, providing feedback and emphasizing empathy—you can ensure an effective review process for pull request changes, promote continuous improvement and contribute to the overall success of the project.
]]>In today’s digital business world, QA testers must work within an Agile development team, side by side with an array of developers, from a variety of locales. Working with a diverse group of professionals presents a challenge as well as valuable skill development opportunities.
Agile teams are also often on tight iteration schedules that require a collaborative working relationship between development and QA. Exceptional communication skills along with a strong aptitude for empathy, inclusion, and mutual respect are required to handle the constant push-and-pull of ideas between team members.
This article provides tips for developing constructive and positive working relationships with developers as a QA tester. We’ll cover the challenges of working with developers, specific habits to cultivate to create stronger relationships, and finally, how to leverage developer knowledge to improve your test automation.
Within your QA career, you may encounter developers who are hard to work with, even unapproachable. They may seem more focused on their code rather than in QA’s opinion. On the other hand, QA testers may appear to developers as overly negative, always asking questions, interrupting work and adding to it.
It isn’t always easy working within a team—even a small, Agile development team. Working productively within a team means developing a professional work personality and forming productive work relationships. Developers don’t need to be your best friend, but you have to find a way to work with them in a positive, constructive and respectful manner.
One way to work with developers effectively is to build a work personality. Your work personality should act logically and responsibly and approach issues calmly and professionally. Your work personality is a persona you create to work inclusively and professionally with a varied group of developers.
Keep in mind developers tend to be both creative and logical. Learn to work productively with them by building a working relationship built on mutual respect and professionalism.
Start with R-E-S-P-E-C-T and develop a working relationship that enables mutual respect and inclusive behaviors. Keep discussions logical and focused on business objectives and leave personal differences outside the workplace.
Remember to take initiative for training, learning, resolving issues and participating in meetings and reviews. Make QA work visible and accessible for developers. Share test cases, reference documentation and allow developers to better understand how QA testing functions.
Exceptional testers develop positive working relationships with developers by:
Always remember to focus on application quality and the customer experience instead of testing to test. Remember to act and think like a customer and test from the customer’s perspective. Everyone on a development team is responsible for releasing a quality product, so avoid creating a division between QA and Development. Collaborate for the benefit of the team, the business and the customer.
Teams have power dynamics—it’s human nature to have both leaders and followers. The same holds true for QAs and developers within a software development team. Regardless of their role, dominant team members push their ideas into every team conversation and interaction.
For example, you may test for two dominant developers with polar-opposite opinions. Meetings and discussions turn into stalemates. Team members pick sides, and a division begins. If left without management intervention, the power dynamic can bring a team to a complete stop.
QA testers may consider attempting to mediate stalemates or request help from team leaders or product managers. There must be a voice that breaks the stalemate and avoids division. If a compromise cannot be negotiated, then team management or an architect or dev lead must decide.
As a QA tester, try to build rapport with both dominant views. Help mitigate discussions by presenting the pros and cons for each. Perhaps manage an anonymous poll that allows members to vote with less direct intimidation. Practice being calm, logical, assertive and respectful while making your point and presenting options to move the team forward. Try to stay neutral and focus on what best meets business and customer needs. Prepare for criticism but don’t take it personally. Use criticism as a way to improve your ideas.
While QA typically has less power than developers, QA testers can still thrive within a team. Participate actively, ask as many questions as you need to understand and don’t be afraid to step in and take control when a power dynamic threatens to bring the team to a halt.
As a QA tester, you have great influence. What? How? You’re in a prime position to leverage developer knowledge to the team’s advantage. Specifically, focus on leveraging developer code knowledge to improve automated test development.
Have you ever found that the QA team is treading water or worse trying to create maintainable and effective test automation? That’s the perfect opportunity to show QA initiative. Select a developer or two and ask their opinions on automated test development. Explain the situation and ask for opinions on how to best create and execute test automation. Show examples of where QA is running into trouble. Take notes and try each developer’s suggestions. If you’re lucky, you’ll find a developer who enjoys teaching.
Make the most of the opportunity to improve QA test automation effectiveness, validity and efficiency. With the right developer partner, QA test automation provides significantly higher ROI and test coverage. You’ll gain valuable coding and test automation skills while improving the QA test automation effort.
Teamwork makes the business dreams work. It takes time and some serious communication skills, but being able to build working relationships with developers as a QA tester is critical to career success. As a QA, you’ll need strong and flexible communication skills, a sense of diplomacy and the desire to actively work and learn. Getting what you need from developers can be a challenge, but it’s well worth the effort to enhance the product and your own career skills.
]]>Do you need a solid, quality codeless test automation tool for your development and QA teams? Prefer the simplicity of a cloud-based service? Create effective and efficient codeless test automation using Test Studio, and keep tests and teams productive.