Communicating User Design - Case Study

Visual storytelling is coming up more and more in my work as a UX/Product Designer. Typically this takes the form of prototyping, whether it be an interactive wireframe or super sleek micro interaction.  While this will often get you a bunch of high-fives or great work emoji in Dribbble it can often leave your end user flustered and unsure of what is happening. This is where storytelling needs to augment the following in order for your product to be effective.

Over recent years storytelling has become the structure I use not only to present my work but to construct persona user flows and the very foundations of my designs. Just to caveat, I'm not a novelist, writer or any other form of literary person. Yes that's right, I could be completely off the mark here but this is how I see stories being constructive.

To me, my stories are lineal with a start, a hero, a problem the hero has to solve and an ending.

I know this might be viewed as a massive oversimplification that any writer out there would be yelling about by now, but just think of crafting your design from the start with your Hero (persona), the problem (engaging with your app or site) and the ending (completing the task your hero first opened the app or site for). In short, craft a story that helps everyone engage with and understand their user journey.

 

Visual language

Visual language taps into the foundation of human-centric design.

Humans created visual language before the alphabet we use today. And this is still buried deep within our psyche. Just think of the last time you had an emotional connection to an image, that's right, pictures are truly worth a 1000 words. As a product designer it is your role to create a visual language depicting the path you wish your users to take.

Photo by JORGE LOPEZ 

Storytelling 

Most designs start with a random set of requirements whether they be from analytics, a user request or a new piece of functionality.  

These items can often be chaotic and counterintuitive, but there is always method in the madness.

Data on it’s own means nothing. An overview of data presents high-level information that is helpful but rarely actionable. In other words this will give you the outline of your plot but it will not allow you to tell the whole story. 

I used this diagram to provide the structure and context for my story, as it allows you to take a larger or holistic view of the problem, rather than my own intimate view that often contains biases and frustrations. 

Once you start focusing in, the random nature of the requests can often create whole new meaning. Allowing you to perceive a piece of functionality or interaction pattern in a whole new way. The closer you look, the more texture and detail you see.

 

The Story of your design

Putting all these elements together can take time, but if you cannot communicate your design effectively the time is wasted. This is why telling your story not just visually but also in context allows others to share in your vision.

Ok, here is the story from a product that I'm currently working on.

The product allows users to take their Blood Pressure (BP) and provide the BP data to their doctor from home.

To tell my story I start with the persona.

Lynne is 79 years old and has hypertension (high blood pressure). Due to the nature of her hypertension she is required to go to her doctor on a weekly basis to take BP readings. Lynne does have the Internet at home that her son setup for her and she uses her iPhone on a daily basis for facetiming her grandchildren, messaging friends and family members and of course talking on the phone. The Apple store has set up the iPhone to use accessibility mode for messaging and phone calls because her hands and eyesight just don't work that well anymore. Because of this. it is very hard for her to consistently use interactive elements in most apps (they are to small) despite this she has tried several applications but just can't get them to work consistently.

Our Facts

• Requires regular measurements to be taken
• Requires the Doctor to be able to view BP data
• The user is happy to use technology
• Help is needed to set up devices
• Owns a smart phone and is happy to use its features
• Requires applications to be very simple to use 
• Requires applications to have very large touch targets

Obviously, all of this is a fictionalised version but you can see that functionality is already starting to come to the forefront.

Set of goals

• Device communicates measurement to the user through real-time on-screen display
• A visual indication is provided to the user around connection status between the device in the smartphone
• Data can automatically be provided to a third party without the need to use a interaction beyond initial setup
• Clear step-by-step on-boarding process (diagrams, text, animations and video)
• On screen interactive elements must be extremely large
• Minimise the number of interactions needed to take and send BP data

 

Turning Stories Into Reality 

Interactive prototype

Use all these items as talking points and always refer them to your persona for example in the below design through user testing we noticed that there was a lag between when the app was first opened and the Bluetooth connection was established even though this connection time was only 400ms. 

Connection sequence

We created a loading screen that illustrated this connection, but also made the connection animation far longer than the actual connection time to illustrate that the device was communicating to the phone. 

We also dynamically converted the interface to educate the user between the inactive (grey) and active (green) states for the buttons throughout the application. The main page was stripped back to have a single primary interaction (starting your BP Reading) and mad the burger menu almost disappear by making it small and in a lower opacity. You will also notice that we have clearly defined instructions for every step always on the screen. This was done as we noticed the retention time could vary. Also as we are dealing with older audiences, having clear written instructions that didn't require an interaction for them to be revealed was a safety net. This allowed for either a quick on boarding (if it was their first time) or the re-engaging of a user (if they hadn’t taken a reading in a few weeks).

Obtaining a reading

Because of the nature of the BP reading we required the user to sit relatively stationary for the length of the test. We found that by displaying the numbers during the reading, the person concentrated on what they were doing rather than being distracted by other things and creating a false reading. 

The Done Sequence

We found many uses believing the test was done once the reading was established. As such more time was required to sink the data to the online profile. To address this we triggered a done screen that instructed the user to wait until the a big green tick is displayed. This gave us the time to connect and sink the data to the online profile without the user dismissing the reading or requiring an additional user interaction.

Adjusting the interface for the audience

By looking at the interface you can clearly see that everything looks big. This is because we have almost doubled the standard sizing put forward by the HIG or Material Design Systems. We've also reduced the number of taps to 1 to gain a successful reading. This is because the audience that we're looking at often have poor eyesight and other ailments such as arthritis making a touch interface quite hard to use. I have depicted the pause the application required  to communicate with its online services an animation so that the job can be achieved without the need for additional interactions and reeding errors.

We also established that speech interfaces were not very successful with an older audience as many suffered from respiratory issues that made both the Android and IOS assistances struggle.

You will also notice that we allowed for the ability to do a full deep dive for the technically savvy user who wished to see all their data with graphs; online integration; Apple watch accessibility; Health kit integration as well as closed user group sharing.

Summing it up

By presenting your features as you would describe them, you can see the true user story is told. In this instance, I have used design and interaction patterns to communicate to the user what is happening without telling them info they did not need to know. As this simplified interaction with the application, spoke to our target ordnance and did not  breaking the application narrative.

Password Suck

 

Making Passwords Better.

Let’s start by playing a game of 'have you ever'. 

So my question is, have you ever tried entering a password onto a new service, only to find that the service has a set of opinionated or even arbitrary rules stopping you from using the password you wish to use?

You must use at least 1 symbol, 1 number, 1 uppercase letter, and 1 lowercase letter and 1 unicorn.

Let me set-up a situation for you:

There is a new online pop-up store offering great deals but they require you to create an account before you can save or buy items.

So @WorkToday@ is your go to password. You used it for a bunch of products before you came across our pop-up store that wasn’t cool with it. That’s the thing about opinionated services — they often disagree. Maybe they need numbers or dislike special characters, maybe they love upper case letters but hate you using the same character more than once, and so on. 

That night you jump back into our pop-up and you try some permutations of your go to passwords but you can’t get in. It’s time to use the password reset link again, which at this point is basically your login button.

The pop-up store then reminds you that your new password will not work because it was to close to your old password. If you’re me, this is the point where you decide that those new jeans are just not worth it and you want to chuck your computer/phone/tablet across the room, and yell out to your mates the the pop-up store sucks. You can’t believe its real and you ask yourself how does this thing even exist with such a crap system?

That’s right, these dumb rules in the registration system have not only lost our pop-up store a client but done it is such a way that the one user has influenced other users to stay away. All because developers with your best interests in mind thought they were helping.

 

Risks and Rewards

Now, just to be clear I'm talking about those non-technical people who either write down their passwords on sticky notes or use a single password for multiple services. Yes, I realise these are both terrible ideas but a lot of non-technical people with online services/passwords do exactly this.

So, the fact that this is dumb is not the point. The idea here is that it’s the users decision. Perhaps, to the user, the convenience of a single email/password combination is worth the risk of their accounts being cracked.

Because of this a lot of login systems assume users carry no responsibility for their account’s security. Instead, the application must carry the burden. Many apps opt to do this the easy way — sticking to the status quo and treating their users like children. 

If I was to play user advocate at this point, you should inform your users but not insist. Your users, should have the right to weigh up Risks and Rewards. 

If you’re me you use a password manager tool such as 1Password or LastPass and always turn on two-factor authentication

Your users are not actually children, and will resent these inconveniences being forced upon them. This is what we call bad user experience.

In short by adding layers of complexity, you most likely are not helping your users  but instead you are hurting their experience and feelings towards your brand or service.

Making It Better

As a UX designer working on your app’s registration, you want a simple friction free way your users can login. But as you care about them, you don’t want them to have the awful experience of their account being cracked. Unfortunately you just can’t, Passwords are susceptible to brute force attacks, phishing scams, guessing, and the evergreen classic looking-over-someone’s-shoulder. 

Being a UX designer puts the responsibly on your developers to secure the backend (make sure they Hash and Salt passwords, keep the user database secure, implement throttling and check for changes in geolocation). Your responsibility is the experience of your users. To this, offer a variety of methods for enabling two-factor on your app, make sure your password recovery system is solid. Inform your users of the benefits of good password habits but leave the ultimate password decision to them.

Remember, your App/services exist for our users, not despite them. I like to think you can get people to use strong passwords by using simple clear language describing the risk of weak password and have easy to use two-factor methods or password manager integration without negatively affecting their experience using our products. 

Better Ways.

Build and Encourage Two-Factor Authentication.

When you set up your two-factor authentication system, make sure to integrate it with the systems your users have. Let them choose how they want to authenticate, whether it’s email, text, carrier pigeon or going through a maize of underground volts  Get Smart style . Make it convenient for them to be secure. And once you do, write out the messages you send them in a way they’ll understand.

Encourage your users to turn two-factor on after a few days of use in order to reduce the burden on the setup flow.

You can do what services like slack are doing with a magic link and Yahoo with their Account Key. The term “two-factor” isn’t  mentioned anywhere.

 

Strength Meters

Use Password meters to incentivise users to use more secure passwords. Who doesn't like getting a green bar?

While this is a good reason to add one, there are some down sides: 

• "Weak password” doesn’t inform your user how to create a strong password. 
• “Excellent password” doesn’t inform your userwhy it’s good.

Also this is an easy way to fall into the trap of treating your users like children again.

 

Inform, Inform, Inform

You don’t want your users to get lost, or even just follow the steps in a flow. You should inform them allowing them to understand what they’re doing. Motivating your user to create a better password is all about information. Making a bar turn green is fun and satisfying, but it doesn’t make a long-lasting difference and making your two-factor system amazing is good for you but your user still needs to turn it on. 

To go biblical on this "Make someone choose a good password, secure them for a day. Teach them what makes a good password, secure them for a lifetime.”

Let’s shift the motivation away from getting the password meter to green or getting through this one form. Let’s get people to choose good passwords for the sake of security.

Time for another scenario. 

Your non-technical user enters “password” as their password. On submit or after validating a message displays stating something like: Sorry about this but your password is currently number 3 on the all time most commonly used passwords. Are you sure you wish to use it? 

With buttons options stating: Change password and Happy to use it

By doing this you have moved the blame away from the frustration being placed on your registration system and onto your user. Also you have informed them in a way that just may be they will try using better passwords in the future

 

Looking forward

For those more tech savvy readers, you already know that passwords are on the way out. This is because of how bad passwords are from a user perspective and the fact that they are far from perfect as a security method. The password is slowly being replaced by biometrics and user-friendly two-factor authentication systems. For the average user, it’s unlikely that we will be rid of them anytime soon. So, until we are all face scanning, finger printing and retina/eyeball reading our way into that shopping app, let’s all do our best to make the humble passwords better.

Building Better Forms

Forms are one of the most important conversion components of UX design. In this article I will be focusing on common dos and don’ts of form design. Keep in mind that these are general guidelines and there are exceptions to every rule.

To Many Fields

One of the most common errors made is requiring more information up front than is absolutely necessary. For every field, ask yourself if the value of the data is higher than the loss of the user.

The questions I ask here is: Am I happy to loose 10% of the users to get this info?

This means that of the 100 users that started your form only 53 will submit the info after 5 fields.

Other things to consider here are high risk fields like phone numbers, date of birth and weight. Try to remove the need for fields like these or only display them to your most engaged users.

Aligning Field Labels

In the Western world we have been conditionedto read from left to right and from the top down. For this reason you will see much higher completion rate with top aligned labeled forms than left aligned labels. Aligning your labels above the entry field will also translate well on mobile.

That said, you should always consider your audience:

• Are they only using desktops?

• Where are the from?

• How computer literate are they?

The big downside with using a top align label is the level of consideration users give to each input. Left aligned labels mostly have a higher level of consideration to the data entered. Also for large data-sets it can make the form look smaller. This gives the appearance that the user requires less effort to complete the form.

One Column

We live in a world of long scrolling. Multiple columns disrupt a users momentum both loosing the context of where they are and adding to the cognitive load required. This also applies to Checkboxes and Radio buttons.

Grouping and Labels

Reduce the concentration a form requires to complete by placing the label and input fields close together. It is a good rule to allow at least half the field height between each label and input group.

Also group batches of content into similar types. This will have the effect of making your form feel less overwhelming and will be clearer to your user, allowing them to complete the form much faster.

Avoid All Caps

All caps can be difficult to read especially at a glance. Try using title or sentence casing. But this can also raise some issues. Check out this article for how to title case: http://www.onlinegrammar.com.au/title-and-sentence-case/

Show Selection Options

Placing options in a selector drop-down requires two clicks, and hides the options. Use an input selector if there are under 5 options. If your drop-down is more than 5 options you should look at adding filtering or sub-groups as it is better to show 2, 10 option drop-down fields than 1, 20 option drop-down field.

Placeholder Text

It is always a tempting option to use placeholder text as your labels.  We all have done this at some point and it can make your design look far cleaner and your form look shorter.  Unfortunately this will make it difficult for people to remember what information belongs in a field, and to check for/fix errors. It also poses additional effort on your users' visual and cognitive load. In short this will kill your completion rate.

Inline Errors

How often have you got to the end of a form only to find it will not submit and the only indication of this is a little red message at the top of the form, that is almost always not displayed in your current page view.

When displaying errors, always show the user where the error is, provide a reason in clear easy to understand text that is placed in the location of the error. Also indicate that there was an error around the submit/next/save... button.

Try to not use inline validation as the user fills out the field unless it helps to complete the process ie. a multi-line text box with a character count. Having a field change as the user is typing will distract your user, increase the difficulty of the task and reduce the complication rate.

Helper Text

Ditch the “i” button at the end of a entry field. It is always better to display helper text wherever possible. You will get much better quality inputs by showing short well written helper text than long detailed helper text hidden under a button/hover state. If complex helper text is needed, try only displaying it when the field is in a  focused state.

Field Length

The length of the field should indicate the length the the information required. Think about fields that have a defined character count like phone numbers and post/zip codes.

Field Type Restrictions

It is also tempting to only restrict the data entry type to number or character count in phone numbers and post/zip code fields. It is worth noting that many modern phone numbers and post/zip codes have special characters or text in them.

Mandatory and Optional Fields

We always seem to add a (*) to indicate a required field. It is worthwhile considering that users may not understand what this means. Try adding optional (yes the actual word) beside optional fields as users know the need to enter information. But if it is up to me an optional field equals a field that is not required so why are we displaying it again?

Why ask?

Wearables, Mobiles, Browsers and Password Managers collect large amounts of data without the user’s consciously aware.

Think of ways you can leverage this data through: conversational UI, SMS, email, voice, OCR, location, fingerprint, biometric, etc.

Call to Action (CTA)

A call to action should state your intent but this should not be at the detriment of your site or apps personality. It is always a good rule to think about the reaction and perhaps try being less confronting. For example, instead of a Read More button try using Continue Reading.

Personality is Key

No one, Yes absolutely no one wants to fill out forms. Try being conversational, funny and gradually engage the user. If done correctly, it will increase completion rates. That said it not worth doing this if it breaks the rules outlined above.

Death to the Loading Icon

Our insight here was that we needed to make it clear you are advancing toward your goal and not waiting. For example, in Google’s search application, elements move in, supporting the informational hierarchy and making it feel like content is loading immediately even when it isn’t. Google also focuses the user on progress by integrating the loading indicator into the transition animation moving left to right as the page you requested loads.

Incremental loading or skeleton screens are one of the best ways to focus your user on progress and not the frustration of waiting. You can effectively eliminate loading icons for load times from 100ms to approximately 450ms. Essentially a skeleton screen is a blank version of a page into which information is gradually loaded. As you can see in the below example, this creates a sense of immediacy, making the user feel like they can engage with content right away, even when your load times are the same as they were when you used a traditional loading indicator.

This technique focuses the user on the content and not the frustration of load times. That said, repetitive animations can also be just as annoying. When applying these techniques ensure there is variety in your animations and use them sparingly. In fact limiting your use of animations is good advice in most cases.

Just a quick postscript: next time you are developing or updating an app, mock-up a version with a traditional loading indicator and a version with a Progressive load. Once this is done, go around your workplace betting your colleagues which version loads faster. As they both will load in the same time frame, they most likely will be shouting you your next cheeky after work Beer, Coffee or Green Tea thing.

HUMAN-CENTERED DESIGN

The human-centered design approach is all about communication, that's right, your Interface should use everyday language and the Snapchats of the world aside your interface should not require a steep learning curve or your users to be a member of the in crowd.

An interface should feel like a good friend, whom is always ready to help out at a moments notice.

BE HUMANS NOT A ROBOTS

93% of how humans communicate is non-verbal (55% body language and 38% tone of voice). Much in the way that what we say is only a small part of what we're communicating, text and imagery is only a small part of what your interface is communicating

- “Albert Mehrabian - Professor Emeritus of Psychology, UCLA”

In this way your interface needs to tick these three boxes:

• Provide feedback to actions
• Show direct manipulation queues
• Display results of actions in an expected way

1) SHOW WHAT’S HAPPENING

The first usability heuristic principle by Jakob Nielsen states: keep your user informed about what is happening.

Users expect to get responses immediately. As we know this is not always possible. In cases where you cannot show immediate results or a skeleton load, try displaying an interesting (or odd) animation. Now we have all seen loading bars and spinners. Whilst you can make do with these, you should try to go beyond the simple and possibly give your user a smile. 

In my world of Smiles and Cry’s, think smiles and not hair pulling out finger tapping frustration.

2) CONTEXT IS KEY

With many different smart things being worn, carried and interacted with on screens of all sizes, it’s highly important to provide clear navigational divides between different pages. A user must understand where they are at all times and have a clear way of navigating back, undoing options and seeing all stages of progression.

3) STATE CHANGES SHOULD BE CLEAR TO ALL

You often need to change out buttons and states on your site or application as a user interacts with it. Simply replacing a button or line of text can easily be missed by a user. That said there is no need to go overboard and show big pop-up notifications for minor changes. A small animation will/can attract the eyes of a user guiding them to that piece of important information or state change.

4) MOVEMENT /ACTION

Micro-interactions must help users understand/how to engage with an interface no matter how uncommon or unfamiliar the interface is. Apart from helping a user effectively interact with an application, micro-interactions have the power to encourage users to keep on browsing, like, or share content. Basically they are a key part in convincing users to take the next step.

5) INPUT PROGRESSION

Form completion (Data input) is one of the most important elements of any application or site.  Forms are pretty boring and are only as effective as the information entered. 

• Always guide your user (tell them upfront) how many steps involved in the form,
• Make every field feel like progress in completing the task
• Give constant updates to the user as they progress so they don't get to the end of the form and find they made an error 20 questions ago. 
• Make the input type clear (give examples of what input is required) 
• On particularly long forms it may help to cheer your user on at steps throughout the form. 
• Of course never ever have an input field that is not absolutely required, we've all seen results of how much drop-off is caused by every additional field

For more on forms see Getting Forms Completed

6) TUTORIALS

With a new site or update to your application be sure to inform your users on the changes. The best way to do this is to train your users through the use of an example fly through (tutorial). 

A quick note here: always ensure your tutorials are annotated clearly, have an obvious forward and backwards progression and allow your user to skip or access the tutorial within a single action.

SUMMING IT UP

So, if you value the experience of your users, UX matters. How your users feel when using the product is key to adoption and creating advocates for your application or site. Even minor details deserve close attention. You should always aim for approachability and simplicity no matter the complexity of the logic behind the interface. 

User-centered Development in not a fix Process

Which camp do you were fall into

Do you believe that timelines and process kill creativity or do you believe that a predefined rigid process is the only way to get something done?

At the far end of this spectrum, extremely dangerous business practices can be found.

So with this I'm going to preach flexibility

I think we can all agree that the integration of user-centered thinking and product development requires structure. But it also requires creativity around user engagement, design and utility.

Also we should to be wary of the need to make money. This means the product needs to be in the hands of the end user.

These words (I’ve deliberately avoided calling them “approaches”)

It’s currently a popular trend to come up with new ways to work through the same problems to deliver the same end result. One month, documentation of any type is dead. And the next month, wireframes are outdated in favour of whiteboard and paper sketch delivery.

A more realistic and humanistic approach is to simply be flexible. Some projects require more detailed documentation than others. For some, you may be able to partner with a developer and draw your wireframes on a napkin over a beer, and for others offshore teams may need overly complex functional specifications, annotated wireframes and interactive prototypes to appropriately deliver your product. Flexibility allows teams to collaboratively define the approach for each project. The best laid plan is specific to the product at hand, the money and time available, and the resources working on the project.

The flexible approach to delivery shouldn’t be misconstrued as being disorganised, and it certainly doesn’t equate to being a pushover.

You must be firm in your rationale for required deliverables and your approach to each project.

Timelines and Process

In order to be successful with a UX strategy or even elements of a UX practice, you need to be able to discuss timelines. As project plans grow they will organically include UX. Until that time, here are some barriers and outlines of typical situations that are likely to occur.

Barrier

Time allotment will have no relevance to the actual items required to be delivered.

Project plans and timelines will likely be created in a vacuum, and UX and UI won’t have a voice. To this I say speak to the people who are doing the work. Have them agree how much time something will take and have them take ownership of this time allocation (if you work with the same people on multiple projects you'll get an understanding of how individuals quote time and you can adjust project plans accordingly).

Supportive/Advocate

Once you have all your resources agreed to and how much time individual deliverables will take, then you own those resources for those allocated times. No other project should infringe on your allocated workflow and on the flipside you need to meet the deadlines set out by your project plan or meet your deliverables when they are due. The flexibility comes here by tracking your burn rate on a daily basis and having your project plans with sufficient detail to know every deliverable element and the exact number of minutes required to achieve each item. You should know long before a deadline that you are not going to achieve it, allowing you to adjust expectations and due dates accordingly.

Work-in-progress

Underlying all of this is the need to proactively share work with all involved throughout the process. Work-in-progress sharing allows teams to better understand the process and approach from beginning to end.

UX and creative teams, especially agencies, are known for intaking a project and going behind the scenes for weeks at a time before the grand reveal.

At this point, the timeline is exhausted. And if there’s objection, the timeline suffers—and, ultimately, so does the end user.

Prototyping and co-designing of product development creates a greater sense of ownership with all parties and delivers a stronger product to the end user.

Business Requirements

Central to software product development is the creation of business requirements. It’s common for UX to react to requirements and create deliverables in response to hundreds of detailed orders. We must change this.

User-centered product development represents this change. Insight user research drives project goals, requirements, and success. All requirements and engineering approaches should be derived from listening to your users at the outset of the project. Ideally, this includes an equal amount of qualitative and quantitative research.

 “Tell UX what needs to go on the screen. Don’t tell UX how it goes on the screen.” 

Think ofbusiness requirements as a list of goals, how they appear on the screen is up to the UX strategist.

Pushback

“Foster positive collaboration instead of a takeover mentality.”

This pushback will likely cause initial friction because business analysts, project managers and producers, who are responsible for creating requirements, tend to fill the UX vacuum when there are no UX professionals engaged in the project. They may view this as a takeover of their work.

But this isn’t the case—their role is extremely valuable, and they can be great partners in helping the UX movement. Foster positive collaboration instead of a takeover mentality—it’ll build a bridge to future work.

Okay, I realise I may have just stated a bunch of things that you probably think about everyday. What is important to remember here is that being flexible throughout in tire project process is the most important step in the creation of an amazing product.

This is an excerpt from Principles of UX Design, an InVision e-course by Timothy Embretson.