Web Development optimize

User flows in web design

Making use of user flows helps ensure that a site is clear, intuitive, and usable.

It's a basic tenet of usability that software must support multiple screen flows and click patterns through a system.

This means that we must allow for different interaction styles and different page flows in designing our websites and apps. We must also create pointers for users to navigate back through their journey if they get lost.

Traditionally in web development, this has meant using breadcrumbs as a navigational aid. Breadcrumbs are very useful for websites that have a lot of pages with conventional information architectures. However, breadcrumbs don't necessarily work in other contexts, such as mobile websites or mobile apps. In these cases, the primary navigational tool may be search or high-level functionality tied to persistent app elements. For a microsite, content may be surfaced through on-page elements and Calls To Action; for a news site, it may be surfaced via promotion modules and related content.

Creating user flows is a useful way to map how users may interact with your site or app. User flows have long been used in web design for figuring out information architecture and site structure. They are also useful for figuring out the purchase journey of an e-commerce platform.

However, user flows are often created early in the site-development process, and then condensed to representative flows. While this is fine for mapping out the basic flow of the simple website or application, it frequently represents the basic interaction pattern of the designer or developer.

Because of this psychological blind spot, we often miss other interaction patterns that may be common for other users. We can also miss edge cases and dead ends.

For this reason, creating screen flows throughout the definition and development process is a useful thing. This can help you to ensure that different flows have been accounted for.

Creating a screen flow is relatively simple; it can be done with printouts and scissors. If you are at the definition stage of your website, you can use wireframes; if you're at the design stage, you can use page designs; and, if you have an in-progress website, you can use the website itself.

Print out the pages or screenshots, and stick them up on the wall. Trace your way through the site, starting with a basic click path. Try getting into the head space of one of your personas, and figure out how they might fulfill their needs with your website. See if there are any situations where the user might get lost or confused. Take notes.

Once you have done that, try a more complex click path. Perhaps the user has arrived via a search engine, and has landed on an inside page. How do they get back to the home page? Do they navigate by search, by breadcrumbs, or is content surfaced on the page that will help them navigate?

Once you've completed these user flows, you can fix any issues you've identified.

Repeat this process until you are satisfied that your site is navigable and not confusing for your users.

If you have budget for user testing, you should take notes of how your test subjects navigate your site. They may find issues that you've missed. If you don't have budget for this, try to do some guerilla user testing.

You should repeat this process once your site is built. You can click through the site and ensure that there are no dead ends, confusing elements, and users can navigate your site easily.

Once you've actually deployed your site, you can use analytics software to track site flows with actual user data.

If your site has Google Analytics installed, you can track the click path via the "Visitors Flow" function. You can also isolate exit pages and pages that have a high bounce rate, and ensure that these pages aren't confusing or alienating users.

You can also use the Google Analytics Goal functionality to map out the expected user flows and purchase funnels on your site. This will allow you to track where users are deviating from the expected flow. If your site has e-commerce capability, tracking the purchase funnel can help you to see whether users are aborting their purchases.

By using this technique, you can ensure that your site is clear, intuitive, and usable, and that your users don't get frustrated and leave.

About

Barry Saunders is a UX Architect. He has worked on projects for News Ltd, Google, Westpac, EFIC, WWF-Australia, QUT, and SBS.

40 comments
GSG
GSG

I highly recommend that everyone in this conversation read the terms of use that you agreed to when you joined TR. http://cbsitou.custhelp.com/app/answers/detail/a_id/1320/ If you don't wish to abide by the terms of use, then we will be glad to terminate your accounts. So start behaving like professionals instead of 10 year olds in a playground namecalling fight. I swear, do NOT make me come over there and send you to your rooms for a time out!

Duke E Love
Duke E Love

>>what else may be buried in them either. What could possibly be buried in Google's CDN? Malware? If so millions of developers are at risk.

Duke E Love
Duke E Love

As a "Web Designer", blocking Google APIs on your clients computers shows a gross level of incompetence and ignorance of how the web works. Your ideas were valid some 5 or 10 years ago but are woefully out of date. In other words. You really don't know what you are doing but you are convinced that you are. Which makes you a liability to any client that hires you. And since you show no inclination to change your mind in light of compelling information contrary of your beliefs or even bother reading them I can only conclude that you are an ID ten T. Seriously. Quit pretending you are an expert when you don't know jack about jack;

Duke E Love
Duke E Love

Your post contains so much misinformation I do not even know where to start. You should not be let near a "clueless users" computer as you are clueless yourself.

Deadly Ernest
Deadly Ernest

I learnt web design so long ago that css was not yet a part of the equation. we were told that any decent web site of more than one page had on each page either a contents menu (often set in a frame) or a menu banner so people could easily manoeuvre about the site. I rarely see that today with so many sites like a mashup, and wonder if we should go back to insisting it's an important part of good site design. Now onto the other aspects to keep in mind. Many organisations advising users on Internet security, such as law enforcement agencies and the like, advise users to make certain adjustments to their browsers and how they operate. Chief amongst these are: - AV software. - Install a firewall. - Disallow third party cookies. - Disallow third party scripts; this often requires an add-in or such to do. - Install ad blocking plug-ins, and set these to stop third party site calls without approval. - Set up to block certain sites due to the high risks involved with them or the types of ads they push out, eg adult site ad servers. When I set up a computer for the average clueless user I speak with them about this and show them some of the government and law enforcement sites with those recommendations. One of the things I do as often as I can is to set the client up to use Fire Fox with the add-in of AdBlockPlus and then set ABP to block certain sites - chief amongst those are Google Analytics (because some ad servers don't push ads if they get no GA input) and googleapis as these are often used by driveby sites to send you to their malware downloads; they also stop one hell of a lot of ads. There are many other sites that are just ad server sites I set up to block as well. I also train the user in how to train ABP to block more sites as they go about their browsing. Now, the reason I mention the above is I've noticed that some sites will NOT provide the site data until after the ads are pushed out, this means that I don't get to see what I went to that site for, and it goes on my list of rectum sites to advise people NOT to visit as it's now suspect of being a malware delivery site. Also, the blocking of third party cookies and scripts will often stop the content being called from that site being presented, with the same result as the previous item. I mention this as tonight I got sent a link to a site to view a musical item and the item was called by a third party script from an ad server. I did a search and found the original on a different site to either of those two - YouTube. It is important in your web design to keep such behaviours in mind as you also have to test the site for performance and delivery factors when people set up to stop your ads and mashups from hitting their screens. So set up such software and see how your site looks when it's viewed through such a set up. In some cases the simple action of downloading the actual API from Google and placing it on your site instead of calling it from the Google site will make the difference between it working or being blocked. Analytical software on your server and part of your site will work where such software being called as a third party will be blocked. People visit your site for a reason, and they trust your site, but not a third party, so use your site to deliver the information instead of taking the easy way out and using a third party that may be blocked due to security.

Deadly Ernest
Deadly Ernest

type of site I want to use, and is not the best way to build a website in general. Where static information is being provide the use of lots of scripts and / or external calls to get the information only slows down the delivery of the information. Once I establish a link between your site and mine, the quickest way to to have your servers provide the code direct to mine, not have it call a server elsewhere in the world and send the data over. But the concepts of easy to read and quick to supply with simplicity seems to be beyond you an others. Not all websites need or benefit from huge swags of video and other fancy images or scripts, but that concept also seems to be beyond you. I notice those pages don't tell you how to deal with things when people set up security to block the ads you want to push at them and if that security also blocks what else you want to push from elsewhere, maybe they should get a does of user reality too. BTW I'm not the only one blocking third party scripts, third party apis, and Google apis.

Deadly Ernest
Deadly Ernest

if you block third party code calls, you block ALL third party code calls, including Google's ones to call ads - which is their main purpose and is the main reason for blocking the third party calls, to stop the ads. The fact it also stops other third party code calls that include sending you to places to get malware is an added benefit. Now, it seems I've mentioned this process a few times already, but you seem either unable to comprehend the concept or totally uninterested in the idea of people NOT getting ads or malware. We've been around this bush too many times, so I'll reiterate the main point of the original post that relates to the initiating blog - - When testing a web site works the way you want it to, you need to include checks to test it still works when people have set up security measures that are outside the unsecure default settings most systems come with. In this case I pointed out the police recommended actions of stopping the operation of ALL third party cookies and third party code calls as well as including the use of settings to limit ads via this same process and included some specific third party code calls - such as Googleapis and Google Analytics. Like it or not, it's a way to cut back on paying to have someone force feed ads to your system, and since we pay for each MB downloaded, it saves the users money as well.

Deadly Ernest
Deadly Ernest

is to use third party script calls for scripts and code you can load on your own server if you take the time and trouble to do so. All the Google APIs are small scripts and can be easily copied and loaded locally so they do NOT have to be called as third party ones, except for those involved with activating and calling ads from the Google servers. Ads that most users do NOT want and are NOT interested in. So why don't you just admit you're either a lazy web designer or one who makes money from serving ads and can't stand the idea of NOT serving ads up to everyone, or is it something more malicious as the other major use of such code is to deliver malware.

Deadly Ernest
Deadly Ernest

It's usual when making a comment that you disagree with someone, either me or Barry, to include something to indicate what you specifically disagree with and why, not just make a silly troll like statement with no real sense or meaning that is personal abuse of the person.

boxfiddler
boxfiddler

Oh wait. I already asked that. Knock it off already.

Slunk
Slunk

I have seen your sites. You do not know what you are doing, Your code is on the 4th grade level. No CSS, no JS, You use font tags ferfucksake. Font tags have been depreciated for over ten years. No server side ANYTHING, No AJAX, no nothing other than HTML 2 or 3 at best. You have absolutely no concept of modern web development techniques. None. Zero. Zilch. If we set the clocks back 12 years you would still be at a 101 level. Nor do you have a basic understanding of how the web works or how invaluable "free" content like stackoverflow.com is paid for, And yet, you lecture me?

Duke E Love
Duke E Love

That I am talking about high traffic sites and not the Podunk mom and pop sites you work on? On my low traffic sites I have no problem with serving up the files locally and I do not use a CDN. I really do not care where the files come from. That is the least of my worries. And to be clear. If you think that blocking Google's CDN will not make you, or anyone, safer then you really have no idea what you are doing. That is just stupid. >> So why don't you just admit you're either a lazy web designer or one who makes money from serving ads Because I am not a web designer. I am a software developer. PPL like me write the software that ppl like you use to make your web sites. Again, your world view is so small that you cannot possibly see a world beyond that of making Podunk websites. To you there are no other possibilities. So go back to your little crappy world of dream weaver or front page and STFU.

Duke E Love
Duke E Love

Barry's post was quite good. You block Google APIs? Do you know why developers even use CDN's?

Deadly Ernest
Deadly Ernest

you're ready to address the point I raised in my original post about testing to suit user needs. Just because users don't things the way you want them to so you can be a lazy coder doesn't automatically mean they're wrong and you're right. There is absolutely NO reason why you HAVE to call an API as a third party script call, the Google apis can be downloaded and loaded locally, but that would require you to amend the call location for each website you work on and thus require you to think and do some work instead of just a cut and paste job. Googleapis do nothing and provide nothing that cannot be done locally, the same is true of the vast majority of third party script calls, but blocking them will greatly reduce the ads sent to you and reduce the risk of malware and other nasty code - a security measure you seem to think should NOT be used, thus I wonder what you actually do for a living since you dislike user security.

Duke E Love
Duke E Love

You are an idiot. Blocking Google API's is stupid. It displays immeasurable ignorance and incompetence. All other points are moot, other than you suck at making "web pages". You are not a web designer... You are an HTML monkey.

Deadly Ernest
Deadly Ernest

to comprehend what I've previously written. A few basic static pages don't HAVE to have a css to do the job and writing them in basic html allows them to be a smaller download and quicker to see. So you chose the first option in the profile choices, is that because none of the others really apply to you? I suspect you're the one who has no grasp on the realities of life and Internet usage, as you can't provide even a basic answer to the original comments or my questions except to be personally abusive; showing your immaturity and lack of knowledge at the same time.

Duke E Love
Duke E Love

Do you even know any web languages other than html? You don't even use CSS ferfucksake. That dates your skill set to about 2000 or so. You do know that nearly all professional websites run some sort of back end (or front end) programming languages.

Duke E Love
Duke E Love

>>own profile lists you as a computer product reseller / retailer What is the first choice on the drop down when you create an account here? >>BTW I'm still waiting for you to provide a reasonable answer to the point I raised at the start on testing how software stand up against unexpected user operations. I am still waiting for a reasonable answer to why a grossly incompetent loser like you feels that they are in a position to offer advice when you have no idea what you are doing. Pfft. You are at the skill level of a kid in grade school.

Deadly Ernest
Deadly Ernest

own profile lists you as a computer product reseller / retailer and not an engineer which you claim to be at times. BTW I'm still waiting for you to provide a reasonable answer to the point I raised at the start on testing how software stand up against unexpected user operations.

Deadly Ernest
Deadly Ernest

to be a software engineer. HTML is a coding language used to create simple and small web pages, which is why I use it for static info web pages - it saves a lot in bandwidth to doing the same thing with Javascript and wasteful unneeded third party apis or code calls.

Slunk
Slunk

To be out classed in all respects? There is nothing you can do web related that I can't do better. Period.

Slunk
Slunk

It is markup. Loser.

Deadly Ernest
Deadly Ernest

the user with java or anything but basic html. I suppose you always buy the cars with every damn accessory available, even when you know you won't be using more than one or two of the twenty odd you have it overloaded with. Like any well done engineering, a web site should be kept simple and have the basics needed to do the job and no excess crap, end of story. So that's what I do, just what's needed to do the job. BTW using your sock puppet to make extra comments just shows how immature your behaviour is.

Deadly Ernest
Deadly Ernest

own advice "and STFU." Since you don't care where the files come from, you obviously don't care what else may be buried in them either.

dogknees
dogknees

The fact that the majority of web-designers/coders use code on other sites in no way indicates that it is the best way to go, just the most common. Any argument based on "what the majority do" is flawed and irrelevant.

Deadly Ernest
Deadly Ernest

lazy people try to make websites has changed as they try to charge a lot for doing a little by using what others have done. Then you have those working hard to rip people off through serving ads and malware as well.

Deadly Ernest
Deadly Ernest

to your server is justified in what manner other than being too lazy to download and install them? I'm still waiting for someone to give a reasonable explanation of or why they feel they have to call so many third party scripts instead of putting the content on their own servers? People visit a website to see material from the company that owns the website, not others website's material, but it seems to annoy a few of you that people take action to stop the practice of doing a mashup style site. BTW It's interesting that your tone, and position, as well as profile is a perfect match for DEL except for the town in Florida.

Slunk
Slunk

>>There is NOTHING that you can put on a website that requires a third party cookie or script call that can NOT be done by either putting it on your own server or by showing it as a hot-link with the information the user needs to make a decision to go to it or not. You really do not understand the internet. It has changed dramatically in the last few years.

Slunk
Slunk

I usually don't get involved with these sorts of conversations but this one takes the cake. Your "beliefs" concerning the nature of web development are so out of date and quite frankly, flat out wrong, on so many levels that it makes my head hurt. It is quite obvious that you have never been responsible for a website of significant scale or have used (or are even aware of) modern web development methodologies and the distributed nature of modern website development. I.E the web as a platform. You are seeing things from the vantage point of hosting a site on shared hosting, a VPS or a dedicated server, where I (and apparently Duke) come from a world of Mashups, data centers, clustering, load balancers, caching servers etc. Since you describe yourself (and people who make websites) as "web designers" I can only conclude that you have never been employed in a professional development environment. Because if you did you would be out of a job. You would not last long enough at a reputable web development firm to organize your your desk if you told clients to block Google API's in order to block ads and/or for "security" reasons. That said, you have absolutely no business calling yourself a web designer, web developer or even "my cousin who makes websites". Just a heads up, among professional circles "web designer" is code for "I can't do that".

Deadly Ernest
Deadly Ernest

at this time say this is the way to do it. An example of that is for several thousands of years the best practice for dealing with captured enemy soldiers was to just kill them, but we don't do that now as we have a better way. You say the current best practice is to feed content from another site to the user without them knowing it at all, while I say it's a better practice to feed them content only from your site or do so in a way it's clear to them it's from another site and allow them to choose to see it or not. The most common form of content delivery from an external site is ads, stuff which most users do NOT want to see, and given the option to not see it they'll take the option and you lose you ad revenue - for which I give you no sympathy. It's clear to me that we'll never agree on this issue, so I see no point in going around this bush again. The main point I WAS raising in my first post on this thread was that people take action to stop external content delivery, some due to ad protection, some due to security protection, and it behoves the website designer to check if the site will STILL deliver the critical information the user was seeking should their system be set NOT to allow external scripts or accept external content. A very valid comment about ensuring the site still delivers its main message. BTW I go to a website to see info and stuff from that site, not info from another site or ads from elsewhere, and I'm not alone in this. The easy way is a short script to call it from elsewhere, the harder way out is to download it and place it on your own server after taking the time to check it's OK and slipping it into the right directory.

Duke E Love
Duke E Love

Using a CDN has NOTHING to do with taking the easy way out (nothing, zero zilch) and everything to do with best practices, optimizing user experience and developing high performance websites that can handle thousands to millions hits a day. http://en.wikipedia.org/wiki/Content_delivery_network Just about every high traffic website uses a CDN of some sort, I highly doubt that Facebook, Google, Yahoo and Tech Republic itself are "taking the easy way out".

Deadly Ernest
Deadly Ernest

you want to take the easy way out and just use a script to call another script from another site instead of placing the called script on your own site server. The task of copying it to your site is dead easy, but you and others choose to take the easy way out. That's your choice, but it does mean anyone setting up tight security on their system (their choice, like mine) will NOT be working the site you build the way you want it, which is part of what I said right at the start - you need to test if the site will work when it's not used how you want it used by the user. The majority of external calls I see of scripts from other sites are for ads and ad servers. Your love of these would indicate you love serving other peoples' ads than the intended user's ease of use. BTW you can easily get malware hits and the like from visiting everyday websites - I've seen a few on genealogy sites and even places like YouTube will sometimes dispense sex site related ads as well.

Duke E Love
Duke E Love

It has nothing to do with being lazy or being a “good designer”. To the contrary, it is common knowledge that using a CDN for static assets such as JS libraries, stylesheets and images *significantly* increases a website's performance and download speed. http://www.yuiblog.com/blog/2007/04/11/performance-research-part-4/ http://developer.yahoo.com/performance/rules.html http://stackoverflow.com/questions/2704490/what-are-cdn-best-practices There are other reasons for using a CDN, the least of which are lowering server load and bandwidth. This may not seem like much but on high traffic sites this is crucial. So when you block a (very popular) CDN like Google API's you are doing little more than crippling and/or breaking these sites for your "clueless user". And seeing that there has been a fundamental shift of a website functionality from server side to client side scripting you are doing far more harm than good. I don't know what your obsession is about blocking ads (apparently at all costs) and as far a malware goes I will tell what I tell my father. "If you stopped going to those girly sites and other shady websites you won't have these problems".

Deadly Ernest
Deadly Ernest

how you go about designing a web site to be the most effective and safe to use. I strongly believe it should be done in a way that is efficient in download, presentation, and safe to use as well, while it delivers the information or actions required of it. This means, in what I was taught and have found is best practice, is that everything for the site should be on the same server and all under the control and management of the web master. This means there is NO NEED for third party cookies or script calls, this means the site is a lot safer for the user. However, with so many quick and easy ways of doing things by just using the work someone else has done you can create a site with lots of third party cookies, scripts, and other stuff. So instead of creating a real local website you end up with a mash-up of some sort. If you like that, well do so, but don't expect me to use it or recommend it to people as every time you leave your server to get something from another place you open the site and the user to a possible security breach. The other main reason many people use third party services is to make money by serving up ads from Google Ads and the like. Like 99.999999% of the people in the world I go to a website to see what they have on their web site, not to see who they let put ads on the web page. I do NOT like having to pay for download of crappy ads so you, as the website owner, can make money off my visit to your site. If you want to make my use of your site harder or more costly, then you can't blame me for not returning to the site of buying from you. In the USA people may get free downloads, but the majority of the world the ISPs charge people for each megabyte of downloaded material, so any effort to reduce the rubbish like ads is very good work. Most ads come from third party services, so there's another reason for stopping all third party activity. As I said, this disagreement is NOT about skill sets, but about how you use those skills in the real world. There is NOTHING that you can put on a website that requires a third party cookie or script call that can NOT be done by either putting it on your own server or by showing it as a hot-link with the information the user needs to make a decision to go to it or not. BTW In regards to the Google APIs I mention I block that you seem to think so highly of, they are damn easy to download from Google and to place on your own website server instead of calling them from Google, thus eliminating the third party call and aspect of them.

Duke E Love
Duke E Love

It is not my responsibility to keep your skill set current.

Deadly Ernest
Deadly Ernest

copy them onto your site and use them from there. The issue is the blocking of third party scripts stops a lot of the malware scripts being run on drive-by sites. However, to allow some and not the others to work takes a lot more work and effort than you can expect of the average user. Thus the simple blocking of all automatic third party activity. If you set your site so that the third party calls require an active approval by the user and you give them a full and fair disclosure of what's required, then the user is changing the third party to be an active first party site. The key is to give the user control and the knowledge to make an intelligent decision. A GOOD web designer WILL have all the scripts running off their server and not another site, will a LAZY designer will call from other sites instead of taking the little extra effort required to have their whole site run from their server. When calling a third party script you hand over total control of what that script does to the third party site, which is bad design and management. So I don't like sites made by lazy designers who can't be bothered taking the effort to do it right; so sue me over it. The other aspect is I'm NOT the only one advising people to block third party sites and scripts, a lot of law enforcement agencies are giving the same advice. Mind you, certain legislative requirements coming into effect in Europe will also have an effect in the use of third party sites and calls, so it makes more sense to do the site the right way to start.