Landing page optimization doesn’t happen overnight. That’s why marketers get frustrated — and often give up. If you want better landing pages, focus on collecting data. You should design your landing pages based on what you already know about your audience, but you’ll collect even more information as more people visit the page. Converting that data into informed decisions about your marketing funnel can produce more leads and sales. Today, I’m going to teach you my best landing page optimization tips and tricks so you can attract more prospects and convert more customers. If you’d like to skip around, here’s…
Landing page optimization doesn’t happen overnight. That’s why marketers get frustrated — and often give up. If you want better landing pages, focus on collecting data. You should design your landing pages based on what you already know about your audience, but don’t stop there — make sure you collect even more information as more people visit your website. Converting that data into informed decisions about your marketing funnel can produce more leads and sales. Today, I’m going to teach you my best landing page optimization tips and tricks so you can attract more prospects and convert more customers. If…
My email list is one of my most valuable assets. I have tons of email subscribers even though I regularly scrub my list, and I’ve converted many subscribers to paying clients. I started in the same place as everyone else, though: zero email subscribers. Whether your list includes 10 subscribers, 100 subscribers, or 1 million subscribers, you probably want more. That’s the nature of marketing. So, how can you increase conversions to build your email list further? That’s the question I’m going to answer today. I’ll cover several topics, so here’s a list in case you want to skip around:…
The average company used 16 SaaS apps in 2017. That’s a 33 percent increase from the year before. That doesn’t mean your SaaS business will flourish, though. If you want your piece of an industry that’s worth an estimated 116 billion globally, optimizing your SaaS conversion funnel most become a priority. Your conversion funnel describes the steps your prospective customers take to reach a buying decision. Narrowing the conversion funnel and pushing prospects through faster can result in higher profits. Do to so, you must learn how to nurture your leads and prospects. Let’s look at some of the most…
Fewer than 25 percent of businesses express satisfaction with their conversion rates. That’s pretty depressing. Conversion rate optimization (CRO) doesn’t improve your conversion rates overnight, but it sets you up for success. Part of CRO involves optimizing your calls to action for conversions. How is the best call to action for conversions? There’s no single call-to-action formula that can magically convince most of your leads to convert, but if you’re willing to get to know your audience, experience with different CTAs, and test variations, you’ll get closer to the conversion rates you want. We’ll be covering lots of information, so…
What if you could boost email signups by 1,375 percent (or more)? And what if I told you that the secret to those kinds of results lies in something as simple as an exit popup? Craft blogger Nikki McGonigal used to just have an email signup form in her website’s sidebar. Then she added an exit popup. Her conversion rate increased by more than 1,300 percent. Before you dismiss her results as industry related or as an aberration, you should know that businesses in just about every industry use exit popups. How do you get results from exit popups? I’m going…
Once Upon A Time: Using Story Structure For Better Engagement
Stories form the connective tissue of our lives. They’re our experiences, our memories, and our entertainment. They have rhythms and structures that keep us engaged. In this article, we’ll look at how those same rhythms and structures can help us enrich and enhance the user experience.
In his seminal work Hero With A Thousand Faces, Joseph Campbell identified a structure that rings true across a wide variety of stories. He called this “The Hero’s Journey,” but his book explaining it was 300+ pages so we’ll use a simplified version of Campbell’s work or a jazzified version of the plot structure you probably learned about in elementary school:
The ordinary world/exposition is where our hero/protagonist/person/thing/main character starts. It’s the every day, the safe, the boring, the life the hero already knows.
The inciting incident is the event or thing that pulls or (more often) pushes the hero into the story. It’s what gets them involved in the story whether they want to be or not.
In the rising action/preparation phase, the hero prepares (sometimes unknowingly) for the ordeal/climax which is when they go up against the villain (and prevail!).
After the hero prevails against the villain, they must return to their ordinary world and bring back the new knowledge and/or mythical object they got from/for defeating the villain.
Finally, in the Resolution, we tie up all the loose ends and throw a dance party.
We can apply this same structure to the experience of the user or — as I like to call it — the “user journey.”
Where the user starts (their every day).
They have a problem they need solved.
They’ve found your product/service/website and they think it might work to solve their problem, but they need to decide that this is the product/service/website will solve their problem. So in this step they gather facts and figures and feelings to determine if this thing will work. It could be deciding if the type of video game news covered on this site is the kind of news they want to consume or deciding whether this type of pen will solve their writing needs or whether the graphic design prowess of this agency can make their new website super awesome.
The fight to make a decision about purchasing that pen or adding that news site to your regularly checked sites or contacting that agency for a quote.
The Road Back
Decision made, the road back is about moving forward with that purchase, regular reading, or requesting the quote.
Where they apply your product/service/website to their problem and it is mightily solved.
If we consider this structure as we look at user interactions, there are lots of ways we can put ourselves in the user’s shoes and optimize their experience, providing support (and sometimes a good shove) exactly when they need it.
Here are some techniques. Some apply to just one part of the User Journey while some apply to several parts at once:
Journey With Your Users
Stories take time. Movies aren’t done in two minutes; they take two hours to watch and absorb. They are a journey.
If you always only ever shout “BUY! BUY! BUY!” you may make a few quick sales, but you won’t encourage long-term loyalty. Journey with your users, and they’ll count on you when they have a problem you can solve.
InVision’s newsletter journeys with you. In this recent newsletter, they sent an article about Questlove and what we can learn from him concerning creativity. If you click through, other than the URL, the word “InVision” does not appear on the page. They’re not pushing the sale, but providing relevant, interesting content to the main audience of people who use their products. I haven’t yet been in the market for their services, but if/when I am, there won’t be much of an Ordeal or fight for approval. They’ve proven their worth as a traveling companion. They’re someone I can count on.
Journeying with your users can take many forms, only one of which is content marketing. You could also build training programs that help them move from beginner to expert in using your app or site. You could add high touch parts to your sales process or specific technical support that will help you come alongside your user and their needs. In contexts of quick visits to a website you might use visuals or wording that’s down-to-earth, warm, welcoming, and feels personable to your main audience. You want to show the user they can count on you when they have a problem.
Give ‘Em A Shove
Users need an inciting incident to push them into the user journey, often more than one push. They have a lot going on in their lives. Maybe they’re working on a big project or are on vacation or their kid played frisbee with their laptop. They may have lost or never opened your first email. So don’t hesitate to send them a follow-up. Show them the difference between life without your product or service and life with it. Heroes are pushed into a story because their old life, their ordinary world, is no longer tenable given the knowledge or circumstances they now have.
Nick Stephenson helps authors sell more books (and uses the hero’s journey to think through his websites and marketing). Last fall he sent out a friendly reminder about a webinar he was doing. He gets straight to the point reminding us about his webinar, but provides value by giving us a way to ask questions and voice concerns. He also lets us know that this is a limited time offer, if we want the new life his webinar can bring we’ve got to step into the story before it’s too late.
Give your users more than one opportunity to buy your product. That doesn’t mean shove it down their throat every chance you get, but follow up and follow through will do wonders for your bottom line and help you continue to build trust. Many heroes need a push to get them into the story. Your users may need a shove or well-placed follow up email or blaring call to action too.
Give Out Magic Swords
By now you know your users will face an ordeal. So why not pass out magic swords, tools that will help them slay the ordeal easily?
Whenever I have tried to use Amazon’s Web Services, I’ve always been overwhelmed by the choices and the number of steps needed to get something to work. A one button solution it is not.
But on their homepage, they hand me a magic sword to help me slay my dragon of fear.
They use a 1-2-3 graphic to emphasize ease. With the gradient, they also subtly show the change from where you started (1) to where you’ll end (3) just like what a character does in a story. My discussion above could make this ring hollow, but I believe they do two things that prevent that.
First, number two offers lots of 10-minute tutorials for “multiple use cases” There seems to be meat there, not a fluffy tutorial that won’t apply to your situation. Ten minutes isn’t long, but can show something substantially and “multiple use cases” hints that one of these may well apply to your situation.
Second, number three is not “You’ll be done.” It’s “Start building with AWS.” You’ll be up and running in as easy as 1, 2, 3. At step 3 you’ll be ready to bring your awesome to their platform. The building is what I know and can pwn. Get me past the crazy setup and I’m good.
Find out what your user’s ordeal is. Is it that a competitor has a lower price? Or they’re scared of the time and expertise it’ll take to get your solution to work? Whatever it is, develop resources that will help them say Yes to you. If the price is a factor, provide information on the value they get or how you take care of all the work or show them it will cost them more, in the long run, to go with a different solution.
No One is Average
So many stories are about someone specific because we can identify with them. Ever sat through a movie with a bland, “everyman” character? Not if you could help it and definitely not a second time. If you sell to the average person, you’ll be selling to no one. No one believes themselves to be average.
Coke’s recent “Share a Coke” campaign used this brilliantly. First, they printed a wide variety of names on their products. This could have backfired.
My name isn’t Natasha, Sandy or Maurice. But it wasn’t “Buy a Coke,” it was “Share a Coke.” And I know a Natasha, a Sandy, and a Maurice. I could buy it for those friends for the novelty of it or buy my name if I found it ( “John” is so uncommon in the U.S. it’s hard to find anything that has my name on it besides unidentified men and commodes.)
So often we target an average user to broaden the appeal for a product/service/website, and to an extent, this is a good thing, but when we get overly broad, we risk interesting no one.
You Ain’t The Protagonist
You are not the protagonist of your website. You are a guide, a map, a directional sign. You are Obi-Wan Kenobi on Luke’s journey to understand the force. That’s because the story of your product is not your story, this isn’t the Clone Wars (I disavow Episodes I-III), it’s your user’s story, it’s A New Hope. Your users are the ones who should take the journey. First, they had a big hairy problem. They found your product or service that solved that big hairy problem. There was much rejoicing, but if you want them to buy you aren’t the hero that saves the day, you’re the teacher who enables them to save their day. (I am indebted to Donald Miller and his excellent “Story Brand” podcast for driving this point home for me.)
Zaxby’s focuses on how they’ll help you with messages like “Cure your craving” and “Bring some FLAVOR to your next Event!” The emphasis on “flavor” and “your” is borne out in the design and helps to communicate what they do and how they will help you solve your problem. But “you”, the user, is the hero, because you’re the one bringing it to the event. You will get the high fives from colleagues for bringing the flavor. Zaxby’s helps you get that victory.
Furthermore, we’re all self-centered, some more than others, and frankly, users don’t care about you unless it helps them. They only care about the awards you’ve won if it helps them get the best product or service they can. They are not independently happy for you.
At a recent marketers event I attended, the social media managers for a hospital said one of their most shared articles was a piece about the number of their doctors who were considered the top doctors in the region by an independent ranking. People rarely shared the hospital’s successes before, but they shared this article like crazy. I believe it’s because the user could say, “I’m so great at choosing doctors. I picked one of the best in the region!” Rather than “look at the hospital” users were saying “look at me!” Whenever you can make your success their success you’ll continue your success.
Celebrate Their Win
Similar to above, their success is your success. Celebrate their success and they’ll thank you for it.
Putting together any email campaign is arduous. There are a thousand things to do and it takes time and effort to get them right. Once I’ve completed that arduous journey, I never want to see another email again. But MailChimp turns that around. They have this tiny animation where their monkey mascot, Freddie, gives you the rock on sign. It’s short, delightful, and ignorable if you want to. And that little celebration animation energizes me to grab the giant email ball of horrors and run for the end zone yet again. Exactly what Mailchimp wants me to do.
So celebrate your user’s victories as if they were your own. When they succeed at using your product or get through your tutorial or you deliver their website, throw a dance party and make them feel awesome.
The Purchase Is Not The Finish Line
The end of one story is often the beginning of another. If we get the client to buy and then drop off the face of the Earth that client won’t be back. I’ve seen this with a lot of web agencies that excel in the sales game, but when the real work of building the website happens, they pass you off to an unresponsive project manager.
Squarespace handles this transition well with a “We got you” email. You click purchase, and they send you an email detailing their 24/7 support and fast response times. You also get the smiling faces of five people who may or may not, have or still work there. And it doesn’t matter if they work there or never did. This email tells the user “We’ve got you, we understand, and we will make sure you succeed.”
This harkens all the way back to journeying with your user. Would you want to travel with the guy who leaves as soon as you got him past the hard part? No, stick with your users and they’ll stick with you.
We are storytelling animals. Story structure resonates with the rhythms of our lives. It provides a framework for looking at user experience and can help you understand their point of view at different points in the process. It also helps you tweak it such that it’s a satisfying experience for you and your users.
You got to the end of this article. Allow me to celebrate your success with a dance party.
Generating good lead magnet ideas can become a long process. Simply throwing together an e-book or whitepaper just because other businesses do it would be a mistake. High-converting lead magnet ideas offer so much value that your target audience can’t say no. The more you refine your lead magnet, the more qualified your leads become because you’re offering exactly what those leads need at the exact right time. Lead magnets can work for nearly all audiences, including those of B2B and B2C businesses. They’re powerful because they open the door to further communication between the business and the lead. But…
FAST UX Research: An Easier Way To Engage Stakeholders And Speed Up The Research Process
Today, UX research has earned wide recognition as an essential part of product and service design. However, UX professionals still seem to be facing two big problems when it comes to UX research: A lack of engagement from the team and stakeholders as well as the pressure to constantly reduce the time for research.
In this article, I’ll take a closer look at each of these challenges and propose a new approach known as ‘FAST UX’ in order to solve them. This is a simple but powerful tool that you can use to speed up UX research and turn stakeholders into active champions of the process.
Contrary to what you might think, speeding up the research process (in both the short and long term) requires effective collaboration, rather than you going away and soldiering on by yourself.
The acronym FAST (Focus, Attend, Summarise, Translate) wraps up a number of techniques and ideas that make the UX process more transparent, fun, and collaborative. I also describe a 5-day project with a central UK government department that shows you how the model can be put into practice.
The article is relevant for UX professionals and the people who work with them, including product owners, engineers, business analysts, scrum masters, marketing and sales professionals.
1. Lack Of Engagement Of The Team And Stakeholders
“Stakeholders have the capacity for being your worst nightmare and your best collaborator.”
Anyone who has tried to do this knows that it can be extremely difficult to organize and get stakeholders to participate in research. There are two main reasons for this:
Research is somebody else’s job. In my experience, UX professionals are often hired to “do the UX” for a company or organization. Even though the title of “Lead UX Researcher” sounds great and very important in my head, it often leads to misconceptions during kick-off meetings. Everyone automatically assumes that research is solely MY responsibility. It’s no wonder that stakeholders don’t want to get involved in the project. They assume research is my and nobody else’s job.
UX process frameworks are incomplete. The problem is that even when stakeholders want to engage and participate in UX, they still do not know *how* they should get involved and *what* they should do. We spend a lot of time selling a UX process and research frameworks that are useful but ultimately incomplete — they do not explain how non-researchers can get involved in the research process.
Further, a lot of stakeholders can find words such as ‘design,’ ‘analysis’ or ‘fieldwork’ intimidating or irrelevant to what they do. In fact, “UX is rife with jargon that can be off-putting to people from other fields.” In some situations, terms are familiar but mean something completely different, e.g., research in UX versus marketing research.
2. Pressure To Constantly Reduce The Time For Research
Another issue is that there is a constantly growing pressure to speed up the UX process and reduce the time spent on research. I cannot count the number of times when a project manager asked me to shorten a study even further by skipping the analysis stage or the kick-off sessions.
While previously you could spend weeks on research, a 5-day research cycle is increasingly becoming the norm. In fact, the book Sprint describes how research can dwindle to just a day (from an overall 5-day cycle).
Considering this, there is a LOT of pressure on UX researchers to deliver fast, without compromising the quality of the study. The difficulty increases when there are multiple stakeholders, each with their own opinions, demands, views, assumptions, and priorities.
The Fast UX Approach
Contrary to what you might think, reducing the time it takes to do UX research does not mean that you need to soldier on by yourself. I have done this and it only works in the short term. It does not matter how amazing the findings are — there is not enough PowerPoint slides in the world to convince a team of the urgency to take action if they have not been on the research journey themselves.
In the long term, the more actively engaged your team and stakeholders are in the research, the more empowered they will feel and the more willing they will be to take action. Productive collaboration also means that you can move together at a quicker pace and speed up the whole research process.
The FAST UX Research framework (see Fig. 2 below) is a tool to truly engage team members and stakeholders in a way that turns them into active advocates and champions of the research process. It shows non-researchers when and how they should get involved in UX Research.
In essence, stakeholders take ownership of each of the UX research stages by carrying out the four activities, each corresponding to its research stage.
Working together reduces the time it takes for UX Research. The true benefit of the approach, however, is that, in the long term, it takes less and less time for the business to take action based on research findings as people become true advocates of user-centricity and the research process.
This approach can be applied to any qualitative research method and with any team. For example, you can carry out FAST usability testing, FAST interviews, FAST ethnography, and so on. In order to be effective, you will need to explain this approach to your stakeholders from the start. Talk them through the framework, explaining each stage. Emphasize that this is what EVERYONE does, that it’s their work as much as the UX researcher’s job, and that it’s only successful if everyone is involved throughout the process.
Stage 1: Focus (Define A Common Goal)
There is a uniform consensus within UX that a research project should start by defining its purpose: why is this research done and how will the results be acted upon?
Generally, this is expressed within the research goals, objectives, research questions and/or hypotheses. Most projects start with a kick-off meeting where those are either discussed (based on an available brief) or are defined during the meeting.
The most regular problem with kick-off sessions like these is that stakeholders come up with too many things they want to learn from a study. The way to turn the situation around is to assign a specific task to your immediate team (other UX professionals you work with) and stakeholders (key decision makers): they will help focus the study from the beginning.
The way they will do that is by working together through the following steps:
Identify as a group the current challenges and problems.
Ask someone to take notes on a shared document; alternatively, ask everyone to participate and write on sticky notes which are then displayed on a “project wall” for everyone to see.
Identify the potential objectives and questions for a research study.
Do this the same way you did the previous step. You don’t need to commit to anything yet.
Ask the team to order the objectives and questions, starting with the most important ones.
Reword and rephrase.
Look at the top 3 questions and objectives. Are they too broad or narrow? Could they be reworded so it’s clearer what is the focus of the study? Are they feasible? Do you need to split or merge objectives and questions?
Commit to be flexible.
Agree on the top 1-2 objectives and ensure that you have agreement from everyone that this is what you will focus on.
Here are some questions you can ask to help your stakeholders and team to get to the focus of the study faster:
From the objectives we have recognized, what is most important?
What does success look like?
If we only learn one thing, which one would be the most important one?
Your role during the process is to provide expertise to determine if:
The identified objectives and questions are feasible for a single study;
Help with the wording of objectives and questions;
Design the study (including selecting a methodology) after the focus has been identified.
At first sight, the Focus and Attend (next stages) activities might be familiar as you are already carrying out a kick-off meeting and inviting stakeholders to attend research sessions.
However, adopting a FAST approach means that your stakeholders have as much ownership as you do during the research process because work is shared and co-owned. Reiterate that the process is collaborative and at the end of the session, emphasize that agreeing on clear research objectives is not easy. Remind everybody that having a shared focus is already better than what many teams start with.
Finally, remind the team and your stakeholders what they need to do during the rest of the process.
Stage 2: Attend (Immerse The Team Deeply In The Research Process)
What often happens is that observers join in on the day of the research study and then they spend the time plastered to their laptops and mobile phones. What is worse, some stakeholders often talk to the note-taker and distract the rest of the design team who need to observe the sessions.
This is why it is just as important that you get the team to interact with the research. The following activities allow the team to immerse themselves in the research session. You can ask stakeholders to:
Ask questions during the session through a dedicated live chat (e.g. Slack, Google Hangouts, Skype);
Take notes on sticky notes;
Summarize observations for everyone (see next stage).
Assign one person per session for each of these activities. Have one “live chat manager,” one “note-taker,” and one “observer” who will sum up the session afterwards.
Rotate people for the next session.
Before the session, it’s useful to walk observers through the ‘ground rules’ very briefly. You can have a poster similar to the one GDS developed that will help you do this and remind the team of their role during the study (see Fig. 3 above).
Farrell (2017) provides more detail on effective ways for stakeholders to take notes together. When you have multiple stakeholders and it’s not feasible for them to physically attend a field visit (e.g. on the street, in an office, at the home of the participant), you could stream the session to an observation room.
Stage 3: Summarize (Analysis For Non-Researchers)
I am a strong supporter of the idea that analysis starts the moment fieldwork begins. During the very first research session, you start looking for patterns and interpretation of what the data you have means.
Even after the first session (but typically towards the end of fieldwork) you can carry out collaborative analysis: a fun and productive way that ensures that you have everyone participating in one of the most important stages of research.
The collaborative analysis session is an activity where you provide an opportunity for everyone to be heard and create a shared understanding of the research.
Since you’re including other experts’ perspectives, you’re increasing the chances to identify more objective and relevant insights, and also for stakeholders to act upon the results of the study.
Even though ‘analysis’ is an essential part of any research project, a lot of stakeholders get scared by the word. The activity sounds very academic and complex. This is why at the end of each research session, research day, or the study as a whole, the role of your stakeholders and immediate team is to summarize their observations. Summarizing may sound superfluous but is an important part of the analysis stage; this is essentially what we do during “Downloading” sessions.
Listening to someone’s summary provides you with an opportunity to understand:
What they paid attention to;
What is important for them;
Their interpretation of the event.
Summary At The End Of Each Session
You do this by reminding everyone at the beginning of the session that at the end you will enter the room and ask them to summarize their observations and recommendations.
You then end the session by asking each stakeholder the following:
What were their key observations (see also Fig. 3)?
What happened during the session?
Were there any major difficulties for the participant?
What were the things that worked well?
Was there anything that surprised them?
This will make the team more attentive during the session, as they know that they will need to sum it up at the end. It will also help them to internalize the observations (and later, transition more easily to findings).
This is also the time to consistently share with your team what you think stands out from the study so far. Avoid the temptation to do a ‘big reveal’ at the end. It’s better if outcomes are told to stakeholders many times.
On multiple occasions, research has given me great outcomes. Instead of sharing them regularly, I keep them to myself until the final report. It doesn’t work well. A big reveal at the end leads to bewildered stakeholders who often cannot jump from observations to insights as quickly. As a result, there is either stubborn pushback or indifferent shrugs.
Summary At The End Of The Day
A summary of the event or the day can then naturally transition into a collaborative analysis session. Your job is to moderate the session.
The job of your stakeholders is to summarize the events of the day and the final results. Ask a volunteer to talk the group through what happened during the day. Other stakeholders can then add to these observations.
Summary At The End Of The Study
After the analysis is done, ask one or two stakeholders to summarize the study. Make sure they cover why we did research, what happened during the study and what are the primary findings. They can also do this by walking through the project wall (if you have one).
It’s very difficult not to talk about your research and leave someone else to do it. But it’s worth it. No matter how much you’re itching to do this yourself — don’t! It’s a great opportunity for people to internalize research and become comfortable with the process. This is one of the key moments to turn stakeholders into active advocates of user research.
At the end of this stage, you should have 5-7 findings that capture the study.
Stage 4: Translate (Make Stakeholders Active Champions Of The Solution)
“Research doesn’t have a value unless it results in decisions and actions.”
—Lang and Howell (2017).
Even when you agree with the findings, stakeholders might still disagree about what the research means or lack commitment to take further action. This is why after summarizing, ask your stakeholders to work with you and identify the “Now what?” or what it all means for the organization, product, service, team and/or individually for each one of them.
Traditionally, it was the UX researchers’ job to write clear, precise, descriptive findings, and actionable recommendations. However, if the team and stakeholders are not part of identifying actionable recommendations, they might be resistant towards change in future.
To prevent later pushback, ask stakeholders to identify the “Now what?” (also referred to as ‘actionable recommendations’). Together, you’ll be able to identify how the insights and findings will:
Affect the business and what needs to be done now;
Affect the product/service and what changes do we need to make;
Affect people individually and the actions they need to take;
Lead to potential problems and challenges and their solutions;
Help solve problems or identify potential solutions.
Stakeholders and the team can translate the findings at the end of a collaborative analysis session.
If you decide to separate the activities and conduct a meeting in which the only focus is on actionable recommendations, then consider the following format:
Briefly talk through the 5-7 main findings from the study (as a refresher if this stage is done separately from the analysis session or with other stakeholders).
Split the group into teams and ask them to work on one finding/problem at a time.
Ask them to list as many ways they see the finding affecting them.
Ask one person from each group to present the findings back to the team.
Ask one/two final stakeholders to summarize the whole study, together with the methods, findings, and recommendations.
Later, you can have multiple similar workshops; this is how you get to engage different departments from the organization.
Fast UX In Practice
An excellent example of a FAST UX Research approach in practice is a project I was hired to carry out for a central UK government department. The ultimate goal of the project was to identify user requirements for a very complex internal system.
At first sight, this was a very challenging project because:
There was no time to get to know the department or the client.
Usually, I would have at least a week or two to get to know the client, their needs, opinions, internal pressures, and challenges. For this project, I had to start work on Monday with a team I had never met; in a building I had never worked, in a domain I knew little about, and finish on Friday the same week.
The system was very complex and required intense research.
The internal system and the nature of work were very complex; this required gathering data with at least a few research methods (for triangulation).
This was the first time the team had worked with a UX Researcher.
The stakeholders were primarily IT specialists. However, I was lucky that they were very keen and enthusiastic to be involved in the project and get their hands dirty.
As is the case on many other projects, all stakeholders were extremely busy as they had their own work on top of the project. Nonetheless, we made it work, even if it meant meeting over lunch, or for a 15-minute wrap up before we went home.
There were internal pressures and challenges.
As with any department and huge organization, there were a number of internal pressures and challenges. Some of them I expected (e.g. legacy systems, slow pace of change) but some I had no clue about when I started.
We had to coordinate work with external teams.
An additional challenge was the need to work with and coordinate efforts with external teams at another UK department.
Despite all of these challenges, this was one of the most enjoyable projects I have worked on because of the tight collaboration initiated by the FAST approach.
The project consisted of:
1 day of kick-off sessions and getting to know the team
2,5 days of contextual inquiries and shadowing of internal team members,
Half a day for a co-creation workshop, and
1 day for analysis and results reporting.
In the process, I gathered data from 20+ employees, had 16+ hours of observations, 300+ photos and about 100 pages of notes. Here is a great example of cramming in 3 weeks’ worth of work into a mere 5-day research cycle. More importantly, people in the department were really excited about the process.
Here is how we did it using a FAST UX Research approach:
Focus At the beginning of the project, the two key stakeholders identified what the focus of research would be while my role was mainly to help with prioritizing the objectives, tweak the research questions and check for feasibility. In this sense, I listened and mainly asked questions, interjecting occasionally with examples from previous projects or options that helped to adjust our approach.
While I wrote the main discussion guide for the contextual inquiries and shadowing sessions, we sat together with the primary team to discuss and design the co-creation workshop with internal users of the system.
Attend During the workshop one of the stakeholders moderated half of the session, while the other took notes and observed closely the participants. It was a huge success internally, as stakeholders felt there was better visibility for their efforts to modernize the department, while employees felt listened to and involved in the research.
Summarize Immediately after the workshop, we sat together with the stakeholders for a 30-minute meeting where I had them summarize their observations.
As a result of the shadowing, contextual inquiries and co-creation workshop, we were able to identify 60+ issues and problems with the internal system (with regards to integration, functionality, and usability), all captured in six high-level findings.
Translate Later, we discussed with the team how each of the six major findings translated to a change or implication for the department, the internal system, as well as collaboration with other departments.
We were so perfectly aligned with the team that when we had to talk about our work in front of another UK government department, I could let the stakeholders talk about the process and our progress.
My final task (over two additional days) was to document all of the findings in a research report. This was necessary as a knowledge repository because I had to move onto other projects.
With a more traditional approach, the project could have easily spanned 3 weeks. More importantly, quickly understanding individual and team pressures and challenges were the keys to the success of the new system. This could not have happened within the allocated time without a collaborative approach.
A FAST UX approach resulted in tight collaboration, strong co-ownership and a shared sense of progress; all of those allowed to shorten the time of the project, but also to instill a feeling of excitement about the UX research process.
Have You Tried It Out Already?
While UX research becomes ever more popular, gone are the days when we could soldier on by ourselves and only consult stakeholders at the end.
Mastering our craft as UX researchers means engaging others within the process and being articulate, clear, and transparent about our work. The FAST approach is a simple model that shows how to engage non-researchers with the research process. Reducing the time it takes to do research, both in the short (i.e. the study itself) and long term (i.e. using the research results), is a strategic advantage for the researcher, team, and the business as a whole.
Would you like to improve your efficiency and turn stakeholders into user research advocates? Go and try it out. You can then share your stories and advice here.
I would love to hear your comments, suggestion and any feedback you care to share! If you have tried it out already, do you have success stories you want to share? Be as open as you can — what worked well, and what didn’t? As with all other things UX, it’s most fun if we learn together as a team.
Working Together: How Designers And Developers Can Communicate To Create Better Projects
Among the most popular suggestions on Smashing Magazine’s Content User Suggestions board is the need of learning more about the interaction and communication between designers and developers. There are probably several articles worth of very specific things that could be covered here, but I thought I would kick things off with a general post rounding up some experiences on the subject.
Given the wide range of skills held by the line-up at our upcoming SmashingConf Toronto — a fully live, no-slides-allowed event, I decided to solicit some feedback. I’ve wrapped those up with my own experience of 20 years working alongside designers and other developers. I hope you will add your own experiences in the comments.
Some tips work best when you can be in the same room as your team, and others are helpful for the remote worker or freelancer. What shines through all of the advice, however, is the need to respect each other, and the fact that everyone is working to try and create the best outcome for the project.
Working Remotely And Staying Connected
The nomadic lifestyle is not right for everyone, but the only way to know for sure is to try. If you can afford to take the risk, go for it. Javier Cuello shares his experience and insights from his four years of travel and work. Read article →
For many years, my own web development company operated as an outsourced web development provider for design agencies. This involved doing everything from front-end development to implementing e-commerce and custom content management solutions. Our direct client was the designer or design agency who had brought us on board to help with the development aspect of the work, however, in an ideal situation, we would be part of the team working to deliver a great end result to the end client.
Sometimes this relationship worked well. We would feel a valued part of the team, our ideas and experience would count, we would work with the designers to come up with the best solution within budgetary, time, and other constraints.
In many cases, however, no attempt was made to form a team. The design agency would throw a picture of a website as a PDF file over the fence to us, then move on to work on their next project. There was little room for collaboration, and often the designer who had created the files was busy on some other work when we came back with questions.
It was an unsatisfactory way to work for everyone. We would be frustrated because we did not have a chance to help ensure that what was designed was possible to be built in a performant and accessible way, within the time and budget agreed on. The designer of the project would be frustrated: Why were these developers asking so many questions? Can they not just build the website as I have designed? Why are the fonts not the size I wanted?
The Waterfall versus Agile argument might be raised here. The situation where a PDF is thrown over the fence is often cited as an example of how bad a Waterfall approach is. Still, working in a fully Agile way is often not possible for teams made of freelancers or separate parties doing different parts of the work. Therefore, in reading these suggestions, look at them through the lens of the projects you work on. However, try not to completely discount something as unworkable because you can’t use the full process. There are often things we can take without needing to fully adopt one methodology or another.
Setting Up A Project For Success
I came to realize that very often the success of failure of the collaboration started before we even won the project, with the way in which we proposed the working relationship. We had to explain upfront that experience had taught us that the approach of us being handed a PDF, quoting and returning a website did not give the best results.
Projects that were successful had a far more iterative approach. It might not be possible to have us work alongside the designers or in a more Agile way. However, having a number of rounds of design and development with time for feedback from each side went a long way to prevent the frustrations of a method where work was completed by each side independently.
Creating Working Relationships
Having longer-term relationships with an agency, spanning a number of projects worked well. We got to know the designers, learned how they worked, could anticipate their questions and ensure that we answered them upfront. We were able to share development knowledge, the things that made a design easier or harder to implement which would, therefore, have an impact on time and budget. They were able to communicate better with us in order to explain why a certain design element was vital, even if it was going to add complexity.
For many freelance designers and developers, and also for those people who work for a distributed company, communication can become mostly text-based. This can make it particularly hard to build relationships. There might be a lot of communication — by email, in Slack, or through messages on a project management platform such as Basecamp. However, all of these methods leave us without the visual cues we might pick up from in-person meetings. An email we see as to the point may come across to the reader as if we are angry. The quick-fire nature of tools such as Slack might leave us committing in writing something which we would not say to that person while looking into their eyes!
Freelance data scientist Nadieh Bremer will talk to us about visualizing data in Toronto. She has learned that meeting people face to face — or at least having a video call — is important. She told me:
“As a remote freelancer, I know that to interact well with my clients I really need to have a video call (stress on the video) I need to see their face and facial/body interactions and they need to see mine. For clients that I have within public transport distance, I used to travel there for a first ‘getting to know each other/see if we can do a project’ meeting, which would take loads of time. But I noticed for my clients abroad (that I can’t visit anyway) that a first client call (again, make sure it’s a video-call) works more than good enough.
It’s the perfect way to weed out the clients that need other skills that I can give, those that are looking for a cheap deal, and those where I just felt something wasn’t quite clicking or I’m not enthusiastic about the project after they’ve given me a better explanation. So these days I also ask my clients in the Netherlands, where I live, that might want to do a first meeting to have it online (and once we get on to an actual contract I can come by if it’s beneficial).”
Working In The Open
Working in the open (with the project frequently deployed to a staging server that everyone had access to see), helped to support an iterative approach to development. I found that it was important to support that live version with explanations and notes of what to look at and test and what was still half finished. If I just invited people to look at it without that information we would get lists of fixes to make to unfinished features, which is a waste of time for the person doing the reporting. However, a live staging version, plus notes in a collaboration tool such as Basecamp meant that we could deploy sections and post asking for feedback on specific things. This helped to keep everyone up to date and part of the project even if — as was often the case for designers in an agency — they had a number of other projects to work on.
There are collaboration tools to help designers to share their work too. Asking for recommendations on Twitter gave me suggestions for Zeplin, Invision, Figma, and Adobe XD. Showing work in progress to a developer can help them to catch things that might be tricky before they are signed off by the client. By sharing the goal behind a particular design feature within the team, a way forward can be devised that meets the goal without blowing the budget.
Scope Creep And Change Requests
The thing about working in the open is that people then start to have ideas (which should be a positive thing), however, most timescales and budgets are not infinite! This means you need to learn to deal with scope creep and change requests in a way that maintains a good working relationship.
We would often get requests for things that were trivial to implement with a message saying how sorry they were about this huge change and requests for incredibly time-consuming things with an assumption it would be quick. Someone who is not a specialist has no idea how long anything will take. Why should they? It is important to remember this rather than getting frustrated about the big changes that are being asked for. Have a conversation about the change, explain why it is more complex than it might appear, and try to work out whether this is a vital addition or change, or just a nice idea that someone has had.
If the change is not essential, then it may be enough to log it somewhere as a phase two request, demonstrating that it has been heard and won’t be forgotten. If the big change is still being requested, we would outline the time it would take and give options. This might mean dropping some other feature if a project has a fixed budget and tight deadline. If there was flexibility then we could outline the implications on both costs and end date.
With regard to costs and timescales, we learned early on to pad our project quotes in order that we could absorb some small changes without needing to increase costs or delay completion. This helped with the relationship between the agency and ourselves as they didn’t feel as if they were being constantly nickel and dimed. Small changes were expected as part of the process of development. I also never wrote these up in a quote as contingency, as a client would read that and think they should be able to get the project done without dipping into the contingency. I just added the time to the quote for the overall project. If the project ran smoothly and we didn’t need that time and money, then the client got a smaller bill. No one is ever unhappy about being invoiced for less than they expected!
This approach can work even for people working in-house. Adding some time to your estimates means that you can absorb small changes without needing to extend the timescales. It helps working relationships if you are someone who is able to say yes as often as possible.
This does require that you become adept at estimating timescales. This is a skill you can develop by logging your time to achieve your work, even if you don’t need to log your time for work purposes. While many of the things you design or develop will be unique, and seem impossible to estimate, by consistently logging your time you will generally find that your ballpark estimates become more accurate as you make yourself aware of how long things really take.
“It all comes down to respect for your colleague’s craft, and sort of knowing your place and precisely where you fit into the project. When working with a developer, I surrender to them in a creative way, and then, defuse whatever power play they might try to make on me by leading the charges with constructive design advice, lightning-fast email replies and generally keeping the spirit upbeat. It’s an odd offense to play. I’m not down with the adversarial stuff. I’m quick to remind them we are all in the same boat, and, who’s paying their paycheck. And that’s not me. It’s the client. I’ll forever be on their team, you know? We make the stuff for the client. Not just me. Not ‘my team’. We do it together. This simple methodology has always gone a long way for me.”
I love this, it underpins everything that this article discusses. Think back to any working relationship that has gone bad, how many of those involved you feeling as if the other person just didn’t understand your point of view or the things you believe are important? Most reasonable people understand that compromise has to be made, it is when it appears that your point of view is not considered that frustration sets in.
There are sometimes situations where a decision is being made, and your experience tells you it is going to result in a bad outcome for the project, yet you are overruled. On a few occasions, decisions were made that I believed so poor; I asked for the decision and our objection to it be put in writing, in order that we could not be held accountable for any bad outcome in future. This is not something you should feel the need to do often, however, it is quite powerful and sometimes results in the decision being reversed. An example would be of a client who keeps insisting on doing something that would cause an accessibility problem for a section of their potential audience. If explaining the issue does not help, and the client insists on continuing, ask for that decision in writing in order to document your professional advice.
Learning The Language
I recently had the chance to bring my CSS Layout Workshop not to my usual groups of front-end developers but instead to a group of UX designers. Many of the attendees were there not to improve their front-end development skills, but more to understand enough of how modern CSS Layout worked that they could have better conversations with the developers who built their designs. Many of them had also spent years being told that certain things were not possible on the web, but were realizing that the possibilities in CSS were changing through things like CSS Grid. They were learning some CSS not necessarily to become proficient in shipping it to production, but so they could share a common language with developers.
There are often debates on whether “designers should learn to code.” In reality, I think we all need to learn something of the language, skills, and priorities of the other people on our teams. As Aaron reminded us, we are all on the same team, we are making stuff together. Designers should learn something about code just as developers should also learn something of design. This gives us more of a shared language and understanding.
“I have basically made a career out of being both technical and creative so I strongly feel that the more crossover the better. Obviously what I do now is wonderfully free of the constraints of client work but even so, I do think that if you can blur those edges, it’s gonna be good for you. It’s why I speak at design conferences and encourage designers to play with creative coding, and I speak at tech conferences to persuade coders to improve their visual acuity. Also with creative coding. It’s good because not only do I get to work across both disciplines, but also I get to annoy both designers and coders in equal measure.”
I have found that introducing designers to browser DevTools (in particular the layout tools in Firefox and also to various code generators on the web) has been helpful. By being able to test ideas out without writing code, helps a designer who isn’t confident in writing code to have better conversations with their developer colleagues. Playing with tools such as gradient generators, clip-path or animation tools can also help designers see what is possible on the web today.
We are also seeing a number of tools that can help people create websites in a more visual way. Developers can sometimes turn their noses up about the code output of such tools, and it’s true they probably won’t be the best choice for the production code of a large project. However, they can be an excellent way for everyone to prototype ideas, without needing to write code. Those prototypes can then be turned into robust, permanent and scalable versions for production.
An important tip for developers is to refrain from commenting on the code quality of prototypes from members of the team who do not ship production code! Stick to what the prototype is showing as opposed to how it has been built.
A Practical Suggestion To Make Things Visual
Eva-Lotta Lamm will be speaking in Toronto about Sketching and perhaps unsurprisingly passed on practical tips for helping conversation by visualizing the problem to support a conversation.
Creating a shared picture of a problem or a solution is a simple but powerful tool to create understanding and make sure they everybody is talking about the same thing.
Visualizing a problem can reach from quick sketches on a whiteboard to more complex diagrams, like customer journey diagrams or service blueprints.
But even just spatially distributing words on a surface adds a valuable layer of meaning. Something as simple as arranging post-its on a whiteboard in different ways can help us to see relationships, notice patterns, find gaps and spot outliers or anomalies. If we add simple structural elements (like arrows, connectors, frames, and dividers) and some sketches into the mix, the relationships become even more obvious.
Visualising a problem creates context and builds a structural frame that future information, questions, and ideas can be added to in a ‘systematic’ way.
Visuals are great to support a conversation, especially when the conversation is ‘messy’ and several people involved.
When we visualize a conversation, we create an external memory of the content, that is visible to everybody and that can easily be referred back to. We don’t have to hold everything in our mind. This frees up space in everybody’s mind to think and talk about other things without the fear of forgetting something important. Visuals also give us something concrete to hold on to and to follow along while listening to complex or abstract information.
When we have a visual map, we can point to particular pieces of content — a simple but powerful way to make sure everybody is talking about the same thing. And when referring back to something discussed earlier, the map automatically reminds us of the context and the connections to surrounding topics.
When we sketch out a problem, a solution or an idea the way we see it (literally) changes. Every time we express a thought in a different medium, we are forced to shape it in a specific way, which allows us to observe and analyze it from different angles.
Visualising forces us to make decisions about a problem that words alone don’t. We have to decide where to place each element, decide on its shape, size, its boldness, and color. We have to decide what we sketch and what we write. All these decisions require a deeper understanding of the problem and make important questions surface fairly quickly.
All in all, supporting your collaboration by making it more visual works like a catalyst for faster and better understanding.
Working in this way is obviously easier if your team is working in the same room. For distributed teams and freelancers, there are alternatives to communicate in ways other than words, e.g. by making a quick Screencast to demonstrate an issue, or even sketching and photographing a diagram can be incredibly helpful. There are collaborative tools such as Milanote, Mural, and Niice; such tools can help with the process Eva-Lotta described even if people can’t be in the same room.
I’m very non-visual and have had to learn how useful these other methods of communication are to the people I work with. I have been guilty on many occasions of forgetting that just because I don’t personally find something useful, it is still helpful to other people. It is certainly a good idea to change how you are trying to communicate an idea if it becomes obvious that you are talking at cross-purposes.
Over To You
As with most things, there are many ways to work together. Even for remote teams, there is a range of tools which can help break down barriers to collaborating in a more visual way. However, no tool is able to fix problems caused by a lack of respect for the work of the rest of the team. A good relationship starts with the ability for all of us to take a step back from our strongly held opinions, listen to our colleagues, and learn to compromise. We can then choose tools and workflows which help to support that understanding that we are all on the same team, all trying to do a great job, and all have important viewpoints and experience to bring to the project.
I would love to hear your own experiences working together in the same room or remotely. What has worked well — or not worked at all! Tools, techniques, and lessons learned are all welcome in the comments. If you would be keen to see tutorials about specific tools or workflows mentioned here, perhaps add a suggestion to our User Suggestions board, too.