If you know me or my work, you know that I’ve been doing technology research for a very long time. My dissertation was on the effectiveness of the Internet for training, which turned out to be a silly question to ask. I started my first job at Old Dominion University studying “multiuser virtual environments,” which was at the time referred to as “the metaverse,” a detail largely forgotten by the time Mark Zuckerberg renamed his company. Over the years since, I’ve studied a wide variety of technologies blending theory and approaches from our field and human–computer interaction, with a particularly visible ongoing stint on games and gamification, particularly in pre-employment assessment. Most recently, we’ve built an AI leadership coaching platform for the United States Naval Academy.
Given all that, it probably should not have been a surprise to me that so many people assumed that if any SIOP president were going to fix the website, it would be me. Challenge accepted!
The SIOP website has a long history of being slightly dysfunctional. Like many aspects of SIOP that the Executive Board has been working to change over the last few years, it is largely an artifact of the way that SIOP was founded and has evolved since that founding. In the early days of SIOP’s website, like many organizations of that time period, it was simply a way to share information among members, as you can see in Figure 1. SIOP itself was at the time mostly a means to organize the annual conference, publish TIP, push out a few industry-facing papers, and not much else. Later, as SIOP’s purview widened, account management, online conference submissions, promotion of our science to Congress, and many other functions were bolted onto the underlying infrastructure. The mentality at the time was that these were member needs that needed to be addressed, so, therefore, the staff should add whatever functionality the volunteers and members asked for, assuming it was technically possible.
Figure 1

The SIOP Homepage as of July 3, 1999
This is the earliest capture available on the Internet archive. If you click through to the Student Affiliate Application, you will find a place where you can print the page to mail it to Ohio, enclosing your check for $10 in annual dues.
The problem with that approach, we now know, is that it is haphazard by design. Due to no fault of our staff, perhaps other than underestimating just how complex and demanding SIOP would eventually become, we ended up with Dr. Frankenstein’s website. And a big problem with a website that serves many different purposes is that it usually doesn’t end up serving any of them particularly well. On top of the limited attention that can be paid to any one piece of the website by our small staff, it also creates a complex spider web of stakeholders. Every committee had their own personal area that they wanted to maintain to their own standards, yet every 2 years, when committee leadership changed, the website might suddenly be forgotten or reinvented by the new chair. This situation occurred with great regularity over the past couple of decades, and staff have long been reluctant to tell enthusiastic volunteers “no.”
This is, in many ways, a great problem to have. SIOP is so popular and its content in such demand that it is overwhelming to keep its website organized and in service to all the people who want to see it. Unlike many volunteer organizations currently struggling to build or maintain volunteer enthusiasm, we have an abundance of interest in providing resources to our community. That is something that most scientific and professional communities aspire to. Our problem, instead, is to make that content useful through better organization and presentation. Our problem is user experience.
You may think of User eXperience, or UX, as a sort of buzzword meaning “a good website.” I am here to tell you today that the problem is dramatically more complicated than that. You should think of a website as a set of distinct components, each requiring different expertise to build, evaluate, and own. The front end is what users like you see, including its structure, visuals, interaction design, responsiveness, and content. The back end is the engine that delivers the front end, including database, server management, and network architecture. Between them sits the application layer, which refers to the actual functionality that makes the interactive features work (e.g., our election software needs to “talk to” the member database) and the integrations that connect to outside services. Cutting across all of this are concerns like security, performance, and accessibility, plus the work surrounding the build itself, which are things like content strategy, project management, testing, and ongoing maintenance.
Put another way, the website is a 15+ dimensional problem, and each dimension is both managed and understood by its own local experts. Even within dimensions, expertise is often split; for example, structure is both an application-level problem (How will users find their way around?) and a front-end-level problem (What should happen when someone clicks on a menu?), which require different expertise. Companies, or individual experts, often bring expertise across a dozen or so subdomains of website management, but very few people or companies have expertise across all of them. If they do have all that expertise, they are very expensive, which makes them a poor choice for a nonprofit, dues-driven organization like ours!
Due to this complexity, SIOP has tackled “fixing the website” a piece at a time for several years now. The biggest but perhaps least visible piece was the back end. If you used the website around 5 years ago, in its last incarnation, you probably experienced a few problems with the back end. Occasionally, the site would freeze and choose not to load. The conference submission website would get bogged down and crash. As a result, we changed back-end providers. The problem that created is that when you change back ends, the entire front end and application layer need to be reinvented from the ground up because both the front end and applications are installed on top of the back end. For cash flow reasons, and because it carried the more fundamental problems, we invested heavily in the back end and relatively little in the new front end and application layer, leaving them as problems for later.
That decision created the experience you are now having with our website. From a technical perspective, it is dramatically better. The site doesn’t crash randomly! Data are not lost for no apparent reason! These are amazing gains. But they are also mostly invisible gains. I think of it a lot like hearing that a house you’re considering buying has a new roof. “I’m pleased to hear the house has a functional roof, but that’s really a minimum, more so than a benefit!”
That brings us to today. The Executive Board is now turning its attention to those other components: the front end and the application layer. Over July and August, we worked with a user experience consultant to conduct a 5-part, 10-hour series of workshops to develop a website strategic plan, targeting the highest priority (i.e., most frustrating) aspects of the website, identifying owners of those issues, and developing a workable timeline to address them. This involved the Presidential Trio, the entire Executive Board, several committee chairs, and about a third of our staff. The goal was to create a plan that we can execute over the next 2–3 years that will lead to progressive improvements on the website in a format that will live beyond the particular goals of a particular president or board.
Some of the front-end issues with the website are very obvious when your attention is called to them. For example, the website has a bug where scrolling down from the top causes the page to jump forward about 10 lines. On desktop, that feature helpfully scrolls past the title and top image so that you can get to the content faster. On mobile, it makes it impossible to read the first item because it will skip past that item when scrolling in both directions. This is also the kind of bug that seems simple to fix (“Don’t jump when scrolling!”) but requires many dozens of hours of diagnosis to track down the specific, technical cause and the best solution unlikely to break other parts of the website. And there are myriad bugs like this one that need to be sorted and prioritized.
A key change in perspective for the Board was the very purpose of the website. The historic view that the website was simply a place to deliver information to SIOP members was holding us back. A more modern view, the one we embrace now, is that the website is the face of the organization. Although SIOP does a lot to support our community, much of it is undercut if our public face does not do it justice. To the people using the SIOP website, it is a representation of SIOP itself. That’s a big mindset shift for a room full of psychologists. But we’re on the path now.
I can’t promise that the website will be fixed overnight. Our website’s current user experience is at least a several-year problem, just to patch the roof, and even then, it’s a problem that is never truly solved. You can’t fix your face and assume it will stay fixed forever. But that’s precisely why we’ve moved it to the center of our organizational priorities and why it will stay there.
Volume
64
Number
2
Author
Richard Landers, University of Minnesota
Topic
Technological Changes