The days of building a website as merely a static, informational thing are long past. We’re no longer building websites; we’re building a software product, and it’s extremely important for the values and mission of that product to be understood by those who are actually making it. This is the core of what my session at this year’s NTEN conference, Tell The Developers The Story, is all about—the importance of involving development/technology in all aspects of creating and designing a product, and not as an isolated group.
Get Creative…and Keep Them in the Room
There are a few scenarios involved in how a website is built. You may have an organization that has creative and software development resources; or only a software development team; or only a creative team; or no creative or development resources at all. An organization may rely on external teams to augment their capabilities as a client. Over the many years I’ve been working as a technologist and strategist, I’ve come to see a pattern—regardless of scenario, when the creative team is divorced from implementation, a number of issues often crop up. Organizations, especially nonprofits, should be sensitive to these issues.
Because These Three Issues
One issue is a lack of interaction or functional detail given to the build team; instead, user experience and visual design are punted to the build team without adequate detail. The development team is given designs that may contain a lot of broad information, but they do not go deep enough to capture the design intent or rationale. If the design team isn’t available or is unwilling to provide more detail, the developers often must resort to best guesses, which inevitably causes tension when the work is reviewed by the design team or the client. This is probably one of the biggest reasons for cost and time overruns when building websites.
Another issue that results from this design disconnect can be subtle: while the website build may have gone well and the product is launched, there may be inconsistencies in the presentation, interactions, and overall cohesiveness that add up to a user’s lack of connection with the product, its brand, its mission—a general feeling of inferior quality that may not be an explicit failure, but is noticeable enough to cause problems, especially over time.
There’s also the danger of treating content curators and website administrators as second-class citizens. This issue is a bit broader in that it not only involves the choices developers make, but can involve the ones that strategists and designers make as well. As I’m fond of saying, “Admins are users too.” Too often, administrative interactions and interfaces aren’t well thought out in design; and therefore there are few or no guidelines for developers to ease the burden for content managers.
The bottom line here is that you can produce a far better product if those building it understand its goals and intentions rather than only being handed the plans.
Bringing Tech in Before Build Time
My colleague, the founder and director of strategy at Constructive, Matt Schwartz, is presenting a session at this year’s NTC about the Four Strategic Foundations of Effective Websites. Technology is one of those strategic foundations, and I’ll be adding my thoughts to his session as well as expanding upon them during mine.
Throughout my career, I’ve always been a proponent of making sure that developers and technology are well-represented throughout every phase of a project, not only at build time. This ensures that the right technical decisions are being made that solve the right problems, and provides a balancing voice during the creative phase, constraining things to what’s technically possible and achievable, rather than blowing out costs and time to build the thing that seems simple but is really a technical nightmare. Constraints are good, as they can free you to design and build the right product with the right intention.
The level of developer involvement need not be that deep, but it should be deep enough to lend a good sense of the purpose of a project, the brand, its goals, and its audience. It empowers them to understand the reasoning behind the way certain problems were solved through design—making for a much higher quality implementation where they, as much as anyone else involved, can take ownership and pride in the quality of work they do.
To learn more, catch my session at NTEN. See you there!