How Elon Musk’s 5-Step Process Applies To Software Development

In a fantastic, super geeked-out interview (courtesy of the Everyday Astronaut), Elon Musk breaks down the 5-Step Process he’s implemented to develop everything from Tesla electric cars to Space X rockets. One of the great things about Elon’s explanation of each step is that he speaks in a very blunt manner and uses examples of the mistakes he and his teams have made that drove him to implement these steps. As he explains each step, it occurred to us how these exact same steps can and should be applied to developing software products.

STEP 1. Make Your Requirements Less Dumb

In this clip, Musk says “The requirements you were given are definitely dumb — and it’s particularly dangerous if a smart person gave you the requirements because you might not question them.” Basically, he encourages everyone to assume that there are things wrong with the requirements they’ve received so that they feel much more free to ask questions and make them better (or, less dumb).

In addition, Musk requires all requirements to come with a person’s name attached to them – not just a department name. This way, a person takes responsibility for the requirement and everyone knows who to go to with questions.

How this relates to software development

Here are a few real-world examples of scenarios that we run into a lot with our clients during our Team Work Sessions:

  • UX Team asks “Why is this a requirement?” The client says “That’s what the business team wants.”
    The fact that product teams often do not question or challenge why a requirement is a requirement in the first place probably speaks more to a problem with the corporate culture dynamic than anything else. In other words, often times product teams are put in a position of focusing purely on delivering what they are asked to deliver — without being empowered to ask “why?”.
  • UX Team asks “Why does your current software product function this way?” The client says “That’s just how it’s always functioned.”
    This one actually happens quite a lot and it’s often the result of a product team that:

    • Can no longer “see the forest for the trees” because they’ve been so close to the product for so long
    • Has new members that don’t feel comfortable questioning things until they’ve earned their stripes.
  • UX Team asks “What drove this to become a requirement in the first place?” The clients says “Feedback from our users”. Then UX Team asks “How many users and what was their specific feedback?” The client says either “I don’t know. It’s just what we were told.” or “We had one or two users complain.”
    This also happens quite a lot and it often causes product teams to get sidetracked with enhancements or new requirements that should have a much lower priority than others in their backlog. It’s sort of like the “The squeaky wheel gets the grease” treatment.

Ideally, if product teams followed Elon’s “Step 1” advice, they would attach a name to every requirement and create a culture whereby everyone felt not only empowered but expected to ask questions about the requirements they were given before they spend tons of time designing and developing them.


STEP 2. Try Very Hard To Delete A Part Or Process

In this clip, Musk says “The bias tends to be “let’s add this part or process ‘in case’ we need it” – but you can make ‘in case’ arguments for almost everything.”

How this relates to software development

In art school, they teach “When everything is important, nothing is important”. In UX design, when you make the visual weight of too many things on a given screen the same, you create a visual hierarchy that does not inform the user about what is important vs less important. Therefore, whenever you add something you need to always consider whether it is worth degrading the visual weight of other existing things or if you should remove existing things to make room for the new thing.

This also holds true for adding functions and features to a software product. As Musk explains, the tendency is for product teams to add more and more features to their product when they should be equally considering what they can remove. After all, if the end goal is to make a better product but the bells and whistles you want to add make your product more difficult to use, are they really worth adding?

As this relates to a “Process“, a few years ago we were hired to redesign an existing product but the first priority was to get the live product working. Soon after we engaged with our client, we fixed the existing code and were ready to deploy it – but we couldn’t because the client’s development team was still working out the details of their new Continuous Integration (CI) scheme and how our team was going to get integrated with it. We suggested that, for this particular release, we simply push the updated code files to production manually without CI in place. Then, we will shift our focus to the redesign effort while the client development team takes their time to implement a proper CI scheme for us to use. Processes can be good but when teams get so programmed to follow them, it can prevent teams from considering simple, logical solutions.


3. Simplify or Optimize

In this clip, Musk talks about how he purposely makes this his third step so that it helps prevent teams from “optimizing a thing that shouldn’t exist”. In other words, it’s great that you were able to optimize the performance of that new feature – but did you consider whether it was needed in the first place?

How this relates to software development

This one speaks directly to the creation of a good user experience. When we design a software product, we test the usability of our designs before it is developed. When we deploy the tested and refined design into production, we then monitor how it is being used and even A/B test different designs to further optimize it. Sometimes our tests reveal what we call a “design thorn”, which is an element in our design that we are struggling to optimize but it continues to cause problems for the users. In many cases, the best way to handle a design thorn is to simply remove it.

This also applies to application and infrastructure optimizations, which can speed the performance of a product and help keep it more stable. A product that performs quickly, is error free, and is always available is one that is far more likely to create a great user experience.


4. Accelerate Cycle Time — or, “Go faster!”

In this clip, Musk says “Go faster — but don’t go faster until you’ve worked on the other 3 (steps) first.”

How this relates to software development

In Agile Development, “Velocity” is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint. So to increase Velocity, it would help if you made your requirements “less dumb”, deleted features or processes, and simplified or optimized your product. Once you’ve done these, you can be in a much better position to “Go faster!


5. Automate

In this clip, Musk talks about the importance of never starting with automation first and going through the Steps in reverse. This is our favorite video because Musk tells a great story where he’s made this exact mistake when they were struggling with a fiberglass mat that was mounted to the top of the Tesla battery. The installation of this mat was “choking the whole production line”. So, he and his team spent a lot of time working on ways to optimize the automation (robots) until one day Musk finally asked the The Battery Safety Team, “What the hell are these mats even for?”. They told him they were for “noise and vibration”. So he went to the Noise and Vibration Team, and they said they were for “fire safety”. So, they placed microphones and sensors inside 2 different cars and tested the noise and vibration with the mats in and with the mats out and they found no difference whatsoever. Needless to say, the mats were removed.

How this relates to software development

This one can relate to everything from a simple ticketing system to an elaborate e-commerce website. Both require people, processes and technology to be in place before any true automation can be implemented. Much the way the robots on the Tesla assembly line were not implemented until they were designed, tested, and optimized for each step of the assembly line, you should not automate anything until you can support that automation.

In one software product we made for a client, they wanted a Task Management feature that auto-generated tasks for people based on specific triggers within the system. For example, “When Team B enters X data, generate a task for Team B”. The problem was, the client didn’t have the teams to support all the auto-generated tasks — so tons of tasks were getting generated and left open in the system and the users eventually just ignored the whole Task Management feature.


The Importance of a Minimum Viable Product (MVP)

Even though this one isn’t a ‘Step’, it’s a great clip where Musk talks about how the first few Starship rockets all blew up for reasons that were not on their “Risk List”. In other words, the first Starship rockets they launched helped them uncover flaws that no one on their teams expected, which is one of the main points of launching an MVP first. You simply do not know, what you do not know.

How this relates to software development

Too many software product teams have a hard time whittling down the backlog of their product requirements to something that could be termed a Minimum Viable Product. We often hear excuses like “It’s really not a ‘Viable’ product without all its features.”, which is usually nonsense. More often than not, a product can be broken down into a logical set of releases that grow from an MVP to and official “1.0” full release. Whether you release only one set of features to a small sample of user personas or you release only the core features of the product that may still require manual work to be done on the back-end, and MVP is critical to the success of any product launch.

How We’d Make It Better: Microsoft Teams

‘You’re Muted!’

One issue that seems to happen on nearly every video call is that users don’t know or remember that they are muted. So, they begin talking and everyone else on the call starts saying “You’re Muted!”. It’s almost become a living meme at this point. One of the reasons this happens so often is that Teams only gives users some easy-to-miss indicators that let them know they are muted.

How we’d make it better:
Other video conferencing applications like GoToMeeting can detect that you are trying to talk when your microphone is muted and they display a message on top of the microphone icon letting you know “You’re muted” — hopefully before someone on the call yells at you. They also use a solid green icon to indicate an “On” state and a grey icon to indicate and ‘Off’ state for your microphone, camera, and screen sharing options. This use of dramatically different colors helps the user know when their microphone is “On” vs “Off”.

You're Muted!


Call Selected People

Having several people be part of a ‘team’ in a group chat can be convenient for discussions and sharing ideas but arranging calls between members of that team can sometimes get tricky. If one or several members are out that day, or you simply need to speak with a few people in that group chat, the Teams app requires you to make a call to the whole team or create an entire new group chat.

How we’d make it better:
Make the Video Chat and Audio Chat buttons into dropdowns that give users the option to call the whole group or just certain selected people. This frees the user from having to constantly create new group chats and avoid calling people who aren’t needed for a certain call.

MS Teams Call Selected


A Tab for Links

Links are shared very frequently in chats on Teams but finding a link someone posted days or weeks ago can be a challenge.

How we’d make it better:
Add a ‘Links’ tab next to the ‘Files’ tab where users can quickly scroll through the links posted in the chat.

MS Team Links


Search Within a Selected Chat

Teams has a decent global search function located in the top bar that enables you to search across all chats but sometimes you just want to find something within a selected chat instead of having to scroll back through all the messages. Currently, there is a hidden trick for doing this that requires you to somehow know to use the ‘command+F’ or ‘control+F’ keyboard shortcut. This will change the global search field into a ‘/find within @Chat’ function (see screenshot below).

How we’d make it better:

  • Add a search icon near the other action buttons within a given chat. Clicking this search icon would change the ‘global search’ field into the ‘/find within @Chat’ field.
  • The search results should then behave similar to the ‘Find’ feature in your Chrome web browser whereby the words you’re looking to find are highlighted in yellow and the scroll bar indicates all places within the chat that the word can also be found.

MS Team Chat Search


Chat Filter

After several months of chatting back and forth within a given group chat, the number of messages can really pile up. Sometimes you just want to filter down the messages to just those within a certain date range or from a certain user and right now there is no good way to do this.

How we’d make it better:
Add a ‘Filter’ icon to the action buttons within a given chat. When clicked, it could display filtering options, such as a date range and users.

MS Teams Chat Filter


Reply Feature

Sometimes several conversation topics start happening within a given group chat and it’s hard to keep track of what message is replying to what other message. Or, sometimes someone asks a series of specific questions in separate messages and you want to reply directly to each question instead of adding a single message to the bottom of the whole chat thread. Unfortunately, Teams does not provide a way to reply to a single message in a chat thread.

How we’d make it better:
iOS Message does a good job of letting you reply directly to a specific message within a conversation thread by providing a contextual menu on a message that includes a simple ‘Reply’ feature. For Teams, we would simply expand the existing ellipses menu to include a ‘Reply to this message’ option.

Teams Reply To This Message

How We’d Make It Better: Spotify (Vol. 1)

One of the things I hope you’ll notice when we go through the examples of how we would make Spotify better is that most of it has little to do with the User Interface design — but all of it has to do with the User Experience.

Content

Currently, Spotify provides a small area buried at the bottom of each Artist page containing a blurb ‘About’ the artist (if the artist provided one). However, there is a huge opportunity for Spotify to fill a void that’s been missing since the days of vinyl records, CDs and even cassettes and that is: Liner Notes and Artwork.

“Back in the day”, listening to music was always a multi-sensory, immersive experience where you would sit in your bedroom listening to music while looking at the artwork and reading all the Liner Notes, which often included :

  • Lyrics
  • Songwriting credits
  • Producer and sound engineering credits
  • Guest musicians
  • Album artwork credits
  • Thank you notes
  • And more

When you read the liner notes, you felt like you were really getting to know the band on a different level because you would learn all kinds of behind-the-scenes details about the music you were listening to. Sometimes it even gave you a better sense of the band’s personality and talents. Unfortunately, this whole experience went away when music started to be distributed via download and streaming services.

How We’d Make It Better:
The good news is that all this content exists — so if/when Spotify includes it in their product, they will fill that void and create an even better user experience for its customers.

This is a sample page of liner notes from Green Day’s ‘Dookie’ album. I always loved the raw sketchy look of this because it reminds me of the doodles I would make in my notebooks during school.


Sortable Column Headers

One of the great features of Spotify is its recommendation algorithm, which suggests artists that you may like based on other artists you’ve listened to. Now lets say you visit one of these recommended Artist’s page to see what other songs they have. The first thing you will see is a list called ‘Popular’ at the top, which seems to be a list of the most popular songs by the artist – but we’re not sure. Assuming this is a list of the artist’s most popular songs, the list (for some reason) is not sorted by showing songs with the most plays at the top. In fact, there’s no way of knowing how the list is sorted at all. And, even if you wanted to manually sort the song list by the number of plays, there’s no way to do that either.

In addition, it would also be useful if there was a column for ‘Album’ so that the users could see what album a particular song is on and link to it.

Spotify’s Artist Page with a song list you can’t sort.

How We’d Make It Better:

  • Add sortable column headers
  • Make the default view show the most popular songs first
  • Add a column for the name of the Album

We could do a whole series on what we would do to improve the iTunes user experience but it does have all the above features.

The Winery Dogs on iTunes

iTunes Song List with sortable columns.


The Spotify Artist Page does not provide a way to access “All Songs” by the selected Artist.

“All Songs” List

While the Artist page appears to show the top 5-10 most popular songs, there is no list or link to all songs by the Artist. You can expand the “Popular” list to see 5 more popular songs but somehow the Artist page leaves out a section and a link to all “Songs” by the artist. We’ve talked to several people about this one and they all noticed the same thing and are frustrated by this seemingly obvious omission. How can the Artist page in a music listening app contain all the sections listed below but not include a section for “Songs”?:

  • Popular
  • Popular releases
  • Albums
  • Singles and EPs
  • Featuring [Artist Name]
  • Fans also like
  • Discovered on
  • About
  • Offers

Of course there is a way to get to all the songs by an Artist — but you can’t get to it from the Artist page. Instead, you have to search for the artist and then filter the search results by “Songs” to see them.

How We’d Make It Better:

  • Simply change the “Popular” section name to “Songs”
  • Sort the “Songs” list by the most played songs at the top
  • Provide a link to “All Songs”

No-Repeat Shuffle

When a user uses the shuffle feature on either their own playlist of any list of songs, the expectation is that the songs will not repeat until all the songs have been played once. If you’re a Spotify user, you may be saying “But that’s what shuffle already does!” and you would be right, sort of. If you use shuffle on a song list and then close the app and open it again hours later or the next day and go back to play that same song list, you will likely hear songs repeat. For example, I have a Beach Mix containing 94 beach-themed songs. When my wife and I were on vacation with friends, I put my Beach Mix on one day and then, at some point, I turned it off. The next day, I put my Beach Mix on again and I heard several songs repeat from the previous day before playing other songs that had not played yet. In another example, we were driving a long distance and I was playing my mix of 98 Mellow Rock songs. We stopped a few times along the way and whenever we got back in the car and I put the same playlist on, we would hear songs repeat.

How We’d Make It Better:
Ideally, Spotify should utilize a songs “last played” date and time stamp so that when you shuffle a list of songs it knows to select songs with the older “last played” dates before playing songs with the newer dates.

Spotify Shuffle


In Conclusion…

As you can see, none of the examples above are focused on how the User Interface was designed or laid out but all of them impact the User Experience. They’re really more about content and either missing features or enhancements to existing features.

This Google Ads #UXFAIL Is Costing Customers Thousands of Dollars

Like most businesses these days, we run ads on Google to try and attract new business. The concept of Google Ads is great in theory because it helps you get found by people that are already searching for your type of business. However, despite the enormous success of Google, it is not without its flaws — especially from a UX design perspective. We already covered the 5 Things The New Gmail Design Got Wrong so we don’t want to look like we’re picking on Google – but this #UXFail is actually costing Google’s customers hundreds, if not thousands, of dollars each month.

Google Ads has a campaign type called “Call Only” ads. As the name implies, these ads are geared towards getting people to call your business. Well, during the pandemic we decided to run some Call Only ads and instead of qualified leads we received hundreds of calls from people looking for their local Unemployment Insurance office. Our phone began ringing off the hook – but for all the wrong reasons. At first we assumed there was something wrong with the way Google routes calls from their number (to track the clicks) to our business number. Google looked into it and they said it was not an issue. We tried asking each caller where they got our number and most just said they “Googled it”. We talked to our phone company to see if they could track down any routing issues. Given the fact that millions of people were suddenly unemployed, we thought the phone systems could be getting overloaded and causing issues. They found no issues. We looked up Unemployment Insurance office phone numbers to see if our phone number was published by mistake anywhere. It was not. We spent weeks and hundreds of dollars on clicks trying to figure out the issue until we gave up and just paused the Call Only ads.

Finally, a Breakthrough

TGA Google Ad

My brother owns TGA Legal Collections (shameless plug) and he asked me to help him run some Google Ads. These ads were set up to target companies that are looking to hire a firm to collect money from debtors that owe them money. Within one week of running his Call Only ads, he began getting calls. Unfortunately, the calls were not from companies but from debtors that were looking to make payments to a collection agency. Luckily, one of the debtors was nice enough to actually send my brother a screenshot of exactly what they Googled before calling his business. As you can see in the screenshot on the right, the debtor typed in the full name of the collection agency they were looking to make a payment to and the first result Google displayed was my brother’s ad. Clearly the debtor never read a word of the text in the ad — even after sending the screenshot to my brother — they just saw the huge phone number and clicked it.

Now you may think “why would someone click a phone number without reading who’s number it is?”. Well, a good UX designer always empathizes with users rather than blame them. So when we looked into it further it was clear that many Google users have become used to seeing the first result on Google’s Search Engine Results Page (SERP) as the one they want. Look at the screenshots below. Google a flight number and you get its status first. Google the weather and you see the weather first. Google the age of a celebrity and you see their age and photo first. It goes on and on. So when a Google user searches for a business, many users are being trained to believe that the first result is what they want and when they see a huge phone number they assume it’s the number of the business they want to call.

Google SERP

Google users have become used to seeing a result at the top as the one they need.

But Why Were These Ads Displayed At All?

The answer is simple: Since one of the main keywords we add to our UX Team campaign was “ui“, the ad was served up because millions of people during the pandemic were searching for their local Unemployment Insurance office — or “UI” office. Since one of the main keywords added to the TGA campaign is “collection agency“, the ad was served up because the debtor searched for “pressler collection agency“. So the ads being served up is not the issue. It’s doing exactly what it’s designed to do. The issue is that the users clicked the huge phone number without realizing it was not the number they wanted to dial.

The #UXFAIL

While making the phone number so big may seem like a good design idea for a Call Only ad, it is actually a huge flaw that is costing Google customers thousands of dollars in erroneous clicks. The visual hierarchy of the ad design places so much weight on the phone number that it drowns out all the other elements that would have informed these people who’s number they were really dialing.

Google Ad UX Fail Blurred

The screen on the right is blurred to help reveal the design’s visual hierarchy.

 

The Possible Solution

One possible solution to this design flaw is to address the ad’s visual hierarchy. A good visual hierarchy assigns a visual weight to various elements in a design to help inform users of what is most important, somewhat important, and less important. In these Call Only ads, the visual hierarchy should assign a high visual weight to business name or headline, a medium visual weight to the phone number line, and a low visual weight to the description text. By assigning a high visual weight to the business or headline, the users are far more likely to read it and realize that “UX Team™ UX Designers” are not the Unemployment Insurance office.

Google Ads UX Fail Solution

The design on the right shows how a few adjustments to the placement and visual weight of elements can improve the design and reduce erroneous calls.

 

 

 

 

 

 

 

 

 

 

 

 

Presenting Evidence-Based Design Recommendations

Much the way a prosecutor presents evidence to help a jury reach a verdict, we as designers must present the evidence to support our design recommendations. If you take the prosecutor comparison a step further, we also know that a prosecutor and a defense attorney can both have the exact same evidence to work with but it is the one that is better at presenting how that evidence should convince the jury to reach one verdict over another that will win the case. This is also true for designers. You can have ample evidence to support your design but if you don’t present that evidence in a clear, easy-to-understand manner, you may not win your case.

Start with the evidence

If everything in your design recommendation is built on top of a solid foundation of indisputable evidence, you stand a good chance of creating a convincing rationale for your design. If you start with an opinion, you are doomed because everything that follows can fall like a house of cards. By leading with the evidence you also build immediate confidence in your thought process, which adds credibility to everything you present next.

When we were hired to redesign an insurance quoting system, we were told the primary goal of the redesign was to “dramatically increase the number of small business quote submission”. To achieve this goal we created the following hypothesis:

“Based on our research, we now know that the MAJORITY of users value ‘Speed of Quote’ over ‘Price’ and ‘Coverage Options’. Therefore, to increase the volume of submitted quotes, the UX should be OPTIMIZED for the MAJORITY rather than degraded or compromised for both the majority and the minority.”

Then, throughout the project we carefully scrutinized every macro and micro design decision — from the overall user flow to every form field label name. One example of that related to selecting or editing building coverage options. Some of the initial design ideas being considered included accordions, multi-column layouts and drag and drop features. But, before we went too far down the design road, we first asked the following question: “Of the total small business policies written today, how many have just 1 building? How many have 2? How many have 3?, etc…”.

The Evidence:

Total Policies1 Building2 Buildings3 Buildings4 Buildings5+ Buildings
19,37217,5441,254319131124

Based on this data, the indisputable evidence shows that the mass-majority of small business policies have just 1 building.

Use the evidence to drive decisions

Now that we have the above evidence, we need to show how it should be used to drive our design decisions. This part is critical. If you don’t present the evidence in a way that leads to an obvious conclusion, you either don’t have good evidence or you’re not presenting it properly. In this case, we have great evidence but even great evidence can be met by some resistance because the evidence may lead to unwanted outcomes, such as additional development effort. In fact, often times during a software design project, the product team members will get hung up on trying to come up with design solutions that can accommodate both the mass majority and the extreme corner cases. The fact is, a “one-size-fits-all” UX is rarely the best solution for all your users. It may be the easiest to develop — but it will almost certainly degrade your UX for some of your users and you never want to degrade the UX for the majority.

So based on the number of buildings per policy, we recommended the following UX:

  1. For 90% of the users with one building, we will simply display rows for each coverage option that can be applied to the one building.
  2. For 10% of users with two or more buildings, we will display a multi-column layout so that coverage options can be applied across buildings one at a time or in bulk across multiple buildings in one action.

In other words, we ended up coming up with a UX solution that is optimized for both the majority and the minority. For the majority of users with just one building, we displayed a clean, easy-to-use list of coverage options to select from without any unnecessary clutter. For the minority of users with multiple buildings, we displayed a different layout that allows them to bulk apply coverage options across multiple buildings in one action since most users with multiple buildings select the same coverage options across all or most buildings.

The Bottom Line

Without the compelling evidence to help drive our design decisions, we almost certainly would have been pressured to create a one-size-fits-all UX with columns for each building — even though it would have completely contradicted our stated goal. Since we learned that 90% of the quotes would only have one building, it made no sense to display the one building in a column layout — but it made a lot of sense to use a column layout for more than one building.  A win-win for all users.

Why The Google Places API Search Failed Our Usability Tests

Whenever we perform usability tests, we inevitably discover something we didn’t expect — which is exactly why we test. In this case, we were designing a quoting system for insurance agents and the primary success criteria for the project was to “increase quote submissions by making the quoting process dramatically faster and easier for the agents”. When it comes to streamlining any complex process, it’s usually a lot of little tweaks that add up to significant time savings. For this quoting system, one of those things was the “Business Name” field. During our user shadowing sessions with the users, we observed how laborious and error-prone it was for users to enter the business name every time they created a quote. So, we suggested implementing the Google Places API Search, on the Google Maps Platform, which we’ve used on many other applications before with great success.

For this application, our stated hypothesis for using Places API was this:

“We believe that by replacing the text input field with the Google Places API search feature, we will optimize the overall efficiency of this required field for the following reasons:

  1. Redundant data entry will be reduced because the user can select a business from the results set after typing just a few characters
  2. User input errors will be reduced because the users will select a business from the search results
  3. Data quality and data mining capabilities will improve because businesses are motivated to keep their Google listings up-to-date because so many customers use Google
  4. Google’s Instant Autocomplete functionality is familiar to most users because of Google’s widespread usage and adoption”

Google’s ‘Familiar’ Instant Autocomplete Results

Since its official launch in 2008, most people have grown very familiar with how Google’s Instant Autocomplete search results work. You start typing something in and Google immediately starts to show you matching results that you can select. With Google’s Place’s API (shown to the right), a user begins to type a business name and Google immediately starts to display matching business names that are closest to the user’s location and they have the option of either selecting from the Instant Autocomplete results or selecting the option to create a new business listing.

The Surprise

In our initial usability tests, not a single agent selected a business from Google’s Instant Autocomplete results that displayed right in front of them as they typed. Instead, every one of them either typed the full business name or they copied and pasted the business name into the field from another data source. To be clear, we are not saying that Google’s Instant Autocomplete results are poorly designed, we are saying that when we implemented the feature in the redesign of an insurance quoting system, this ‘familiar’ feature was not used by agents as we expected it to be used. In fact, we were so baffled by the failed test results that we decided to test it again with non-agents just to see if we could narrow down the root cause of the failed test. As we suspected (and hoped), all non-agents selected from the search results rather than type the full business name or copy and paste it into the field. 

The Lessons Learned

So why did such as familiar feature fail our usability test? We believe the primary reason was “Learned Behavior”. The agents we tested all use many different insurance quoting systems and not one of them uses Instant Autocomplete results for the Business Name field. Instead, as flawed as it may seem, they all use a simple free-form text entry field that requires the users to type in the full business name. So, the users are simply used to typing the full business name instead of selecting it because within the context of an insurance quoting system, that’s what they’ve always done.

The Solution

So how do we change the way the agents see this Business Name field so that they use it more as a search box instead of a text entry field? We took a page from the CueActionRewards (CAR) Model in Behavioral Design, which is a proven design framework for inducing user habits.

How the Cue-Action-Reward (CAR) Model has been used to induce habits.

Source: The book “Human Behavior is Programmable”

In the case of this one Business Name field, we needed to make it visually obvious (Cues) that the results were ‘selectable’ so that it encouraged users to click (Action) a result because it would mean less typing, less errors, and it would provide an opportunity to pre-fill a lot of data within the quoting system based on the the unique ID of the selected business (Reward!).


Here’s what we did:

    • Added the word “Search” to the field label name and added a search icon as Cues to get agents to use this field as a search box rather than a text entry field.
    • Added the “Select a Matching Business” (Cue) to encourage a selection (Action) from the results set.
    • Added radio buttons (Cue) to the results to further encourage a selection (Action).
    • Colored the business names in the results set blue (Cue) to help indicate that they are clickable.
    • The Reward is then fulfilled by typing less and on the next screen a message informs the user that data was automatically pre-filled for the selected business, which we hope will encourage a repeat of the same use then next time the agents uses the Business Name field.

All This For a Single Form Field?

Yes. In order to “increase quote submissions by making the quoting process dramatically faster and easier for the agents” we needed to get this first form field right.

5 Reasons Why You Should Hire A ‘Dedicated UX Team’

Lately, more and more of our clients are taking advantage of our ‘Dedicated UX Team‘ engagement model whereby we carefully select and assign a group of UX resources to our client’s project(s) throughout the entire duration of our engagement. It seems too many businesses have experienced failed relationships with design firms because the firm constantly reassigns resources from one client project to another. So, unless you specifically request your consulting firm to provide you with a Dedicated Team, you’re likely going to engage in a time and material project where there’s no guarantee that the resources that start on your project are the ones that stay on your project.

Here are 5 reasons why you should make sure you hire a dedicated team:

1. Intellectual Capital

A lot of our clients have businesses that require a deep understanding of complex complicated business rules, regulations and compliance laws, technology requirements and limitations, and even unusual nomenclature and acronyms. So, there is simply no way a resource could be assigned to a halfway through a project’s completion and expect to create a great software product without that deep understanding. With a Dedicate Team, all the knowledge that is gained throughout a project is never lost. In fact, often times we end up presenting things about our client’s business that they didn’t even know about because our methodology requires us to perform specific research and user shadowing activities that were never done before.

2. Continuity & Consistency

Whether a given team people are designing a product, a website or a building, it is important that the design maintains a certain level of continuity and consistency throughout its complete end-user experience. Since a ‘Dedicated Team’ works on a project from its beginning, the design of your product will be far more consistent than if you had team members swapping out throughout your project. Any great design has baked-in design standards, rules and characteristics that are known by those who create them and those that document them. If you don’t maintain continuity and consistency in your product’s design, you’re users will surely let you know about it.

3. Trust & Stability

Throughout the course of any project, team members begin to develop a trust in each others abilities and recommendations. This trust adds stability to the team and makes the overall team perform much better and faster because everyone spends less time doubting each other and more time getting their jobs done.

4. The Best of Each Role

A great UX Team is typically comprised of Lead UX designer, UX designers, Front-end Developers, a Project Manager and sometimes other supporting resources such as researchers, testers and analysts. When you have a Dedicated Team, you can make sure that each resource on the team is focused on what they’re really good at instead of requiring team members to stretch their abilities to do things they’re not good at. The bottom line is that it is simply never a good idea to have Developers designing and Designers developing.

5. Enhanced Long-lasting Relationship

Some firms shield their clients from getting to know exactly who is doing the actual work for them. We believe in building a long-lasting relationship between our clients and their assigned team members. In fact, our clients get to know each team member on a first name basis, which sounds petty but this kind of enhanced relationship leads to better communication and a sense of comradery that helps the team gel and work more better together.

5 Things The New Gmail Design Got Wrong

Google recently launched its revamped Gmail design and, while there many things they got right, there are some things we feel they got wrong — in just the left sidebar. So, we took it upon ourselves to make a few suggested design tweaks that we feel correct some of the things the new Gmail does wrong and builds upon some of the good things Google introduces in their new design.

 

1. Poor Visual Hierarchy

As plain and simple the old “Classic” version of Gmail was, the one thing it had was a clear visual hierarchy. One of the most important considerations in any design is making sure the important elements appear important and the less important elements appear less important. In the Classic design, it was very clear that the ‘Compose’ button was the most important element. Then, maybe the Google logo appears to be the second most important, then the highlighted ‘Inbox’ label and ‘Drafts’ label, and then everything else. In the new Gmail design, the ‘Compose’ white button appears so unimportant that it almost gets lost and the red highlighted ‘Inbox’ appears most important. In addition, the weight of the icons seem to far outweigh their relative importance.

The Blur  Test
A great method we use to test a design’s visual hierarchy is the ‘Blur Test’, which is an old art school trick that helps reveal a design’s or painting’s primary focal point. In UX design, we take a screenshot of a design and apply a 3 to 4 pixel blur to it or we use a browser plugin such as Funkify to simulate someone visually impaired. When you do this, certain elements jump out and others drop back. As you can see in the blurred screenshots below, the new Gmail design has a fairly weak visual hierarchy. Beyond the highlighted ‘Inbox’, most elements carry a very similar visual weight. In our tweaked design, we made the ‘Compose’ button the most important, followed by the highlighted ‘Inbox’, followed by ‘Drafts’ and the other icon folders. In addition, we also indented the label names to help offset them from the other icon folders.

2. Using ‘Error Message’ colors for the highlight color

The new Gmail design uses a highlight color that is typically reserved for error messages and warnings. In general, UX designers need to be very careful about how and where they use the color red in their software designs because users are so used thinking something has gone wrong when they see red. In the screenshot below you will see a typical error message displayed below the new ‘Inbox’ to demonstrate how similar they look. In our tweaked design, we used used the familiar color of a yellow highlighter marker as the background instead of using a light red/pink background.

3. Detached “Unread” numbers

In the ‘Classic’ Gmail design, the total number of unread messages appears directly connected to the corresponding folder. In the new Gmail design, the unread numbers appear very far away from its corresponding folder. In our tweaked design, we moved the number back to where it was in the ‘Classic’ design.

4. Inconsistent primary action button color

The new ‘Compose’ button uses a white background which not only gets lost but it’s also inconsistent with Google’s own design standards. In other Google applications, the primary action color is blue. Even within Gmail’s message window, the ‘Send’ button is blue – so it would seem logical to use a blue ‘Compose’ action button. We are not saying the ‘Compose’ button must follow Google’s own standards but if it is meant to be the most important element on the screen it should look like it.

5. Poor icon spacing and size

The icons are a nice touch in the new Gmail design but they are far bigger than they need to be and the 27 pixels of space between the icons and the label names make the icons feel a bit too detached from each other. In our tweaked design, we made the icons 20% smaller and reduced the space between the icons and label to just 12 pixels.

 

 

Why and How UX Designers Should Perform User Shadowing

What is User Shadowing?

User Shadowing is an extremely useful behavioral observation practice that is used by UX designers and researchers to learn how people perform day-to-day tasks within their natural environment. It is especially useful when designing software products that will be used by people within a work environment, such as an office setting, lab, shop or out in the field. The key learnings from each user shadowing session are then compiled and used to help inform the design of a software product’s user experience. Some of the key learnings can include:

  • What the user’s (actual) job responsibilities are: On more than one occasion, we revealed job responsibilities that were quite different than what our direct client thought a user’s responsibilities were. In fact, on one project our shadowing sessions resulted in a company revamping and redefining all their job descriptions.
  • What steps do the users perform to complete their day-to-day jobs: Often times, our shadowing sessions will not only uncover many redundant steps but also inconsistent steps performed among users of the same role.
  • What systems, paperwork and people do the users interact with: This is often the biggest eye-opener because a client will usually bring us in thinking they need us to redesign a single software product but then we reveal that their users are actually interacting with a dozen or more applications to get a single task done.
  • What data and features should be surfaced and made more accessible to the users: After observing a few users, you may quickly see a pattern whereby the users are constantly navigating deep into an application to find specific data elements or features. Instead of leaving these buried in the new application, you may consider surfacing them directly onto the user’s initial home screen.
  • What pain-points do the users struggle with: Are they constantly entering redundant data in multiple places? Do they need to log into and bounce around between multiple disparate systems? Do they struggle to find certain screens and data elements? Is the currently system painfully slow? Are they performing workarounds just to get their job done?

The key principle of shadowing is that the UX researcher(s) act only as unbiased observer. They are not to interfere with the user as that interference might change the way the user behaves in any given circumstance. Once the user completes a given task, the researcher can then ask questions about the completed task and/or ask the user to walk through the task again – but it is critical that the researcher refrain from interrupting the natural flow of the user.

How Many Users Should You Shadow?

To determine the number of users you should shadow, first start by defining the number of user personas the product you are designing has. Then, try to shadowing 3-5 users that represent each persona. For example, if your product has Call Center Reps, Supervisors, and System Admins, you should try to shadow 3-5 of each. Typically, once you’ve observed more than 5, your observations will yield less and less unique findings.

How Long Should User Shadowing Take?

Shadowing can take place over any time period. It can be as short as a 30-minute session or it can be very involved and take place over a period of days or weeks. The exact length of shadowing is normally determined by what the user does and what the researcher wishes to learn.

Key User Shadowing Tips:

Record the sessions:
When possible, shadowing sessions should be recorded as they are conducted because the ability to playback a recorded session will prove to be invaluable. It is simply impossible for a researcher to capture every action the observe. In fact, you can have 5 researchers participate in the same shadowing session and each will observe different things and even have different interpretations of what they witnessed. The recording becomes the indisputable evidence.

The method you choose to record the sessions is also important because you should make sure the recording method does not distract the user from their normal activities and behaviors. For example, pointing a camera at the user can make them much more apprehensive and aware that they are being recorded, which will make them behave differently than the normally would. Using a simple web conference service like GoToMeeting or WebEx can be a great recording method for users that work at a desk all day because:

  1. The setup is quick and easy. Just email the user a link to click on, have them dial into a number, and then put their desk phone on speaker so you can record whatever the user says and whatever questions you ask.
  2. Once setup, the user will quickly forget they are being recorded and behave more naturally.
  3. Others can join the call and silently listen in and watch without being physically present.

Choose your researcher(s) carefully:
Shadowing is all about trying making sure the user feels at ease because, ideally, you want them to behave and perform their tasks as they would if you weren’t there. So, it is critical that the researcher:

  1. Is able to refrain from interrupting the user’s natural flow of work.
  2. Is not someone perceived to be superior or of a higher rank to the user because the user may feel intimidated and cautious about what they do and what they say.
  3. Is completely unbiased and is not tempted to introduce their own preferences or thoughts on how the user should do things. Shadowing is about learning and informing your design decisions. It’s not about training or gaining support for a possible solution.

2018 Google Trends Shows Dramatic Increase in “UX” Search Terms

While doing some keyword research in Google Trends for our website (which I highly recommend), I discovered a very interesting and dramatic upward trend in the amount of “ux design” searches and “User experience design” topics since 2004. What I think this confirms is that more and more people are realizing just how important the User Experience is for their business and products. We, at UX Team, have certainly noticed it in not only the volume of leads we get but in the quality as well. People are simply more educated and need less convincing that they need to invest in UX in order to produce successful software products and websites.

So, it it time to step down from our UX Soapbox?

Not quite. There are still plenty of companies that are just beginning to learn the value of UX and they need firms, like UX Team, to educate them. We still find ourselves in either early sales meetings or Team Work Sessions where we have to get on our soapbox and promote the importance of user shadowing, usability testing and prototyping. So, the specific activities and deliverables produced by UX Team still require some convincing – but the need to convince folks that they need to focus on the User Experience is certainly a lot less challenging than ever.

See for yourself: https://trends.google.com/trends/explore?date=all&geo=US&q=ux%20design,%2Fg%2F120_g8jl