Situation

Cyberlucent was ready to improve their product's aesthetics. Their biggest fear was that the language used in the product would not resonate with their target customer.

Situation

When CyberLucent™ first introduced their project to me, they weren't interested in my design services at all. Fast forward 2 months later and they came back from an investor pitch that went awry. Turns out, the investor thought their user interface wasn't up to par.

Task

I was tasked with leading their remote C-Level team to garner alignment amongst dozens of stakeholders in different time zones all across the United States.

Task

I was tasked with leading their remote C-Level team to garner alignment amongst dozens of people in different time zones all across the United States.

Task

I was tasked with leading their remote C-Level team to garner alignment amongst dozens of people in different time zones all across the United States.

Task

I was tasked with leading their remote C-Level team to garner alignment amongst dozens of people in different time zones all across the United States.

Before

It has been said that the original user interface was "clunky." In reality, the product was a report delivered offline as a PDF.

Legacy User Interface

Here is the original user interface that the investor had said was "clunky." The context in which this was delivered was offline in PDF format. Something that we'd set out to change for this project's objective.

Action

I prescribed Design Sprints. It was the most efficient way to re-design the user interface and test language understanding with the target users.

Action

I prescribed Design Sprints, because it was the fastest way to prove design is more than just "look and feel."

Action

I prescribed Design Sprints, because it was the fastest way to prove design is more than just "look and feel."

Design Sprint Map

Here's our map for the design sprint.

Sketches

All stakeholders got to participate in this "napkin" sketch exercise on day two of the sprint. We took pictures of our "napkins" with our mobile phones and uploaded to Miro/Realtimeboard. Then the CEO chose the final screens we'd prototype.

Sketch Wireframe

Wireframes are one of the most important steps in the design process. This allows the team to get alignment quickly and inexpensively. In the Design Sprint process, I invite all stakeholders to participate in the "napkin" sketch exercise on Tuesday. The CEO or decider ultimately makes the decision which direction the team goes in. The next step is prototyping.

Sketch Wireframe

Wireframes are one of the most important steps in the design process. This allows the team to get alignment quickly and inexpensively. In the Design Sprint process, I invite all stakeholders to participate in the "napkin" sketch exercise on Tuesday. The CEO or decider ultimately makes the decision which direction the team goes in. The next step is prototyping.

Task Flow Completion Analysis

Here we've cleaned up the napkin sketch and outlined the ideal task completion test we hoped the users would get through.

Task Flow

In this phase of the design process, the remotely distributed team interacts with a virtual white board. Here, we can see a cleaned up version from our previous "napkin" sketch wireframe. This allows for more concise copy to be written. The arrows indicate where a button takes the user through the journey. This exercise helps stakeholders define the user story and journey. This will later act as a script for when we setup the user to test the prototype during the testing phase.

Task Flow

In this phase of the design process, the remotely distributed team interacts with a virtual white board. Here, we can see a cleaned up version from our previous "napkin" sketch wireframe. This allows for more concise copy to be written. The arrows indicate where a button takes the user through the journey. This exercise helps stakeholders define the user story and journey. This will later act as a script for when we setup the user to test the prototype during the testing phase.

In-Person Moderated User Testing

The first design sprint, we had users abandon at the display ad on CNN's website. This was a clear indication to the product owner that advertising to this target audience was not going to play well. Word of mouth would be a much more reliable marketing methodology, and it was up to the product to delight the user to make that happen.

Pivotal Turning Point

The big question of this Design Sprint was to answer,

"What language resonates with CEOs of lawfirms, so they avoid involving information technologists and rely on Cyberlucent's app to troubleshoot their cyber security risks?"

After the first week of user testing the team knew the current terminology came off as jargon to the target user persona. This led me to think about the foundations of "art & copy." As the Catholic Church did in the 17th century with illiterate pilgrims, so too, could Cyberlucent do with non-tech savvy target audience.

Therefore, by incorporating GoDaddy's logo next to "SSL Certificate" we were able to overcome the jargon barrier. Likewise, putting the Internet Explorer logo in context to the problem, helps users comprehend what the problem is, and spurs their intuition to fix the issue using the app.

Result

In two weeks time, the team was able to overcome their own inherent bias of what language they thought their target audience understood. As a result, with restored confidence in their user interface, Cyberlucent immediately continued fundraising efforts the following week.

Lessons Learned

It's ok if not everyone on the C-Level team is in complete agreement. That's where the Design Sprint comes in. The CEO is the ultimate decider and he or she decides which direction we test.
Design workshops can be very successful faciliated remotely as long as everyone is on good internet with updated computer equipment and software.
Getting the board in alignment early on gets their buyin later to avoid "poop and swoop" syndrome.
Using brand logo identity instead of jargon is faster to comprehension for busy people with low cognitive bandwidth.
Requirement documents that are too concise on what technology or methods developers should use to implement them are faulty. Instead use "User Requirements" to merely state what the target user requirements are. For example, "user requires a login method." No need to state "with Facebook Login API" or anything overly complex. This allows the developer to be more creative in their solution. Developers are designers too.