What is wrong with website designers?

[36Drew]

Truthfully I feel like so many just go along "oh well that's just the way it is". I realize that these sites could be designed so that they would actually serve the purpose and be used with ease. All they need is some common sense and outside input added to the designers ability to create the site.

I assume, the designer or design team, show the management team a workup of the site, focusing on flashing banners and "neat little tricks" but the usability of the site is never demonstrated nor taken into account.

Well, let's just quash a great big myth at the moment - most websites that aren't mom-and-pop websites hosted for $4/month on Godaddy are not built by "a webdesigner". In fact, the "website" you are viewing is probably actually comprised of multiple "spinning bits" of technology and are often several different applications bolted together. Even if you're staring at the same URL.

So how is a web application generally built? Very similar to software.

A set of business requirements will be listed. These requirements will speak to the needs that the application fills, how it is to interact with other technology components (ie., access to billing data, user identity, access controls, etc), it might spell out design specifics or simply reference a corporate entity's own style and design guide. Deliverables and satisfaction criteria will be listed. From there, a technical design document will be created - which in turn provides a roadmap for the project. The TDD should spell out data requirements, integration points, adherance to specific company or industry standards, technology decisions, and high-level units of work - which in turn are further broken down by development teams.

QA is almost always included in the process to varying degrees. QA is treated with different levels of importance or disdain by different companies. Where the final product is, well, almost useless crap - you can rest assured the company does not take QA seriously at all and treats them with utter disdain. Where the product is utter crap and never gets fixed - the company doesn't even know what QA is.

The interface patterns and styles are generally developed by a UX team. They work with real people and go so far as to identify personality types that want to use the web app in different ways. Generally, they'll identify an uninformed/technically deficient user, a "light" user (I just want my bill), a heavy user (I want to manage my account information, I want to see what I'm paying for), and a power user (I want to track and manage my account usage). Their work generally culminates into a design or style guide, and oversight on the actual user experience and user interface of the application. Again, UX folks are engaged with varying degrees of importance or disdain.

So here's how "we" do it:

The department I work in is a full-service web shop for a large games company, and we operate the vast majority of the company's websites. We are operated as part of the marketing and communications team, and have been empowered to work to unify and clean up the company's web branding. The branding is horrifically broken across properties solely for the lack of inclusion of a real UX team. That is being rectified. UX is fully engaged now and holds regular testing sessions with real users. They bring their findings back to the team and design patterns are updated based on informed decisions rather than some "marketing dude's" wild-ass idea.

QA, over the past two years, has played a hugely increased role in site delivery. As a result, the quality of our web releases has increased exponentially. Sites go through constant iterations in multiple environments prior to being released for public consumption. By the time you get to see it, it's generally been fully tested and exercised several hundred times. Site updates are released twice weekly.

The company has recently just developed a "design pattern guide" that defines how various elements should look across all of the company's properties. Menus, navigation, image styles, buttons, etc. will, over the course of the next 18 months, be reworked to conform with the new design patterns. This guide was developed based on exposing real users to samples of design elements and garnering their direct feedback.

We are currently working on the TDD that I mentioned above. The next step is to develop a set of re-usable component templates based on the design patterns - and then to start implementing them. At first on the company's main web property, and then to start spreading them through other web properties (probably net-new properties).

As for complexities within what you think might be a single website... let's just take one of our properties as an example:

http://www.battlefield.com/
http://www.battlefield.com/battlefield-4
http://www.battlefield.com/hardline

Those are three very distinct websites, that are all stitched together under that one domain. Each has it's own technology stack. Hardline isn't even located in the same datacenter as the other two. What's good about that is all of the Battlefield information is located together in a common location. What sucks, however, is that the patterns between the sites are different. The navbar, the footer, the styling - is all inconsistent. Even the Origin integration is slightly different. It's confusing. It's also something that we've identified that sucks and have committed to fixing and doing better.

Unfortunately, many companies just don't take the time to look at their work and critique it. You know it sucks. I know it sucks. But the guys who built it and run it either don't see it or just don't care. They don't involve the right disciplines during the planning or design stages. They don't invite timely feedback. They don't process the feedback they receive.

So "what's wrong with web development companies"? No UX input, skimpy testing methodologies, no feedback mechanism, no desire for iterative improvements to achieve consistency, and a lack of effective communication between teams.

[my5cents]

Amazing that some corporate sites go to all this work only to produce a difficult awkward frustrating customer interface.

I think that last few sentences of your post are the problem. All the planning in the world doesn't necessarily make a good product, if the end user doesn't find it convenient to use. Field testing and response to feedback could fine tune a technically good site into a great site for all users.

The last thing a company wants is a customer who uses their site and leaves thinking bad thoughts of the company, and perhaps not accomplishing the task or purchase they wanted.

I just did a test. Although I haven't been a new driver for around 50 years, let's say I just lost my new driver sign, the one that all new drivers have to display.

I went to www.icbc.com, in the search area I entered "new driver sign"... You would think in two pages of answers I would find out how to get a new sign. Nope.

I wonder how many millions ICBC spent on it's vast web site.

[36Drew]

Amazing that some corporate sites go to all this work only to produce a difficult awkward frustrating customer interface.

I think that last few sentences of your post are the problem. All the planning in the world doesn't necessarily make a good product, if the end user doesn't find it convenient to use. Field testing and response to feedback could fine tune a technically good site into a great site for all users.

The last thing a company wants is a customer who uses their site and leaves thinking bad thoughts of the company, and perhaps not accomplishing the task or purchase they wanted.

I just did a test. Although I haven't been a new driver for around 50 years, let's say I just lost my new driver sign, the one that all new drivers have to display.

I went to http://www.icbc.com, in the search area I entered "new driver sign"... You would think in two pages of answers I would find out how to get a new sign. Nope.

I wonder how many millions ICBC spent on it's vast web site.

So you're focusing now on one of many facets (and still important) - content and access to it. Content is King. So at the outset of a project and during the active lifecycle, I would be asking the following questions of the department (and this is just very cursory):


Project Requirements
What intelligence has the UX team gathered from their engagement with real-world users?
What user profiles have been identified?
What pattern is acceptable by users to identify their user profile (ie., how do you easily and readily identify to me that you're a "new driver")?
What content is important to those user profiles?

Applications Requirements:
Search feature?
Content drilldown based on user profile?
Surfacing or ordering content differently by user profile?
How do we handle "negative content"? I'll delve into this one specifically in a moment...

Digital Intelligence:
Are we capturing searches? How? What?
What information are we gleaning from those searches? Are they paired with user profiles (40% of "New Drivers" search for "New Driver Sign")?
Is DI informing the creation or refactoring of content?


That's just a few very basic questions that need to be asked at the outset as well as during the active lifecycle of a product. How much money did/does ICBC spend on that tiny little subset? Probably not very much at all, as evidenced by your inability to quickly find some rather basic information in incredibly short order.

The "Negative Content" thing is a huge huge huge stickler for me. Have you ever gone to a website to find that they've moved content (ie., Castanet migrates forums, old URLs stop working)? How about mis-typing a URL accidentally? How about a search on a content-heavy website?

404's and failed searches are "Negative Content". Saying "Ooops" is a *bleep* way of handling negative content. Real world scenario (franchise name removed). NamelessGame recently release a Macintosh version of the game. They published the announcement and FAQ at http://www.namelessgame.com/mac - but then printed materials and published social media links as http://www.NameLessGame.com/Mac (Uppercase M makes the difference). Displaying an "Oh Crap" is a horrible experience, because we know if somebody goes to /Mac they really want to go to /mac - so instead of throwing a 404, we redirect them. The rule here is that if you know where a user really wants to go, then send them there instead of making them figure it out. You should be paying attention to your 404's (digital intelligence) to know when there's a spike in errors, and if you are getting hundreds per day to a given URL, then you should turn that 404 into proper negative content (redirect).

If you run a search, and can't find any hard and fast results, then you should do a fuzzy search and return those results. Like hey - I can't find "New Driver Sign" because it's not really called that. But I have a match for "N" "Driver" "Sign" - if that interests you, click on the link. Oh - and if I notice that I get a lot of people searching for "New Driver Sign" - maybe I should make sure that the article content for "Get Your N Sign" is actually surfaced properly.

What if I simply can't figure out where the heck to send you? I have no idea what you want, and fuzzy search isn't turning up anything? Maybe a relevant sitemap or content map would be useful here. Oh, and while I'm at it, how about I correlate how we got to this mess with the destination you choose. If it happens enough, and I can recognize a pattern (DI again), then I can properly guide users to what they're really after.

Let's pick on Castanet.... (Troy!!!!). I found this in about 5 seconds. http://www.castanet.net/news/ seems like an incredibly logical url, right? In fact, there are seemingly a variety of categorized news sections and articles that live under "/news/" - http://www.castanet.net/news/Kelowna/133457/Man-flees-from-police being the most recent article there right this moment. So what do you get if you just go to http://www.castanet.net/news/ ?

Code: Select all

Not Found

The requested URL /cgi-bin2/newNews/news_list.cgi was not found on this server.

Apache/2.2.15 (CentOS) Server at www.castanet.net Port 80

I know why that's there. There's no category tied to the URL. Their appstack is trying to figure out that category (/news/Kelowna would run new_kelowna_list.cgi, I'm sure). http://www.castanet.net/news/Kelowna gives a better user experience - you get a list. But no category gives you a horrible user experience, even though it's "technically" correct. Do you, as a user, see a problem with that? Based on what I've expressed above - what would you do differently, if anything? In fact, i think it's a good exercise for you (as a user), and I would think that perhaps Troy might gladly take your feedback.

[Troy]

Let's pick on Castanet.... (Troy!!!!). I found this in about 5 seconds. http://www.castanet.net/news/ seems like an incredibly logical url, right? In fact, there are seemingly a variety of categorized news sections and articles that live under "/news/" - http://www.castanet.net/news/Kelowna/133457/Man-flees-from-police being the most recent article there right this moment. So what do you get if you just go to http://www.castanet.net/news/ ?

Code: Select all

Not Found

The requested URL /cgi-bin2/newNews/news_list.cgi was not found on this server.

Apache/2.2.15 (CentOS) Server at www.castanet.net Port 80

I know why that's there. There's no category tied to the URL. Their appstack is trying to figure out that category (/news/Kelowna would run new_kelowna_list.cgi, I'm sure). http://www.castanet.net/news/Kelowna gives a better user experience - you get a list. But no category gives you a horrible user experience, even though it's "technically" correct. Do you, as a user, see a problem with that? Based on what I've expressed above - what would you do differently, if anything? In fact, i think it's a good exercise for you (as a user), and I would think that perhaps Troy might gladly take your feedback.

Hi 36Drew! Thanks for picking on us. ;)

The URL you've chosen ( http://www.castanet.net/news/ ) isn't linked to from anywhere at all. So, the odds are that this sort of thing being used is a non-issue. However, that being said, I've made a tweak to our news engine so that link will now take you to the complete Castanet news archive -- almost 127,000 stories so far.

Thanks for pointing this out! :)

[GenesisGT]

26Drew, the UX team is the important component of a final product that meets all requirements, including user needs, corporate needs and technical needs.

In the organization I worked for, I managed what I will call the user group, which was responsible for documenting the user requirements, interface, etc.. The one thing I changed was instead of my staff meeting with developers every couple of days/weeks to do testing, get updates on progress, etc. My staff member and the developer shared a cubicle. This gave the developer an instant answer to any user requirements question, while giving my staff great insight to the development process and how developers interpret written user requirements. At times the requirements would even be changed based on the discussion between the two, ending in a better product. And it saved a couple of projects headed towards a slow death.

The process was also reversed for the developers, which became involved in the development of user requirements.

I like developers. but constructive consultation with the end user to me, always leads to a far superior product.

[36Drew]

26Drew, the UX team is the important component of a final product that meets all requirements, including user needs, corporate needs and technical needs.

Pretty sure you and I are on the same page here.

In the organization I worked for, I managed what I will call the user group, which was responsible for documenting the user requirements, interface, etc.. The one thing I changed was instead of my staff meeting with developers every couple of days/weeks to do testing, get updates on progress, etc. My staff member and the developer shared a cubicle. This gave the developer an instant answer to any user requirements question, while giving my staff great insight to the development process and how developers interpret written user requirements. At times the requirements would even be changed based on the discussion between the two, ending in a better product. And it saved a couple of projects headed towards a slow death.

We work in cross-functional delivery teams. In any team, I have a producer, project manager, devops lead and technical director that form the team leadership as partners. Each team has a QA, UX, and DI representative. QA, devops, and the TD have their respective engineers sitting within the teams with a project-based focus implementing department-wide standards. A delivery team might be responsible for 10 "things", have 20-odd engineers (FE, BE, Devops) a testing-automation engineer, and a few manual QA folks all within the immediate area.

The company has a WorldWide QA department in Baton Rouge that performs manual QA tracked via testrails. We also have a rather extensive system in place for automated testing, based on Seleneium, Cucumber, and WATIR.

UX and DI play an incredibly huge part of the user requirements for our projects. Probably more-so than yours did. Our websites exist to engage players and sell games. They don't exist simply to provide a window into a user's account, however kludgy they may be. If we fail to engage users, then we've failed at our primary deliverable. Our UX team doesn't simply consult with users - they actually run UX labs and do trials. Real live players (our end-users) come into EA and get to test out
web features and design patterns. We alter our product development quite rapidly based on those lab trials.

The process was also reversed for the developers, which became involved in the development of user requirements.

I like developers. but constructive consultation with the end user to me, always leads to a far superior product.

I should mention that while I've been a code monkey, and can sling it just fine with developers, i'm not a developer. I'm a Devops manager. I believe, as you do, that constructive consultation with stakeholders is a must. The end-user is, indeed, a stakeholder.

[DANSPEED]

If in doubt slap BETA on it! I guess Telus's UX team in India never got my complaint!

Download bill (PDF) .....

" Your bill seems to be taking a while to generate. Please try again later. "

I hope the over usage charge is BETA too!

[rustled]

If in doubt slap BETA on it! I guess Telus's UX team in India never got my complaint!

Download bill (PDF) .....

" Your bill seems to be taking a while to generate. Please try again later. "

I hope the over usage charge is BETA too!

Sometimes (and I have absolutely no idea why) I can get around this issue by right-clicking the link and choosing "open in new tab" or "open in new window".

Does that make any sense to those of you who understand these things?

[I Think]

Many years ago I designed a software p rogram and paid a programmer to write it.
Quickly discovered that the programmer had no idea how to program a user interface, he kept assuming that the user was as knowledgeable as himself. I partially solved the problem by putting a pair of boxing gloves on his desk, telling him that unless he could run the program wearing boxing gloves, our customers could not use it.

The people who do traffic signs have the same problem, they know where the next town is, and figure that every driver does too, so their traffic signs are of limited help to out of town visitors.

[rekabis]

I've made a tweak to our news engine so that link will now take you to the complete Castanet news archive

And you’ve put a band-aid on a broken-leg problem. Better than nothing, but not by much.

The real thing to do is to never have a 404-type error - or a redirect to a generic page - unless absolutely necessary. If a page no longer exists in its original location, the article slug should be used to find the page in the new location, and a 301 Permanent Redirect used to redirect the user transparently to the new page. If there is no article slug, but there is a category slug, that slug should be used to conduct a 301 to the actual category, not to a generic “archive” page that might be next to useless. As an example, the /news/ category slug should be used to bring a user to the primary news page and *not* the archives. The slug itself suggests current news, not archives.

Yes, this kind of functionality does add a bit to the back end as you have to create a specialized search engine that returns just a single value, but on larger sites with many pages created daily and/or pages that shift every now and then to new categories, it is absolutely essential to prevent link rot on the outside.

Edit: slug name.

Edit2: a cgi-bin path? Are we talking about Perl??? Holy heck. Talk about rocking it old school. Clearly, a well-managed MVC framework is out of the question with Castanet… the devs are probably too busy with the buggy whips and slide rules to actually implement anything as modern as MVC…

Edit3: Apache 2.2.15‽ ***FACEPALM*** Really? You’re going to drop trou on the Internet, when 2.2.29 is available?? You must have some pretty hairy dependencies if you can’t even securely patch Apache to the latest 2.2 revision.

Edit4: I need sleep. Edited slug back to what it was in the URL itself.

[rekabis]

As for the Telus account interface itself, I believe that the problem here comes down to the same problem that exists in 99% of cases where you have a fully fleshed out team with both programmers and UI/UX designers:

MANGLEMENT INTERFERENCE

It is highly likely that Manglement decided that this interface should be released early, and so sent down word to the lower echelons that it should be enabled by default to anyone logging in. Actual developers/designers would never do something like this, nor would product testing or project managers -- you test with actual in-house or solicited testers, not with the public at large.

So yeah, this was probably a decision by Manglement, not by the rank-and-file workers who just follow orders.

[36Drew]

And you’ve put a band-aid on a broken-leg problem. Better than nothing, but not by much.

Troy made a modification, after-hours (almost midnight), on a weekend to fix up something that's an absolute edge case. Give the guy a little bit of credit.

The real thing to do is to never have a 404-type error - or a redirect to a generic page - unless absolutely necessary. If a page no longer exists in its original location, the article slug should be used to find the page in the new location, and a 301 Permanent Redirect used to redirect the user transparently to the new page. If there is no article slug, but there is a category slug, that slug should be used to conduct a 301 to the actual category, not to a generic “archive” page that might be next to useless. As an example, the /news/ category slug should be used to bring a user to the primary news page and *not* the archives. The slug itself suggests current news, not archives.

Pretty sure that the concept of negative content has already been mentioned a few times. Welcome to the conversation. Unfortunately, you're two days late. As for the best means to present that negative content, what data exactly are you basing your suggestion on? You don't have any access at all to Castanet's data intelligence or statistics. You have no idea the number of users that have or have not used the /news/ URL. You have no idea what is referencing, if anything at all. You've not performed any UX consultation with Castanet's userbase. Your opinion is, at this moment, entirely and completely uninformed.

Edit2: a cgi-bin path? Are we talking about Perl??? Holy heck. Talk about rocking it old school. Clearly, a well-managed MVC framework is out of the question with Castanet… the devs are probably too busy with the buggy whips and slide rules to actually implement anything as modern as MVC…

Edit3: Apache 2.2.15‽ ***FACEPALM*** Really? You’re going to drop trou on the Internet, when 2.2.29 is available?? You must have some pretty hairy dependencies if you can’t even securely patch Apache to the latest 2.2 revision.

Perl does have MVC frameworks available. There may be a significant investment in legacy code. There may be other business functions that require the use of Perl. There may be a significant investment in the decision to leverage Perl as a development platform. You have no idea what's there, and while it may not be your language of choice it's certainly not your place to critique another's choice of language.

As for Apache 2.2.15 - CentOS and RHEL do not update minor versions unless they absolutely have to. Patches are backported. If you happen to spend 30 seconds, you will find that EL6 (and by proxy, CentOS 6.x) provide a stable but patched version of 2.2.15.

[rekabis]

As for Apache 2.2.15 - CentOS and RHEL do not update minor versions unless they absolutely have to. Patches are backported. If you happen to spend 30 seconds, you will find that EL6 (and by proxy, CentOS 6.x) provide a stable but patched version of 2.2.15.

Go into any data centre that does hosting, and you will find that about 98+% of all customers that have simple Linux VMs (and even a large majority on Windows) will not go through the OS to install software and manage the patches -- they will have a Control Panel (such as Plesk or WHM/cPanel) to install the software and manage the patches for them. Keep that up to date, and you’re on 2.2.29 at the very least, and not 2.2.15. It’s only those customers that have fully self-managed VM environments (where you can create VMs at will and dynamically assign resources to VMs on the fly) where they have a more sophisticated setup, and are more unlikely to let a piece of software manage their setup and configuration. But then again, we’re talking about entire school districts and Fortune 500 companies that use that particular product… a fully self-managed VM environment is prohibitively expensive for something like Castanet (prices typically sit in the $2,000/mo range and climb rather quickly from there). Individual VMs that have resources statically assigned are much cheaper and much more common, and those are the ones that typically have control panels.

I’m not saying that Castanet makes use of a control panel. But it would be extremely unusual if they don’t. Unless they have a sysadmin dedicated to *only* server maintenance, a control panel helps relieve a business of a lot of unnecessary overhead and headaches.

Source: I work in a data centre. A big one. The backup generators alone are probably powerful enough to keep the entire city of Kelowna lit for almost 48hrs.

[Captain Awesome]

Ah, I see we're witnessing yet another "I know more techie stuff than you" competition while stroking their own ego.

[rekabis]

Ah, I see we're witnessing yet another "I know more techie stuff than you" competition while stroking their own ego.

No, it’s more an “I am actually on the front lines, and get to see actual real-world usage of servers in data centres” sort of thing, no ego required or desired. I made that last comment so people could see where I was coming from, and that I was speaking from real-word experience rather than just making stuff up as I go along.