And the winner for the most obvious UX statement of the year goes to…

I have a huge amount of respect for the Nielsen/Norman Group, but their latest article seems so obvious that it makes me sad that they have to write it.

Infinite Scrolling is Not for Every Website

Endless scrolling is not recommended for goal-oriented finding tasks, such as those requiring people to locate specific content or compare options. For e-commerce sites, finding products by feature might be difficult to accomplish quickly if all of the products are presented linearly on a never-ending page, without sorting or other filtering or navigation techniques to help isolate the intended item.

Goodbye tablets?

I remember when the iPad first came out, we had landed a huge account at our office and the boss got everyone iPads to celebrate. Everyone was really excited about them, and for the first week there was endless talk about what apps people had downloaded. Some people tried to use them for work, taking them into meetings as a note-taking device, but ultimately switched back to good-old pen and paper.

Within a few weeks most folks stopped using them. The ones who still talked about new apps were largely parents who downloaded games for their children.

Fast forward a few years and tablets are the hottest consumer product of the holiday season. But there seems to be some evidence that this is a short-lived trend. According to this article, rather than a seemingly infinite number of responsive design breakpoints, we’ll soon settle on desktops (which are not going away, despite all of the predictions a few years back) and 5-inch phones.

Developing secure apps

Chris Cornutt over at phpdeveloper.org reminds us that development security isn’t an add-on. I have two fun side-project I want to work on this year, and security is an area where my coding practice can definitely improve.

This is one of those places where I feel working with existing frameworks can be an improvement over my normal “code from the ground up” approach. Not only should an existing framework save time on rote tasks, but hopefully the developers creating various modules and plugins have a better grasp on security practices than I do. Especially the ones who are writing code specifically related to authentication.

Granted, coding for me is a hobby, not a career. I can indulge myself in inefficient practices because I enjoy the art of problem-solving. But if I ever plan to launch my projects and have other people use them, it’s not okay for me to create something that’s not secure and could put my users data at risk.

Games as Art

I mostly talk about websites and apps on this blog, because that’s the industry I work in every day.

One of the somewhat tech-ish blogs I follow is Jeff Vogel, an independent game developer in Seattle who has made a series of RPG-style games for the past two decades or so. Jeff seems like a good guy and there’s a romantic part of me that loves the idea of the one-man game shop in the era of multi-million dollar titles like Call of Duty, Grand Theft Auto, and Madden.

Even though I have very little time for video games and haven’t played a Spiderweb Software (Jeff’s company) game in close to ten years, I still like his blog because it gives me insight into the game design process and talks about the intersection of his corner of the tech industry with our broader society and culture. So, you know, right up my alley.

Anyway, apparently in this world there’s been a raging debate over whether or not video games are or can be classified as “art”. Some controversy was ignighted a few years back when highly respected film/art critic and writer Roger Ebert infamously declared that no matter how good they got, games could never be art.

Jeff has an interesting addition to the video games as art debate, and as always brings some much needed level headed perspective.

Does the fold matter?

Jason Sutton takes on the question of whether or not we still need to design to keep content “above the fold“.

Sadly, the answer seems to be “maybe???”. Certainly lots of vertical scrolling seems to be the new design trend, especially for those in the “mobile-first” camp. But as Jason points out – the most recent usability study on scrolling is from the Bush administration. At this point it seemed as if a quarter of all users still never scrolled down on a web site, and we have no statistical evidence to prove definitively that this has changed.

Marc Ardizzone on UX

My friend and former Embolden colleague Marc Ardizzone has a great blog post up on the basics of user experience.

The piece is titled What is User Experience, And Why Should I Care? It should really be called What Is User Experience, Why Should I Care, and What Can I Do About It?

It’s a good primer aimed at the type of organization that doesn’t have a UX professional on board. I think it’s especially useful for the sort of smaller nonprofit clients we used to serve at Embolden – the ones that had a single beleaguered communications person in charge of everything from managing the website to writing press releases to organizing events.

Designing for large screens

I’m fairly late to the whole large monitor trend. I never got into using my computer as a gaming or entertainment device, and until recently my work life was very PC-focused where multiple smaller monitors are much more common than one large monitor.

However, my new job is a Macbook shop, and large external monitors dot our office. I finally broke down this past weekend and bought a 27 inch external monitor for those days I work from home – it’s infuriatingly inefficient for me to work on a small laptop screen.

I went back and reread this December article from A List Apart on designing for large screens. Although the project manager in me cringes at the potential scope creep, the article is right to point out that three years of responsive design has focused almost entirely on smaller breakpoints for mobile and tablet devices – leaving most websites still maxing out at around 960px.

The Swiss Army Project Manager

Project Manager is one of those job titles that seems to mean completely different things depending on where you work.

The common theme on all project manager job descriptions are vague sounding goals around ensuring quality and staying within budget. But the actual day-to-day activities and skills required for a Project Manager position can vary widely.

I’ve known project managers who were entry level employees in their company essentially tasked with setting meetings and taking notes. I’ve known project managers whose role is the highest level in their company without being a senior manager. I’ve known PMs that manage a team of ‘resources’, and I’ve known PMs who outsource everything to a vendor (who has their own project manager).

Of course, this is all in the context of building websites. Project Management in manufacturing or construction may be different.

However, in the web building world I’ve found the following skills to be essential to good project management:

Own the relationship

For any customer engagement, you’re going to be the main point of contact. You’re the person the client deals with on a day-to-day basis, you’re the one who understands their project better than anybody, and you’re the one who gets to know them as people.

There may be a sales person who brought that client in, and there may be an account manager who meets with them a few times a year and tries to sell them on new services. But regardless of what the org chart and job descriptions say – you are the one who really builds, maintains and owns that relationship.

Everything else you do serves or flows from this essential duty.

Good client relationships are built by establishing trust, communicating clearly, consulting expertly, and building rapport.

Building good relationships makes it easier to:

  • Have input into product decisions
  • Negotiate scope changes and push back on scope creep
  • Get acceptance if you need to adjust the timeline or otherwise give ‘bad news’
  • Win repeat business

Understand your product

There’s a school of thought that you don’t need to understand what you’re managing in order to manage it. You just need to understand proper management techniques.

I wholeheartedly reject that idea when it comes to project management in the web world.

You could make the best Gantt Charts on the planet and be an absolute whiz at budgeting, but if you don’t know the difference between Java and Javascript or understand the fundamentals of responsive design you’re not going to be effective in your role as a web PM.

To be clear, you don’t need to be a programmer or designer. You do need to know enough to:

  • Speak about your product intelligently
  • Offer good advice to your clients
  • Negotiate scope change
  • Help clients understand what will require custom development vs leveraging existing functionality for a much lower cost

Be the main client consultant

At some larger agencies there may be separate people taking on the role of “Business Analyst”, “Technical Analyst” and “Information Architect”. You may even have a UX team that’s separate from the design team.

But at most agencies, one or more of these roles are going to fall to you.

As a PM, you may find yourself doing any of the following as part of your day-to-day job:

  • Help the client shape their marketing messages
  • Show why a certain approach will make their site more usable
  • Create user flow and site map documents
  • Assist with digging into their analytics to inform strategic decisions
  • Prioritize internal feature requests and determine which will give the biggest win for the least effort

Even if your company has people who can handle all of these things for the client, they will not be on every call and in every meeting with you. You can’t answer every question with “let me set up a call with the appropriate resource” and hope to ever get a project over the finish line.

Ultimately, in the real world of web project management you are more often than not the client’s de facto strategist. If you weren’t, they wouldn’t pay you the big bucks.

Communicate clearly

Communicating clearly sounds simple enough, and is probably on every job description for every job in every industry. However, for the web project manager there are specific challenges:

  • You often need to break down complex technical information to an audience made up of non-technical people.
  • You need to translate design feedback from the client into something the designer can actually work with.
  • You need to write requirements so clearly that there is a zero percent chance of the developers building something that is not exactly what the client asked for.

The final one is the most important. The requirements are the one thing you can point to when the client wants a million changes before launch. If they are well written, they will spell out exactly what is being built.

However, vague requirements, or overly technical requirements that the client did not understand will almost always lead to disagreements at the end. These disagreements will end up meaning that you fail on at least one of the three main goals of project management: delivering on time, on budget, and to expectations. Often these disagreements will mean failing on all three counts.

This is why communicating clearly is vital. Ensuring the requirements spell out exactly what you will build, and that the client truly understands what will be built going in to the process. If the client doesn’t understand the requirements or just felt pressured to sign off to meet a deadline, there’s a very good chance that the project will blow up at the end.

Think like a lawyer

Related to communicating clearly above, you need to think like a lawyer when documenting your project.

By this I don’t mean the questionable ethics of refusing to write anything down so there won’t be a paper trail. I’ve worked in environments like that and it always felt uncomfortable to someone who personally prizes honesty.

I mean ensure every implied promise is captured and followed up on. Too often I’ve seen a client ask if something is possible and a resource to honestly answer “yes, this is possible” not understanding that the client now assumes that will be part of the project. As a PM you need to follow up with the client and make sure they know whether or not that request is in scope and do any additional discovery to properly document it.

Just as importantly, you need to be exhaustive in looking through requirements and figuring out where there’s too much gray area that can lead to misunderstandings. Does a Statement of Work say how many mockups and how many rounds of revision the client will get? Does it say where you will be leveraging existing technology so you have the ability to tell the client that custom work will be out of scope? Has any statement about SEO implied an improvement in Google rankings? Have you walked the client through seemingly obvious plugins like comments or donations so you’re on the same page about what functionality is and is not included?

Anything else

You need to be prepared to do anything else required to ensure that your project moves forward. It’s too easy to hit a roadblock and say the project can not proceed.

I once had a job that should have been a slam dunk. I had a project that was already defined and the development work was being done by an outside vendor. My job was just to get a few things signed off, sit through some status meetings and move on to the next thing.

One of the signoffs was from the company’s legal compliance team, and it turned out that a data point we were going to use was not allowable under federal regulations.

As the PM I could have easily said “Okay, that’s that.” Instead, I pushed for six months down every avenue I could to solve this problem. I tried to find ways we could add disclosure that would allow us to use the data in a legal and ethical way. I tried to find a source of data that would pass legal muster. I tried pushing things up the chain to senior management to get involved. I tried to see if we could calculate data in house. I worked with the vendor and design team to try to come up with a version of the tool that did not require this data. Finally after months of negotiations I got a federal agency to agree to allow us to create a new data point that would play the same role as the verboten one, but be different enough to not cause confusion and not run afoul of the regulations.

I am not a lawyer, I am not a statistician, and I was a fairly low-level project manager in the marketing department of one of the largest multinational finance companies in the world. But I got it done just because I refuse to let a project fail and I refuse to accept the idea that a project manager is little more than a recording secretary that helps other people organize their work.

PM Stuff

Finally we get to the traditional “PM Stuff”. The things that most people who aren’t full-time project managers in the industry think our jobs entail.

  • Setting up meetings
  • Taking notes and documenting everything
  • Keeping an eye on the budget and timeline and reporting when they may go over (and asking your developers to work faster)
  • Scheduling resources

As you can see, the duties that are usually written about for PMs – reporting methods, burndown charts and all of that – are but a small fraction of what you’ll actually do on a project.

In the end a PM is not a highly specialized job dependent on expertise in chart-making. It’s a generalist job for a swiss-army-knife type of person. You may not be the best tool for any specific job – you’re not a designer, developer, lawyer or salesperson. But you have to be good enough at all of those things to do in a pinch.