Оценка на читателите: / 9
Слаба статияОтлична статия 

Новини от света на уеб дизайна и СЕО

Представям Ви синдикирани новини от няколко от водещите сайтове в областта на уеб дизайна и СЕО - оптимизирането за търсачки.

A List Apart: The Full Feed
Articles for people who make web sites.
  • The Future of Web Software Is HTML-over-WebSockets

    The future of web-based software architectures is already taking form, and this time it’s server-rendered (again). Papa’s got a brand new bag: HTML-over-WebSockets and broadcast everything all the time.

    The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.

    But a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place. All of this sets us up for a considerably easier (and faster!) development path. 

    Reclaiming all of that time spent addressing architecture difficulties grants you a pool of surplus hours that you can use to do awesome. Spend your dev budget, and your company’s salary budget, happily building full-stack features yourself, and innovating on things that benefit your company and customers. 

    And in my opinion, there’s no better app framework for reclaiming tedious development time than Ruby on Rails. Take another look at the underappreciated Stimulus. Beef up the View in your MVC with ViewComponents. Add in the CableReady and StimulusReflex libraries for that Reactive Rails (as it has been dubbed) new car smell, and you’re off to the races. But we’ll get back to Rails in a bit...

    This all started with web frameworks...

    Web frameworks burst onto the scene around 2005 amidst a sea of mostly figure-it-out-for-yourself scripting language libraries glued together and thrown onto hand-maintained Apache servers. This new architecture promised developers a more holistic approach that wrapped up all the fiddly stuff in no-touch conventions, freeing developers to focus on programming ergonomics, code readability, and fast-to-market features. All a developer had to do was learn the framework’s core language, get up to speed on the framework itself and its conventions, and then start churning out sophisticated web apps while their friends were still writing XML configuration files for all those other approaches.

    Despite the early criticisms that always plague new approaches, these server-rendered frameworks became tools of choice, especially for fast-moving startups—strapped for resources—that needed an attractive, feature-rich app up yesterday.

    But then the JavaScript everything notion took hold...

    As the web development world pushed deeper into the 2010s, the tides began to turn, and server-rendered frameworks took something of a backseat to the Single Page Application, wholly built in JavaScript and run entirely on the client’s computer. At many companies, the “server” became relegated to hosting an API data service only, with most of the business logic and all of the HTML rendering happening on the client, courtesy of the big ’ol package of JavaScript that visitors were forced to download when they first hit the site. 

    This is where things started to get ugly.

    Fast-forward to 2020 and the web isn’t getting any faster, as we were promised it would with SPAs. Shoving megabytes of JavaScript down an iPhone 4’s throat doesn’t make for a great user experience. And if you thought building a professional web app took serious resources, what about building a web app and an API service and a communication layer between them? Do we really believe that every one of our users is going to have a device capable of digesting 100 kB of JSON and rendering a complicated HTML table faster than a server-side app could on even a mid-grade server?

    Developing and hosting these JavaScript-forward apps didn’t get any cheaper either. In many cases we’re now doing twice the work, and maybe even paying twice the developers, to achieve the same results we had before with server-side app development.

    In 2005, app frameworks blew everyone’s minds with “build a blog app in 15 minutes” videos. Fifteen years later, doing the same thing with an SPA approach can require two codebases, a JSON serialization layer, and dozens of spinners all over the place so we can still claim a 50ms First Contentful Paint. Meanwhile, the user watches some blank gray boxes, hoping for HTML to finally render from all the JSON their browser is requesting and digesting. 

    How did we get here? This is not my beautiful house! Were we smart in giving up all of that server-rendered developer happiness and doubling down on staff and the time to implement in order to chase the promise of providing our users some fancier user interfaces?

    Well. Yes. Sort of.

    We’re not building web software for us. We’re building it for them. The users of our software have expectations of how it’s going to work for them. We have to meet them where they are. Our users are no longer excited about full-page refreshes and ugly Rube Goldberg-ian multi-form workflows. The SPA approach was the next logical leap from piles of unorganized spaghetti JavaScript living on the server. The problem, though: it was a 5% improvement, not a 500% improvement. 

    Is 5% better worth twice the work? What about the developer cost?

    Bedazzling the web app certainly makes things fancier from the user’s perspective. Done well, it can make the app feel slicker and more interactive, and it opens up a wealth of new non-native interaction elements. Canonizing those elements as components was the next natural evolution. Gone are the days of thinking through how an entire HTML document could be mutated to give the illusion of the user interacting with an atomic widget on the page—now, that can be implemented directly, and we can think about our UX in terms of component breakdowns. But, alas, the costs begin to bite us almost immediately.

    Go ahead, write that slick little rating stars component. Add some cool animations, make the mouseover and click area feel good, give some endorphin-generating feedback when a selection is made. But now what? In a real app, we need to persist that change, right? The database has to be changed to reflect this new state, and the app in front of the user’s eyes needs to reflect that new reality too. 

    In the old days, we’d give the user a couple star GIFs, each a link that hit the same server endpoint with a different param value. Server-side, we’d save that change to the database, then send back a whole new HTML page for their browser to re-render; maybe we’d even get fancy and use AJAX to do it behind the scenes, obviating the need for the full HTML and render. Let’s say the former costs x in developer time and salary (and we won’t even talk about lost opportunity cost for features rolled out too late for the market). In that case, the fancy AJAX-based approach costs x + n (you know, some “extra JavaScript sprinkles”), but the cost of lots and lots of n grows as our app becomes more and more of a JavaScript spaghetti sprinkles mess.

    Over in the SPA world, we’re now writing JavaScript in the client-side app and using JSX or Handlebars templates to render the component, then code to persist that change to the front-end data store, then a PUT request to the API, where we’re also writing an API endpoint to handle the request, a JSON serializer (probably with its own pseudo-template) to package up our successful response, and then front-end code to ensure we re-render the component (and some branching logic to maybe rollback and re-render the client-side state change if the backend failed on us). This costs a lot more than even x + n in developer time and salary. And if you’ve split your team into “front-end” and “back-end” people, you might as well go ahead and double that cost (both time and money) for many non-trivial components where you need two different people to finish the implementation. Sure, the SPA mitigates some of the ever-growing spaghetti problem, but at what cost for a business racing to be relevant in the market or get something important out to the people who need it?

    One of the other arguments we hear in support of the SPA is the reduction in cost of cyber infrastructure. As if pushing that hosting burden onto the client (without their consent, for the most part, but that’s another topic) is somehow saving us on our cloud bills. But that’s ridiculous. For any non-trivial application, you’re still paying for a server to host the API and maybe another for the database, not to mention load balancers, DNS, etc. And here’s the thing: none of that cost even comes close to what a software company pays its developers! Seriously, think about it. I’ve yet to work at any business where our technical infrastructure was anything more than a fraction of our salary overhead. And good developers expect raises. Cloud servers generally just get cheaper over time.

    If you want to be efficient with your money—especially as a cash-strapped startup—you don’t need to cheap out on cloud servers; you need to get more features faster out of your existing high-performance team.

    In the old, old days, before the web frameworks, you’d pay a developer for six weeks to finally unveil…the log-in page. Cue the sad trombone. Then frameworks made that log-in page an hour of work, total, and people were launching web startups overnight. The trumpets sound! Now, with our SPA approach, we’re back to a bunch of extra work. It’s costing us more money because we’re writing two apps at once. There’s that trombone again...

    We’re paying a lot of money for that 5% user experience improvement.

    But what if we could take the best client-side JavaScript ideas and libraries from that 5% improvement and reconnect them with the developer ergonomics and salary savings of a single codebase? What if components and organized JavaScript could all live in one rock-solid app framework optimized for server-side rendering? What if there is a path to a 500% jump?

    Sound impossible? It’s not. I’ve seen it, like C-beams glittering in the dark near the Tannhäuser Gate. I’ve built that 500% app, in my free time, with my kids running around behind me barking like dogs. Push broadcasts to logged-in users. Instant updates to the client-side DOM in milliseconds. JavaScript-driven 3D animations that interact with real-time chat windows. All in a single codebase, running on the same server hardware I’d use for a “classic” server-rendered app (and maybe I can even scale that hardware down since I’m rendering HTML fragments more often than full-page documents). No separate front-end app. Clean, componentized JavaScript and server-side code, married like peanut butter and jelly. It’s real, I tell you!

    Socket to me! (Get it? Get it? Ah, nevermind...)

    Finalized in 2011, support for WebSockets in modern browsers ramped up throughout the 2010s and is now fully supported in all modern browsers. With the help of a small bit of client-side JavaScript, you get a full-duplex socket connection between browser and server. Data can pass both ways, and can be pushed from either side at any time, no user-initiated request needed.

    Like the game industry’s ever-expanding moves into cloud-based gaming, the future of web apps is not going to be about pushing even heavier obligations onto the user/client, but rather the opposite: let the client act as a thin terminal that renders the state of things for the human. WebSockets provide the communication layer, seamless and fast; a direct shot from the server to the human.

    But this wasn’t terribly easy for many developers to grok at first. I sure didn’t. And the benefits weren’t exactly clear either. After years (decades, even) of wrapping our heads around the HTTP request cycle, to which all server-handled features must conform, adopting this WebSocket tech layer required a lot of head scratching. As with many clever new technologies or protocols, we needed a higher-level abstraction that provided something really effective for getting a new feature in front of a user, fast.

    Enter HTML-over-WebSockets...

    Want a hyper-responsive datalist typeahead that is perfectly synced with the database? On every keystroke, send a query down the WebSocket and get back precisely the changed set of option tags, nothing more, nothing less.

    How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket. Let your server framework validate and send back changes to the HTML of the form, including any errors that need to be rendered. No need for JSON or complicated error objects.

    User presence indicators? Dead simple. Just check who has an active socket connection.

    What about multi-user chat? Or document collaboration? In classic frameworks and SPAs, these are the features we put off because of their difficulty and the code acrobatics needed to keep everyone’s states aligned. With HTML-over-the-wire, we’re just pushing tiny bits of HTML based on one user’s changes to every other user currently subscribed to the channel. They’ll see exactly the same thing as if they hit refresh and asked the server for the entire HTML page anew. And you can get those bits to every user in under 30ms.

    We’re not throwing away the promise of components either. Where this WebSockets-based approach can be seen as a thick server/thin client, so too can our components. It’s fractal, baby! Make that component do delightful things for the user with smart JavaScript, and then just ask the server for updated HTML, and mutate the DOM. No need for a client-side data store to manage the component’s state since it’ll render itself to look exactly like what the server knows it should look like now. The HTML comes from the server, so no need for JSX or Handlebars or <insert other JavaScript templating library here>. The server is always in control: rendering the initial component’s appearance and updating it in response to any state change, all through the socket. 

    And there’s nothing saying you have to use those socket channels to send only HTML. Send a tiny bit of text, and have the client do something smart. Send a chat message from one user to every other user, and have their individual clients render that message in whatever app theme they’re currently using. Imagine the possibilities!

    But it’s complex/expensive/requires a bunch of new infrastructure, right?

    Nope. Prominent open-source web servers support it natively, generally without needing any kind of extra configuration or setup. Many server-side frameworks will automatically ship the JS code to the client for native support in communicating over the socket. In Rails, for example, setting up your app to use WebSockets is as easy as configuring the built-in ActionCable and then deploying as usual on the same hardware you would have used otherwise. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. Again, this is on the usual hardware you’d be running your web server on in the first place. You don’t need to set up any extra hardware or increase your cloud infrastructure.

    This new approach is quickly appearing as extensions, libraries, or alternative configurations in a variety of languages and web frameworks, from Django’s Sockpuppet to Phoenix’s LiveView and beyond. Seriously, go dig around for WebSockets-based libraries for your favorite app framework and then step into a new way of thinking about your app architectures. Build something amazing and marvel at the glorious HTML bits zipping along on the socket, like jet fighters passing in the night. It’s more than a new technical approach; it’s a new mindset, and maybe even a new wellspring of key app features that will drive your startup success.

    But I’d be remiss if I didn’t highlight for the reader my contender for Best Framework in a Leading Role. Sure, any app framework can adopt this approach, but for my money, there’s a strong case to be made that the vanguard could be Ruby on Rails. 

    So we come back around to Rails, 15 years on from its launch...

    Set up a Rails 6 app with the latest versions of Turbolinks, Stimulus, StimulusReflex, CableReady, and GitHub’s ViewComponent gem, and you can be working with Reactive Rails in a way that simultaneously feels like building a classic Rails app and like building a modern, componentized SPA, in a single codebase, with all the benefits of server-side rendering, HTML fragment caching, easy SEO, rock-solid security, and the like. You’ll suddenly find your toolbelt bursting with straightforward tools to solve previously daunting challenges.

    Oh, and with Turbolinks, you also get wrappers allowing for hybrid native/HTML UIs in the same codebase. Use a quick deploy solution like Heroku or Hatchbox, and one developer can build a responsive, reactive, multi-platform app in their spare time. Just see this Twitter clone if you don’t believe me. 

    OK, that all sounds exciting, but why Rails specifically? Isn’t it old and boring? You already said any framework can benefit from this new WebSocket, DOM-morphing approach, right? 

    Sure. But where Rails has always shined is in its ability to make rapid prototyping, well…rapid, and in its deep ecosystem of well-polished gems. Rails also hasn’t stopped pushing the envelope forward, with the latest version 6.1.3 of the framework boasting a ton of cool features. 

    If you’ve got a small, resource-strapped team, Rails (and Ruby outside of the framework) still serves as a potent force multiplier that lets you punch way above your weight, which probably explains the $92 billion in revenue it’s helped drive over the years. With this new approach, there’s a ton more weight behind that punch. While your competitors are fiddling with their JSON serializers and struggling to optimize away all the loading spinners, you’re rolling out a new multi-user collaborative feature every week…or every day

    You win. Your fellow developers win. Your business wins. And, most importantly, your users win.

    That’s what Rails promised from the day it was released to the community. That’s why Rails spawned so many imitators in other languages, and why it saw such explosive growth in the startup world for years. And that same old rapid prototyping spirit, married to this new HTML-over-the-wire approach, positions Rails for a powerful resurgence. 

    Ruby luminary and author of The Ruby Way, Obie Fernandez, seems to think so.

    Heck, even Russ Hanneman thinks this approach with StimulusReflex is the new hotness.

    And the good folks over at Basecamp (creators of Rails in the first place), dropped their own take on the concept, Hotwire, just in time for the 2020 holidays, so your options for tackling this new and exciting technique continue to expand.

    Don’t call it a comeback, because Rails has been here for years. With this new architectural approach, brimming with HTML-over-WebSockets and full-duplex JavaScript interactions, Rails becomes something new, something beautiful, something that demands attention (again). 

    Reactive Rails, with StimulusReflex and friends, is a must-look for anyone exhausted from toiling with JSON endpoints or JSX, and I’m super excited to see the new crop of apps that it enables.

  • Designing Inclusive Content Models

    In the 1920s, Robert Moses designed a system of parkways surrounding New York City. His designs, which included overpasses too low for public buses, have become an often-cited example of exclusionary design and are argued by biographer Robert A. Caro to represent a purposeful barrier between the city’s Black and Puerto Rican residents and nearby beaches. 

    Regardless of the details of Moses’s parkway project, it’s a particularly memorable reminder of the political power of design and the ways that choices can exclude various groups based on abilities and resources. The growing interest in inclusive design highlights questions of who can participate, and in relation to the web, this has often meant a focus on accessibility and user experience, as well as on questions related to team diversity and governance. 

    But principles of inclusive design should also play a role early in the design and development process, during content modeling. Modeling defines what content objects consist of and, by extension, who will be able to create them. So if web professionals are interested in inclusion, we need to go beyond asking who can access content and also think about how the design of content can install barriers that make it difficult for some people to participate in creation. 

    Currently, content models are primarily seen as mirrors that reflect inherent structures in the world. But if the world is biased or exclusionary, this means our content models will be too. Instead, we need to approach content modeling as an opportunity to filter out harmful structures and create systems in which more people can participate in making the web. Content models designed for inclusivity welcome a variety of voices and can ultimately increase products’ diversity and reach.

    Content models as mirrors

    Content models are tools for describing the objects that will make up a project, their attributes, and the possible relations between them. A content model for an art museum, for example, would typically describe, among other things, artists (including attributes such as name, nationality, and perhaps styles or schools), and artists could then be associated with artworks, exhibitions, etc. (The content model would also likely include objects like blog posts, but in this article we’re interested in how we model and represent objects that are “out there” in the real world, rather than content objects like articles and quizzes that live natively on websites and in apps.)

    The common wisdom when designing content models is to go out and research the project’s subject domain by talking with subject matter experts and project stakeholders. As Mike Atherton and Carrie Hane describe the process in Designing Connected Content, talking with the people who know the most about a subject domain (like art in the museum example above) helps to reveal an “inherent” structure, and discovering or revealing that structure ensures that your content is complete and comprehensible.

    Additional research might go on to investigate how a project’s end users understand a domain, but Atherton and Hane describe this stage as mostly about terminology and level of detail. End users might use a different word than experts do or care less about the nuanced distinctions between Fauvism and neo-Expressionism, but ultimately, everybody is talking about the same thing. A good content model is just a mirror that reflects the structure you find.  

    Cracks in the mirrors

    The mirror approach works well in many cases, but there are times when the structures that subject matter experts perceive as inherent are actually the products of biased systems that quietly exclude. Like machine learning algorithms trained on past school admissions or hiring decisions, existing structures tend to work for some people and harm others. Rather than recreating these structures, content modelers should consider ways to improve them. 

    A basic example is LinkedIn’s choice to require users to specify a company when creating a new work experience. Modeling experience in this way is obvious to HR managers, recruiters, and most people who participate in conventional career paths, but it assumes that valuable experience is only obtained through companies, and could potentially discourage people from entering other types of experiences that would allow them to represent alternative career paths and shape their own stories.

    Figure 1. LinkedIn’s current model for experience includes Company as a required attribute.

    These kinds of mismatches between required content attributes and people’s experiences either create explicit barriers (“I can’t participate because I don’t know how to fill in this field”) or increase the labor required to participate (“It’s not obvious what I should put here, so I’ll have to spend time thinking of a workaround”). 

    Setting as optional fields that might not apply to everyone is one inclusive solution, as is increasing the available options for responses requiring a selection. However, while gender-inclusive choices provide an inclusive way to handle form inputs, it’s also worth considering when business objectives would be met just as well by providing open text inputs that allow users to describe themselves in their own terms. 

    Instead of LinkedIn’s highly prescribed content, for example, Twitter bios’ lack of structure lets people describe themselves in more inclusive ways. Some people use the space to list formal credentials, while others provide alternate forms of identification (e.g., mother, cyclist, or coffee enthusiast) or jokes. Because the content is unstructured, there are fewer expectations about its use, taking pressure off those who don’t have formal credentials and giving more flexibility to those who do. 

    Browsing the Twitter bios of designers, for example, reveals a range of identification strategies, from listing credentials and affiliations to providing broad descriptions. 

    Figure 2. Veerle Pieters’s Twitter bio uses credentials, affiliations, and personal interests. 
    Figure 3. Jason Santa Maria’s Twitter bio uses a broad description. 
    Figure 4. Erik Spiekermann’s Twitter bio uses a single word.

    In addition to considering where structured content might exclude, content modelers should also consider how length guidelines can implicitly create barriers for content creators. In the following section, we look at a project in which we chose to reduce the length of contributor bios as a way to ensure that our content model didn’t leave anyone out. 

    Live in America

    Live in America is a performing arts festival scheduled to take place in October 2021 in Bentonville, Arkansas. The goal of the project is to survey the diversity of live performance from across the United States, its territories, and Mexico, and bring together groups of artists that represent distinct local traditions. Groups of performers will come from Alabama, Las Vegas, Detroit, and the border city of El PasoJuárez. Indigineous performers from Albuquerque are scheduled to put on a queer powwow. Performers from Puerto Rico will organize a cabaret. 

    An important part of the festival’s mission is that many of the performers involved aren’t integrated into the world of large art institutions, with their substantial fiscal resources and social connections. Indeed, the project’s purpose is to locate and showcase examples of live performance that fly under curators’ radars and that, as a result of their lack of exposure, reveal what makes different communities truly unique. 

    As we began to think about content modeling for the festival’s website, these goals had two immediate consequences:

    First, the idea of exploring the subject domain of live performance doesn’t exactly work for this project because the experts we might have approached would have told us about a version of the performing arts world that festival organizers were specifically trying to avoid. Experts’ mental models of performers, for example, might include attributes like residencies, fellowships and grants, curricula vitae and awards, artist statements and long, detailed bios. All of these attributes might be perceived as inherent or natural within one, homogenous community—but outside that community they’re not only a sign of misalignment, they represent barriers to participation.

    Second, the purposeful diversity of festival participants meant that locating a shared mental model wasn’t the goal. Festival organizers want to preserve the diversity of the communities involved, not bring them all together or show how they’re the same. It’s important that people in Las Vegas think about performance differently than people in Alabama and that they structure their projects and working relationships in distinct ways. 

    Content modeling for Live in America involved defining what a community is, what a project is, and how these are related. But one of the most interesting challenges we faced was how to model a person—what attributes would stand in for the people that would make the event possible. 

    It was important that we model participants in a way that preserved and highlighted diversity and also in a way that included everyone—that let everyone take part in their own way and that didn’t overburden some people or ask them to experience undue anxiety or perform extra work to make themselves fit within a model of performance that didn’t match their own. 

    Designing an inclusive content model for Live in America meant thinking hard about what a bio would look like. Some participants come from the institutionalized art world, where bios are long and detailed and often engage in intricate and esoteric forms of credentialing. Other participants create art but don’t have the same resources. Others are just people who were chosen to speak for and about their communities: writers, chefs, teachers, and musicians. 

    The point of the project is to highlight both performance that has not been recognized and the people who have not been recognized for making it. Asking for a written form that has historically been built around institutional recognition would only highlight the hierarchies that festival organizers want to leave behind.

    The first time we brought up the idea of limiting bios to five words, our immediate response was, “Can we get away with that?” Would some artists balk at not being allowed the space to list their awards? It’s a ridiculously simple idea, but it also gets at the heart of content modeling: what are the things and how do we describe them? What are the formats and limitations that we put on the content that would be submitted to us? What are we asking of the people who will write the content? How can we configure the rules so that everyone can participate?

    Five-word bios place everyone on the same ground. They ask everyone to create something new but also manageable. They’re comparable. They set well-known artists next to small-town poets, and let them play together. They let in diverse languages, but keep out the historical structures that set people apart. They’re also fun:

    • Byron F. Aspaas of Albuquerque is “Diné. Táchii'nii nishłį́ Tódichii'nii bashishchiin.”
    • Danny R.W. Baskin of Northwest Arkansas is “Baroque AF but eating well.”
    • Brandi Dobney of New Orleans is “Small boobs, big dreams.”
    • Imani Mixon of Detroit is “best dresser, dream catcher, storyteller.”
    • Erika P. Rodríguez of Puerto Rico is “Anti-Colonialist Photographer. Caribeña. ♡ Ice Cream.”
    • David Dorado Romo of El PasoJuárez is “Fonterizo historian wordsmith saxophonist glossolalian.”
    • Mikayla Whitmore of Las Vegas is “hold the mayo, thank you.”
    • Mary Zeno of Alabama is “a down home folk poet.”

    Modeling for inclusion

    We tend to think of inclusive design in terms of removing barriers to access, but content modeling also has an important role to play in ensuring that the web is a place where there are fewer barriers to creating content, especially for people with diverse and underrepresented backgrounds. This might involve rethinking the use of structured content or asking how length guidelines might create burdens for some people. But regardless of the tactics, designing inclusive content models begins by acknowledging the political work that these models perform and asking whom they include or exclude from participation. 

    All modeling is, after all, the creation of a world. Modelers establish what things exist and how they relate to each other. They make some things impossible and others so difficult that they might as well be. They let some people in and keep others out. Like overpasses that prevent public buses from reaching the beach, exclusionary models can quietly shape the landscape of the web, exacerbating the existing lack of diversity and making it harder for those who are already underrepresented to gain entry.

    As discussions of inclusive design continue to gain momentum, content modeling should play a role precisely because of the world-building that is core to the process. If we’re building worlds, we should build worlds that let in as many people as possible. To do this, our discussions of content modeling need to include an expanded range of metaphors that go beyond just mirroring what we find in the world. We should also, when needed, filter out structures that are harmful or exclusionary. We should create spaces that ask the same of everyone and that use the generativity of everyone’s responses to create web products that emerge out of more diverse voices.

  • The Never-Ending Job of Selling Design Systems

    I’m willing to bet that you probably didn’t start your web career because you wanted to be a politician or a salesperson. But here’s the cold, hard truth, friend: if you want to work on design systems, you don’t have a choice. Someone has to pay for your time, and that means someone has to sell what you do to an audience that speaks value in an entirely different language. 

    It’s not exactly easy to connect the benefits of a design system directly to revenue. With an ecomm site, you can add a feature and measure the impact. With other conversion-based digital experiences, if your work is good, your customers will convert more. But because a design system is (usually) an internal tool, it’s just harder to connect those dots. 

    This article boils down the methods I’ve put into practice convincing executives not just to fund the initial push of design system work, but to keep funding it. I’ll share how I’ve adjusted the language I use to describe common design system benefits, allowing me to more clearly communicate with decision makers.

    Know your audience

    In my experience, design systems can be owned by information technology teams, marketing and communications departments, or (best case scenario) cross-disciplinary teams that bring many specialists together. The first thing you need to do is determine where the system lives, as in which department owns and cares for it. 

    If it’s part of IT, for example, you need to think like a CIO or an IT Director and speak to their objectives and values. These leaders are typically more internally focused; they’ll filter the value of the design system in terms of the employees of the company. In contrast, if the system belongs to Marketing, put on your CMO or Marketing Director hat. Marketing teams are often externally focused; they think in terms of B2B audiences and end users. 

    The way organizations structure the ownership of a design system can be more complex, but let’s use these two paths (internal vs external) as frameworks for building a persuasive case for those owners.

    Internal-orientation motivators

    Based on the research we’ve done since 2018, there are three very specific internal motivators for having a design system:

    • Efficiency
    • Onboarding
    • Scale.

    Efficiency benefit

    Design systems allow for the rapid prototyping of new ideas using existing, production-ready components. They allow teams to reuse design and code, and they allow individuals to focus their creative energy on new problems instead of wasting it on old ones. Executives and decision-makers may abstractly understand all that, but you need to be able to tell them what it will take to realize the efficiency benefit. 

    There’s a theoretical maximum to how productive a team can be. When you talk about a design system creating more efficiency in your processes, you’re really talking about raising the ceiling on that max. As happens with so many things in life, though, that comes with a trade-off. Early on, while a team is actually building the system, they won’t be as productive on the rest of their work.

    The efficiency curve looks like this:

    The Design System Efficiency Curve. Line graph illustrating the curvilinear relationship of productivity over time in terms of overall efficiency, in situations of transition from having no design system in place through in-process set up of the system, to eventually having an established design system. Productivity is represented on the y-axis and Time on the x-axis. Starting at 0,0 productivity dips down as the team diverts resources to set up the system, but eventually surpasses standard productivity once the system is in place.
    Figure 1. With Productivity on the y-axis and Time on the x-axis, the Design System Efficiency Curve dips down at the start as the team ramps up on the system, but eventually surpasses standard productivity once the system is in place.

    If you’re talking to an executive, it’s important to acknowledge this dip in productivity. 

    Spend some time working out these specific calculations for your organization. For example, you might need four team members for three months to reach a point where the system will save everyone on the team approximately two hours per week. You’re candidly acknowledging the necessary investment while demonstrating the eventual benefits. And make sure to mention that the productivity benefits will continue indefinitely! The math will almost always end up on your side. 

    Another critical point to raise is that simply having a design system has a cumulative effect on the efficiency of your teams. Since the system is an internal tool that can be used 1) across multiple products or experiences, 2) by many teams throughout the organization, and 3) in many phases of the product design and development process, you are gaining efficiencies on many levels. 

    The team working on in-store kiosks can build their interface with a well-tested set of components. Your UX people can use the system to prototype and test with production-ready code. The people responsible for grooming the backlog know there is a stable pattern library upon which they are building new features or fixing old ones. Anyone looking for answers to what, why, or how your organization designs and builds products will find those answers in the living system.

    The efficiency at each of these (and many other) decision points is how we can raise the ceiling on our total possible efficiency. How this plays out is very different in each organization. I’m here to tell you that part of the work is thinking about how a design system will impact every part of your process—not just design or development.

    What to measure

    Action: Measure the cost of productivity with and without a design system.

    If you aren’t already, start measuring how productive your team is now. The easiest way to do this is to break your team’s work down into measurable cycles. Once you have a rough idea of how much you can get done in a cycle of work, you’ll be able to compare your efficiency before the system was in place with your efficiency after. This kind of measurable benefit will speak volumes to your executive team.

    Onboarding benefits

    Growth is expensive. When you hire a new team member, you don’t just supply a salary and benefits. You need a computer, a desk, a chair, accounts to all the software/services…the list goes on. And all these expenses hit before your new employee is a fully contributing member of the team. You won’t start to recoup your investment for a few months, at least. 

    Design systems can reduce the time it takes your new hire to become a productive contributor. Once you have a healthy design system in place, you’re able to provide an employee with a clearly-defined and effective toolset that is well-documented and can be applied across multiple initiatives. More specifically, assigning new hires to start out working on the design system team will allow them to quickly learn how your organization designs and builds digital products.

    Onboarding Model. Diagram illustrating the movement and eventual cycling (depicted by arrows pointing to the right) of individuals in a "Hiring Pool"(represented by a cluster of dots on the left of the graphic) into the DS Team (design system team), represented by a diamond shape in the center of the graphic, then exiting the DS Team to join Other Teams (smaller diamond shapes on the right of the graphic), and finally, back into the DS Team (dashed-line arrow looping below and to the left, back into the DS Team diamond shape).
    Figure 2. A Model for Onboarding. As you bring people into your organization from your hiring pool, consider having them start on your design system team and then rotate out onto other teams. As you grow, folks who haven’t had a turn on the system team can rotate in as well.

    On the left in Fig. 2, you have a pool of potential employees. As you hire individuals, you can bring them into the design system team, where they’ll gain a deep understanding of how your organization builds digital products. Once they’re up to speed, you can seamlessly move them to another product, discipline, or feature-based team where they’ll take this knowledge and hit the ground running. Additionally, your organization can benefit from having all team members (even those who have been around for a while) periodically work a rotation with the design system team. This continuously spreads the design system expertise around the organization and makes it part of the fabric of how you work.

    And don’t think this approach is only valuable for designers or developers. A healthy design system team comprises people from many disciplines. In addition to team member rotation, building in time to mentor folks from many different disciplines can prove tremendously valuable in the long run. A highly functional design system team can serve as an ideal model of workflow and can educate many team members dispersed throughout the organization about how to approach their work.

    Believe me, executives’ eyes will light up when you share how a design system can ensure high productivity in record time. As a caution, though, rotating people in and out of any team too often can leave them feeling exhausted and can make it hard for them to be productive. Remember, you have the flexibility to scale this to a level that makes sense for your team. Be smart and use this approach as it works in your context.

    What to measure

    Action: Measure the time it takes for teams to become productive.

    As new people are added, a team typically returns to the “forming” stage of Tuckman’s stages of group development. This is part of the reason that growth is expensive. But with a design system in place and a healthy culture, you can reduce the time it takes the team to get back to “performing.”

    Scale benefits

    Traditionally, you have to hire more people to scale productivity. A design system enables a team to accomplish more with less. Reusability is a major reason teams choose to work in a more systematic way. Small teams with an effective system can design, build, and maintain hundreds of sites each year. They’d never come close without a design system to work with. 

    UX Pin has a design system guide that starts by acknowledging something that most of us ignore.

    Scaling design through hiring, without putting standards in place, is a myth. With every new hire, new ideas for color palettes, typography and patterns appear in the product, growing the inconsistency and increasing the maintenance cost. Every new hire increases the design entropy.

    A well-executed system allows a team to scale while keeping design entropy at bay.

    What to measure

    Action: Compare the amount of people on your team to the amount of work they are accomplishing.

    Adding people to a team doesn’t necessarily mean they’ll get more work done faster. This is well-documented in historical software books like Fred Brooks’ The Mythical Man-Month. Eventually, you will have to investigate changing other factors (besides just adding more people) to increase productivity. A good design system can be one of these factors that increases the productivity of the team members you already have. It’s this change in productivity over scale that you need to measure and compare in order to prove value for this benefit.

    External-orientation motivators

    Let’s shift to thinking about the benefits that a design system offers to end-users. The four primary external motivators are:

    • Consistency
    • Trust
    • Accessibility
    • Usability.

    Consistency and Trust benefits

    Consistency is widely assumed to be the primary benefit of a design system. We identify dozens of button designs, color variations, and inconsistent typefaces in hopes of convincing higher-ups to allow us to build a system to bring it all in line. After working on design systems for the last five or six years, I can say with confidence that a design system will not make your product more consistent. 

    You see, us web designers and developers are very scrappy. We can create the most inconsistent experiences within even the most rigid systems. It’s not the system itself that creates consistency, it’s the culture of an organization. It’s all of the unspoken expectations—the filters through which we make decisions—that give us the confidence to pause and ask if the work we’re doing fits culturally with the product we’re building. A good CMO knows this, and they won’t buy the oversimplified idea that a design system will solve the rampant inconsistencies in our work. 

    Because of this, these executives often have a different (and easier to measure) question: “Does it convert?” This perspective and line of conversation is not an ideal approach. Believe me, we can create experiences that convert but are not good for our users or our brands. Given this, a conversation with your CMO might go better if you shift the language to talk about trust instead.

    With inconsistent experiences, your users subconsciously lose trust in your brand. They’ve been conditioned to expect a certain kind of user experience, and that’s what they should be given, even across multiple websites or products. Vanessa Mitchell wrote about why brand trust is more vital to survival now than it’s ever been:

    “Brand trust as an ‘“insurance policy”’ against future issues is not a new concept. Most organizations know trust bestowed by the consumer can not only make or break a business, it can also ensure you survive a problem in the future. But few achieve brand trust adequately, preferring to pay lip service rather than delve into what it really means: Authentically caring about customers and their needs.”

    When your customer is using your product to accomplish a very specific task, that one task is the only thing that matters to them. Creating a consistent experience that works for everyone and allows them to accomplish their goals is building trust. CMOs need to understand how design systems empower trusted relationships so those relationships contribute to your bottom line.

    What to measure

    Action: Measure the engagement of your customers.

    Customer engagement can be measured with web analytics platforms. What you’re looking for will vary depending on the context for your organization, but trends in things like time on site, visit frequency, subscription rates, and bounce rates will give you meaningful data to work with. It’s also very common to track customer engagement with metrics like Net Promoter Score (NPS) by asking simple questions of customers repeatedly over time. There are so many ways to structure tests of the usability of your work, so I’d encourage you to loop in the UX team to help you find tests that will demonstrate the user engagement success of the design system effort.

    Accessibility benefits

    Accessibility can be a tremendous benefit of a design system. Do the work properly the first time, then allow that beautifully accessible component to serve your customers each time it is used. Certainly, it’s not a fail-safe measure—there is still integration-level testing to ensure component accessibility translates to the larger experience—but ensuring the accessibility of individual components will result in more accessible experiences. And integrating good accessibility practices into your system means more folks within your organization are aligned with this important work. 

    You might find at first that marketers aren’t all that interested in accessibility, but they should be. Did you know that there were 814 web accessibility related lawsuits (just in the US!) in 2017? Did you know that there were almost 2,300 in 2018? That’s a 181% increase. This must be a priority. First, because it’s the right thing to do. Second, because it’s important to the sustainability of the business. A design system can help you address this issue, and it can help you maintain compliance as you grow. This is the kind of message that resonates with leadership.

    What to Measure

    Action: Measure your compliance to accessibility guidelines over time.

    Many organizations have a regular cadence of accessibility audits across their digital properties. While some of this can be automated, there’s always a manual aspect needed to truly evaluate the accessibility of a site or application. Tracking how often regressions occur in the properties served by your design system can be a great way to demonstrate the value that system is bringing to the organization.

    Usability benefits

    As with so many aspects of a design system, usability benefits come from repetition. Design system pros often hope to focus energy on solving a usability challenge only once before moving on to the next problem. This absolutely is a benefit of a well-constructed system. It’s also very true that “familiarity breeds usability.” Your customers will learn to use your products and begin to subconsciously rely on that familiarity with the experience to lower their cognitive load. This should be just as important to our executive leadership as it is to those of us who are practitioners. 

    You can also reframe this benefit in the context of conversion. Helping our users accomplish their goals is helping them convert. They are there to use your product. So make it easy to do, and they’ll do it more. This is what businesses need and what executives want to see—improving the business by helping customers. As mentioned above, we want to make sure we’re doing this in healthy ways for both our users and our brands.

    What to Measure

    Action: This might be the easiest one—measure conversion!

    Running usability studies will help to validate and measure the success of your work with the system, which many organizations are already doing. Your goal should be to validate that components are usable, which will allow you to build a culture of user-centered design. Setting the bar for what it takes to evolve the system—such as requiring that changes are tested with real users—introduces this idea into the core of all your processes, where it should be.

    Sell investment, not cost

    Knowing how and which internal and external motivators to touch on during conversations is significant, but there’s one last thing I’d like to mention, and it has to do with your way of thinking. A major factor in many of these conversations lies simply in how we frame things: move the conversation about the cost of building a design system into a conversation about the present and residual benefits of the investment you’re making. It’s easy to view the time and effort required to build a system as an investment in ultimately delivering high-quality digital products. But leadership will be more willing to consider realistic budgets and timelines if you talk about it like a long-term investment that has benefits on multiple levels throughout the business. This also leaves you with the ability to regularly remind them that this product will never be done—it will require ongoing funding and support.

    A design system project will not succeed if you don’t convince others that it’s the right thing to do. Successful, sustainable design systems start with the people, so you have to begin by building consensus. Building a design system means you’re asking everyone to change how they work—everyone has to be on board.

    This concept of collaboration is so core to the work of design systems that it led all of us here at Sparkbox to look for opportunities to better understand how teams around the world are designing, building, and using a more systematic approach to digital product design. For the last three years, we’ve been gathering and sharing data in the form of the Design Systems Survey and the Design System Calendar. If you are considering a design system for your organization, or if you work with a design system team, the survey and calendar may be helpful in your quest to build better products.

  • Navigating the Awkward: A Framework for Design Conversations

    We’ve all been there. A client or coworker shows us this amazing thing they (and maybe their entire team) have worked on for hours or weeks. They are so proud of it. It’s new or maybe it just looks new. They may or may not ask you what you think—but you’re there to experience it. And your brain quietly screams.

    As an experienced designer, you often have an intuitive reaction and can quickly spot bad designs; they may be visually incongruent, poorly structured, confusing, lack social awareness, or look like they are trying too hard.

    If your initial response is so negative that it slips through into your expression or voice or body language, it can completely sabotage any possibility of buy-in. And, far more seriously, it can ruin the relationship of trust and collaboration you’re building with that person. 

    Reflecting on my own successes and failures—and the experiences of others—I’ve put together a conversational framework for navigating these all-too-frequent design interactions, whether you’re an in-house designer, a consultant, or an agency employee. 

    Be a relationship steward

    “Getting things done” is often accomplished at the expense of relationships and sustainable design solutions. As in, the “We need to manage this situation” approach (emphasis on the “manage”) quite often looks more immediately effective on paper than the “We need to be productive while stewarding this project for this partner” mindset.  

    The thing is, a design stewardship mindset to working with clients/partners is a better bet; thinking beyond buy-in or proving your point or getting your own way pays off in both an immediate situation, and long-term, for both sides.

    I’ve had plenty of those “design conversations gone wrong” over the years, and have noticed a common set of whys and hows behind the scenes. To help me consciously factor them in and stay focused, I’ve developed this simple conversational framework:

    Element 1: Move from selling to helping.

    Element 2: Question your triggers and explore the problem.

    Element 3: Map the problem to the client’s values.

    Element 4: Formulate questions for the client based on values.

    Element 5: Listen and be prepared to challenge your assumptions.

    Element 6: Reflect back on the problem and share recommendations with the client.

    We’re going to explore all that below, but here’s a quick reference version of conversational frameworks you can look at as we go.

    Healthy self-talk

    When confronted with a bad design, there are some common reactions a designer might have—what we often catch ourselves saying in our head (hopefully!) or directly to our clients. (I need to preface by saying I borrowed some of these from a viral “Hi, I’m a ...you might know me from my greatest hits...” on Twitter.)

    • You are not your users!
    • Blindly following another organization’s best practices is not going to guarantee successful conversion for your business.
    • Have they ever heard there’s such a thing as Calls to Action?
    • Really, you couldn’t have bothered to tell the user ahead of time how many steps this process involves?
    • No, a chatbot won’t magically fix your horrible content!
    • Is this clipart?!!
    • Don’t use your org chart for navigation...not even on your intranet.
    • You can’t mix apples and oranges.
    • Views do not equal engagement metrics!
    • Stop celebrating outputs instead of outcomes!
    • Diversity is more than just white women.
    • You’re talking about implementation details, but I still don’t even know what problem we’re trying to solve.
    • Not another FAQ!
    • Does accessibility mean anything to these folks?
    • We don’t need 15 unique designs for this button. There is a style guide for that!
    • Good luck with your SEO efforts; keyword stuffing won’t get you ranking!
    • Can we start designing experiences instead of pages and features?

    I am sure you can relate. While there’s nothing inherently wrong about these statements—and there are times when it is worth being upfront and saying them as-is—we also know they might be ineffective, or worse yet, perceived as confrontational. 

    Someone worked hard on this. They put a lot of thought into it. They love it. They want this to be the solution. 

    So, how can we avoid defensiveness? How do we engage the other person in a meaningful conversation that comes from a place of empathy instead of arrogant expertise? 

    In describing “How Shifting Your Mindset Can Ignite Transformation,” Keith Yamashita points out that “each of us comes into the world curious, open, wanting to bond and wanting to have great connections with other people,” yet “our training, societal norms, school, and early jobs beat all of that out of us.” Self-awareness and inner reflection are essential to helping us reconnect with other humans. Practicing mindfulness is a great way to develop and enhance these skills.

    It’s not me, it’s you (Element 1)

    First step to getting your message across is shifting your position from “How do I share my perspective” to “How can I help my (clients/partners/coworkers) improve their current product?” 

    Make room for the needs of others and create some distance from your ego and. In particular, try to refrain from saying what you find so intuitive, as well as delay providing your opinion. 

    Blair Enns, who writes about the importance of being a vulnerable expert, says it beautifully (emphasis is mine):

    • You can be slick or the client can be slick. It’s better if it’s the client.
    • You can fumble and be awkward in the conversation or the client can fumble and be awkward. It’s better you are the awkward one.
    • You can have all the answers to the client’s questions or the client can have all the answers to your questions. It’s better to ask the questions. (Nobody has all the answers.)
    • Those who are not trained in selling often think of the cliches and think they must be seen to be in control, to have the answers, to have the polish. The opposite however is better. You can still be the expert by showing vulnerability. You don’t need to manufacture answers you do not have. It’s okay to say “let me think about that.”

    Allowing others to be in the spotlight may take some practice and requires you to be self-aware. When you find yourself triggered and itching to comment or to disagree with something, try the following exercise:

    1. Pause.
    2. Acknowledge that you are frustrated and want to jump in.
    3. Invite yourself to be curious about the trigger instead of judging yourself or others. 

    The more you practice this kind of self-awareness, the more you’ll notice your triggers and change how you respond to them. This quick mental exercise gives you the space to make an intentional choice. For similar practical strategies, take a look at “How to Turn Empathy into Your Secret Strength.”

    Winning the moment isn’t a win (Element 2)

    One potential trigger may be rooted in your mindset: are you more focused on trying to get “buy-in,” or on building positive, lasting relationships to support ongoing collaboration and stewardship?

    To do this, you need to first ask yourself some questions to get to the bottom of what your impulse is trying to communicate. You then need to do some slow thinking and identify a question that will engage your partner in a conversation.

    Here’s a hypothetical situation to explore what this might look like.

    You’re shown a very clunky, centralized system designed so users can register for recreational activities around the city. The client wants your team to create a chatbot to support it. 

    Your internal reaction: “Instead of pages and features, can we start designing experiences?”

    Analyzing your reaction:


    When we focus on pages and features like chatbot solutions, we typically aren’t seeing the whole picture.


    Organizations can get distracted by a shiny opportunity or single perceived problem in a product, but these can frequently overshadow where real impact can be made. 


    The 80/20 Pareto principle has a strong pull for many organizations.


    Organizations want solutions that take minimal perceived time and effort.


    Organizations want to save money/go with the cheaper option. 

    So what?

    As a result, organizations risk prioritizing what seems to be the easy thing at the expense of other, more user-friendly and profitable solutions. 

    This example is simplistic, but notice that by asking a few sets of questions, we were able to move from a reactive statement to a reason why something may not be working—a reason that’s a lot less emotional and more factual. You could use a modified 5 Whys approach like this, or some other questioning method that suits the situation. 

    If you dissect our example more closely, you’ll see that unlike the initial reaction, which speaks more to design elements like pages and features, we are now talking about more broadly relatable topics across business lines, such as cost savings or risk assessment. Structuring your conversation around topics most familiar to the other person and reflecting their core values can help us be more successful in improving their product.

    Ask with values in mind, close with opportunities (Element 3)

    I recently attended an excellent event on “Speaking Truth to Power,” presented by the Canada School of Public Service. The keynote speaker, Taki Sarantakis, shared his strategies for how to be an effective expert and advisor, such as:

    • Be credible and build trust
    • Have humility and empathy
    • Make sure that the person you are advising understands that the advice they do not want to hear is for their benefit.

    He also broke down a few concepts that could be a barrier to implementing this advice. If we see ourselves as “speaking truth to power” we are likely making a values judgement. We believe and project to others that we have all truth and no power, while the person on the other end has all the power, and no truth. It’s an arrogant position that weakens our ability to make any productive progress. Framing our interactions as a battle will likely result in a lose-lose situation.  

    Sarantakis then presents an example conversation that is rooted in credibility and humility, and comes from a place of care. He underscores that any advice you choose to share has to absolutely come from a place of concern for the person making a final decision, and not from a desire to show off and say so on record. It roughly looks like this:

    • Here is what you need to know...
    • You know X, but you may not know Y and Z.
    • I know this is something you may not want to hear, but I need to say it because it is important that you know this.

    As part of the panel discussion that followed the keynote, Kym Shumsky, who has lots of experience advising senior leaders, reinforced Sarantakis points by stating that valuing truth, knowledge, and accuracy over relationship-building can be detrimental. Thinking back on my personal experiences, I fully agree. 

    So how do we build trust, credibility, and share from a place of care? Steve Bryant, Head of Content at Article Group, has some thought-provoking words on this in his article “Make relationships, not things”:

    Relationships are based on trust. Trust takes time and honesty. You can’t just create a pile of content and be done with it. You can’t “thing” your way to people trusting you.

    Which is to say: the question isn’t what content to create.

    The question isn’t how to create that content.

    The question is why do you care about the people you’re creating the content for? What makes them special? What kind of relationship do you want to have?

    How do you want them to feel?

    Translating core values into specific needs (Element 4)

    Going back to the exercises we just explored and what we think could be the source of the problem, it’s time to start moving backward from the core values to specific design characteristics that need to be addressed.  

    You have to always start the conversation as a set of questions. Beginning with questions allows you to set aside the expert hat, be curious, and let the client share their experiences. It shows them you care and are there to listen generously

    Build rapport, be present, and be there to listen (Element 5)

    Erika Hall offers timeless advice about the need to build rapport and understand our partners in her article “Everyday Empathy”:

    And as social science shows, trying to bridge the gap with facts will never change anyone’s mind. The key is to value — truly value — and reflect the perspective of the people you want to influence. [...] Attention is a gift beyond measure.

    A great bit of advice on “being present” rather than “presenting” on a topic is offered by Blair Enns (author of The Win Without Pitching Manifesto) in the episode “Replacing Presentations with Conversations.” Being present also means being vulnerable and open to discovering something new that might change your initial reaction. 

    And then be prepared to truly listen, not convince. Sarah Richards points out how important it is to understand the different mental models that partners bring to the table and work together to form new ones to accomplish common goals:

    How many times have you said you are going to talk to someone who is blocking you? Now count how many times have you said you are going to listen to someone who is blocking you? When we have someone in our organisation who disagrees with us, we go to see if we can convince someone that our way of thinking, our way of doing things, is the best way of doing it.

    Here is what a conversation relating to “Can we start designing experiences instead of pages and features?” might look like, if we follow this approach:

    You: What do you hope to accomplish with a chatbot?

    Partner: We want people to get answers to their questions as quickly as possible, so they can register and pay for local recreation activities of their choice faster. We live in a beautiful city and it’s a pity when residents and visitors can’t take advantage of everything it has to offer. 

    You: What have you heard from the people who experienced barriers to quickly registering and paying?

    Partner: They complain that they can’t easily find activities in community centers closest to them or that there is no way for them to see all current and upcoming classes around the city at a glance, or that additional information about different activities is not provided within the system and they often have to look up events or class instructors separately to find more information on other websites. They also are not able to browse all activities by type of recreation, like “nature” activities, which might include hiking, city tours, birdwatching, garden events, and festivals. They often do not know what terminology to use to search for events and activities, so they say it is difficult to find things they already do not know about.

    You: How do you think this makes them feel?

    Partner: They say this frustrates them, as information on other websites might differ from the information in our system and they end up wasting their time guessing which one is correct and up-to-date. They then end up having to call the community center or organization providing an event for more information, to figure out if it is a good fit, before registering and paying; which significantly delays the process. 

    I think you see where this is going. 

    Here are a few more follow-up questions:

    • Have you tried registering for an activity using the system? How did you feel/what did you experience? 
    • What would you like people using your system to feel/experience?
    • You’ve mentioned a number of barriers that people experience. How well do you think a chatbot will be able to remove these barriers now?
    • What are some of the risks you foresee in trying to solve these problems?

    At this point, if you hear something that makes you pause and question your assumptions, ask further questions and consider going back to the drawing board. Maybe you need to ask yourself: What are my lenses?

    Respond with care and invite collaboration (Element 6)

    If what you’ve heard confirms your assumptions, you could offer a few concise, summative statements and a recommendation. Whatever you say needs to integrate the vocabulary used by the client (mirroring), to show them that you were listening and critically reflecting on the situation. 

    Let’s see how that might look:

    “Based on what you’ve shared, it seems that you want to make it quick and easy for anyone in the city to discover, decide on, and pay for a local recreation activity. The experience of the people using the system is very important to you, as you want them to enjoy the city they live in, as well as support the vibrancy of the city economically by registering and paying for local activities.

    If we want to help people enjoy and experience the city through events and activities, we need to make it simple and frictionless for them. The barriers they experience cannot be solved with a chatbot solution because the information people are looking for is often missing and not integrated into the current system in a meaningful way. So the chatbot would not give them the answers they need, creating further frustration. 

    Adding a chatbot also creates an extra layer of complexity. It does not solve the underlying cause of frustration stemming from lack of relevant and integrated information. Instead, it leaves the current experience broken and creates yet another place people need to go to for possible answers.

    It would also be a huge risk and time investment to design a chatbot, as your current content is not structured in a way that would allow us to have useful information extracted.

    Given your time and resource constraints, I would suggest we explore some other solutions together.” 

    Framing and reinforcing the conversation

    To recap, here are the six essential elements of the conversational framework:

    Element 1: Mentally move from how you can share and sell your perspective to how you can help your partner.

    Element 2: Ask yourself probing questions to better understand your reaction to the “bad design” trigger and what is at the core of the problem.

    Element 3: Map the core of the problem to value(s) you can use to begin the conversation with a partner.

    Element 4: Use value(s) identified to formulate and ask questions.

    Element 5: Get ready to truly listen to your partner and be prepared to challenge your assumptions.

    Element 6: Review your responses to probing questions and identify recommendations you can share back with the partner.

    This conversational framework starts with us as individuals, forces us to critically deconstruct our own reactions, then asks us to reframe what we find from a perspective of what matters and is known to our clients. It reminds us that we should learn something in the process by having intentional yet open conversations.

    Future of design leadership is stewardship

    The work we do in the web industry touches people—so we need to be people. We need to be human, build trust, and sustain relationships with our clients and partners. If we aren’t doing a good job there, can we really claim it’s not impinging on our designs and end users?

    Our growth as web professionals can’t be limited to technical expertise; design leadership is stewardship. It’s rooted in listen, then respond, in learning how to pause, create space, and get to the root of the problem in a productive and respectful way. We need to learn how to intercept our reactions, so that we can shift how we approach triggering situations, stay still and listen, and open up conversations rife with possibilities, not progress suppressors. Guide clients toward better design choices by meeting them in the moment and partnering with them.

    In design work, being a steward does not mean that you should push to get your way. Neither does it mean you should indulge clients and create broken or unethical products. Rather, it proposes an attuned way of approaching potentially contentious conversations to arrive at a solid, ethical design. It is about framing the conversation positively and ushering it as a steward, rather than stalling discussion by being the gatekeeper. 

  • Webwaste

    The Web is obese

    In 1994, there were 3,000 websites. In 2019, there were estimated to be 1.7 billion, almost one website for every three people on the planet. Not only has the number of websites exploded, the weight of each page has also skyrocketed. Between 2003 and 2019, the average webpage weight grew from about 100 KB to about 4 MB. The results?

    “In our analysis of 5.2 million pages,” Brian Dean reported for Backlinko in October 2019, “the average time it takes to fully load a webpage is 10.3 seconds on desktop and 27.3 seconds on mobile.” In 2013, Radware calculated that the average load time for a webpage on mobile was 4.3 seconds.

    Study after study shows that people absolutely hate slow webpages. In 2018, Google research found that 53% of mobile site visitors left a page that took longer than three seconds to load. A 2015 study by Radware found that “a site that loads in 3 seconds experiences 22% fewer page views, a 50% higher bounce rate, and a 22% fewer conversions than a site that loads in 1 second, while a site that loads in 5 seconds experiences 35% fewer page views, a 105% higher bounce rate, and 38% fewer conversions.”

    The causes of webpage bloat? Images and videos are mainly to blame. By 2022, it’s estimated that online videos will make up more than 82% of all consumer Internet traffic—15 times more than in 2017. However, from the code to the content, everything about Web design has become super-bloated and super-polluting. Consider that if a typical webpage that weighs 4 MB is downloaded 600,000 times, one tree will need to be planted in order to deal with the resulting pollution.

    They say a picture paints a thousand words. Well, 1,000 words of text takes up roughly two A4 (210 mm wide and 297 mm long) pages and weighs about 6 KB. You’d place about four images that are 9 cm x 16 cm on two A4 pages. Let’s say these images are well optimized and weigh 40 KB each. (A poorly optimized image could weigh several megabytes.) Even with such high optimization, two A4 pages of images will weigh around 160 KB. That’s 27 times more than the two A4 pages of text. A 30-second video, on the other hand, could easily weigh 3 MB. Videos create massively more pollution than text. Text is the ultimate compression technique. It is by far the most environmentally friendly way to communicate. If you want to save the planet, use more text. Think about digital weight.

    From an energy point of view, it’s not simply about page weight. Some pages may have very heavy processing demands once they are downloaded. Other pages, particularly those that are ad-driven, will download with lots of third-party websites hanging off them, either feeding them content, or else demanding to be fed data, often personal data on the site’s visitor. It’s like a type of Trojan Horse. You think you’re accessing one website or app, but then all these other third parties start accessing you. According to Trent Walton, the top 50 most visited websites had an average of 22 third-party websites hanging off them. The New York Times had 64, while Washington Post had 63. All these third-party websites create pollution and invade privacy.

    There is a tremendous amount of out-of-date content on websites. I have worked with hundreds of websites where we had to delete up to 90% of the pages in order to start seeing improvements. Poorly written, out-of-date code is also a major problem. By cleaning up its JavaScript code, Wikipedia estimated that they saved 4.3 terabytes a day of data bandwidth for their visitors. By saving those terabytes, we saved having to plant almost 700 trees to deal with the yearly pollution that would have been caused.

    If you want to help save the planet, reduce digital weight. Clean up your website. Before you add an image, make sure that it does something useful and it’s the most optimized image possible. Every time you add code, make sure it does something useful and it’s the leanest code possible. Always be on the lookout for waste images, waste code, waste content. Get into the habit of removing something every time you add something.

    Publishing is an addiction. Giving a website to an organization is like giving a pub to an alcoholic. You remember the saying, “There’s a book inside everyone”? Well, the Web let the book out. It’s happy days for a while as we all publish, publish, publish. Then…

    “Hi, I’m Gerry. I have a 5,000-page website.”

    “Hi, Gerry.”

    “I used to have a 500-page website, but I had no self-control. It was one more page, one more page… What harm could one more page do?”

    Redesign is rehab for websites. Every two to three years some manager either gets bored with the design or some other manager meets a customer who tells them about how horrible it is to find anything on the website. The design team rounds up a new bunch of fake images and fake content for the top-level pages, while carefully avoiding going near the heaving mess at the lower levels. After the launch, everyone is happy for a while (except the customers, of course) because in many organizations what is important is to be seen to be doing things and producing and launching things, rather than to do something useful.

    If you must do something, do something useful. That often means not doing, removing, minimizing, cleaning up.

    Beware the tiny tasks. We’ve used the Top Tasks method to identify what matters and what doesn’t matter to people, whether they’re buying a car, choosing a university, looking after their health, buying some sort of technology product, or whatever. In any environment we’ve carried it out in—and we’ve done it more than 500 times—there are no more than 100 things that could potentially matter.

    In a health environment, these might include symptoms, treatment, prevention, costs, waiting times, etc. When buying a car they might include price, engine type, warranties, service costs, etc. We’ve carried out Top Tasks surveys in some 40 countries and 30 languages, with upwards of 400,000 people voting. In every single survey the same patterns emerge. Let’s say there are 100 potential tasks. People are asked to vote on the tasks that are most important to them. When the results come in, we will find that five of the tasks will get the first 25% of the vote. 50 tasks will get the final 25% of the vote. The top five tasks get as much of the vote as the bottom 50. It’s the same pattern in Norway, New Zealand, Israel, USA, Canada, UK, Brazil, wherever.

    The bottom 50 are what I call the tiny tasks. When a tiny task goes to sleep at night it dreams of being a top task. These tiny tasks—the true waste generators—are highly ambitious and enthusiastic. They will do everything they can to draw attention to themselves, and one of the best ways of doing that is to produce lots of content, design, code.

    Once we get the Top Tasks results, we sometimes analyze how much organizational effort is going into each task. Invariably, there is an inverse relationship between the importance of the task to the customer and the effort that the organization is making in relation to these tasks. The more important it is to the customer, the less is being done; the less important it is to the customer, the more is being done.

    Beware of focusing too much energy, time and resources on the tiny tasks. Reducing the tiny tasks is the number one way you can reduce the number of pages and features. Save the planet. Delete the tiny tasks.

    A plague of useless images

    I was giving a talk at an international government digital conference once, and I asked people to send me examples of where digital government was working well. One suggestion was for a website in a language I don’t speak. When I visited it, I saw one of those typical big images that you see on so many websites. I thought to myself: I’m going to try and understand this website based on its images.

    The big image was of a well-dressed, middle-aged woman walking down the street while talking on her phone. I put on my Sherlock Holmes hat. Hmm… Something to do with telecommunications, perhaps? Why would they choose a woman instead of a man, or a group of women and men? She’s married, I deduced by looking at the ring on her finger. What is that telling me? And what about her age? Why isn’t she younger or older? And why is she alone? Questions, questions, but I’m no Sherlock Holmes. I couldn’t figure out anything useful from this image.

    I scrolled down the page. Ah, three more images. The first one is a cartoon-like image of a family on vacation. Hmm… The next one is of two men and one woman in a room. One of them has reached their hand out and placed it on something, but I can’t see what that something is, because the other two have placed their hands on top of that hand. It’s a type of pledge or something, a secret society, perhaps? Two of them are smiling and the third is trying to smile. What could that mean? And then the final picture is of a middle-aged man staring into the camera, neither smiling nor unsmiling, with a somewhat kind, thoughtful look. What is happening?

    I must admit that after examining all the visual evidence I had absolutely no clue what this government website was about. So, I translated it. It was about the employment conditions and legal status of government employees. Now, why didn’t I deduce that from the images?

    The Web is smothering us in useless images that create lots of pollution. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution and waste, as they cause page bloat, making it slower for pages to download, while pumping out wholly unnecessary pollution. They take up space on the page, forcing more useful content out of sight, making people scroll for no good reason.

    Interpublic is a very large global advertising agency. As with all advertising agencies they stress how “creative” they are, which means they love huge, meaningless, happy-clappy polluting images. When I tested their homepage, it emitted almost 8 grams of CO2 as it downloaded, putting Interpublic in the worst 10% of website polluters, according to the Website Carbon Calculator. (For comparison, the Google homepage emits 0.23 grams.) One single image on its homepage weighed 3.2 MB. This image could easily have been 10 times smaller, while losing nothing in visual appeal. The Interpublic website is like a filthy, rusty 25-year-old diesel truck, belching fumes as it trundles down the Web.

    Instead of optimizing images so that they’ll download faster, the opposite is often happening. High-resolution images are a major cost to the environment. If, for example, you move from a 4K resolution image to an 8K one, the file size doesn’t double, it trebles. For example, I saved an image at 4K and it was 6.9 MB. At 8K it was 18 MB.

    Digital “progress” and “innovation” often means an increasing stress on the environment. Everything is more. Everything is higher. Everything is faster. And everything is exponentially more demanding of the environment. Digital is greedy for energy and the more it grows the greedier it gets. We need digital innovation that reduces environmental stress, that reduces the digital footprint. We need digital designers who think about the weight of every design decision they make.

    We must start by trying to use the option that damages the environment least, and that is text. Don’t assume that images are automatically more powerful than text. Sometimes, text does the job better.

    • In a test with an insurance company, it was found that a promotion for a retirement product was deemed less accurate when an image of a face was used than when text only was used.
    • An initiative by the UK government to get people to sign up to become potential organ donors tested eight approaches. The approaches that used images were least effective. Text-only worked best.


    “Hello. Is that the Department of Useless Images?”


    “We have this contact form and we need a useless image for it.”

    “How about a family cavorting in a field of spring flowers with butterflies dancing in the background?”


    There are indeed many situations where images are genuinely useful, particularly when it comes to helping people better understand how a product works or looks. Airbnb, for example, found that its growth only began to accelerate after it invested in getting quality images of the rental properties on offer.

    If you need to use images, optimize them and consider using real ones of real people doing real things.

    They say a picture paints a thousand words but sometimes it’s a thousand words of crap.

Search Engine Watch
Keep updated with major stories about search engine marketing and search engines as published by Search Engine Watch.
Search Engine Watch
ClickZ News
Breaking news, information, and analysis.
  • AMD's game-boosting Smart Access Memory is coming to Ryzen 3000

    The $479 Radeon RX 6700 XT obviously stole the spotlight at AMD’s “Where Gaming Begins: Ep. 3” event on Wednesday, but before Radeon chief Scott Herkelman showed off his shiny new graphics card, he delivered another very welcome announcement. AMD’s Smart Access Memory feature is coming to Ryzen 3000 processors to make your games run faster.

    AMD debuted Smart Access Memory alongside its fantastic Ryzen 5000 processors. Smart Access Memory is built atop the PCIe specification’s optional Resizable BAR feature and allows your CPU to fully access your graphic card’s memory buffer, an upgrade from the usual 256MB chunks. The tweak can provide a performance uplift ranging from negligible to notable, as our Smart Access Memory testing with the Radeon RX 6900 XT revealed. Depending on the game and resolution, we saw frame rates soar by up to 8 percent, and AMD says Smart Access Memory can boost performance by up to 16 percent in best-case scenarios.

    To read this article in full, please click here

  • Google Chrome will replace third-party cookies with tracking that's less intrusive

    Google has pledged to crack down on third-party cookies in its Chrome browser for over a year now, taking progressive steps to weed out the code that collects data about you and shares it with the site you’re visiting. Cookies can be helpful in storing your user name and password, or saving your shopping cart; but they can also be used to serve up ads as you browse, making it feel creepily like someone knows what you’re looking for now—or what you looked for last week.

    On Wednesday the company made a further commitment to privacy by saying it won’t replace cookies with alternative methods of tracking users in Chrome. “We don’t believe these solutions will meet rising consumer expectations for privacy, nor will they stand up to rapidly evolving regulatory restrictions, and therefore aren’t a sustainable long term investment,” Google’s David Temkin, the director of product management for ads, privacy and trust, wrote in a blog post. “Instead, our web products will be powered by privacy-preserving APIs which prevent individual tracking while still delivering results for advertisers and publishers.”

    To read this article in full, please click here

  • Brave Search is a privacy-first search engine

    Browser privacy is a big deal, as Google and other companies use your search data to serve you ads while you surf the web. While most users accept that tradeoff, others who believe strongly in maintaining their own data privacy. If you’re one of these, Brave Software can help. On Wednesday the company said it’s launching a search engine to compete with Google and Bing, with privacy as its first priority.

    Brave is buying Tailcat, an open search engine, and will add it to what it’s calling Brave Search, a forthcoming search engine. The difference between Google, Bing, and Brave Search is twofold: Brave won’t collect IP addresses or use personally identifiable information to improve search result; and it will collect its own, independent search index.

    To read this article in full, please click here

  • AMD's $479 Radeon RX 6700 XT targets silky-smooth 1440p gaming

    AMD’s new $479 Radeon RX 6700 XT graphics card will target gamers who want to play at 1440p with max settings but its best feature may be that it’ll be available in “significantly” higher volumes than Radeon RX 6800 GPUs were at launch, the company said Wednesday morning. AMD also announced that its performance-boosting Smart Access Memory technology will be coming to Ryzen 3000 processors.

    But the star of the show was the Radeon RX 6700 XT, which features 40 compute units, a game clock of 2,424MHz, 96MB of AMD's radical Infinity Cache, a 230 watt power rating, and an ample 12GB of GDDR6 memory. AMD is especially touting that massive memory buffer to differentiate the Radeon RX 5700 XT from its rivals when they go on sale on March 18.

    To read this article in full, please click here

  • Samsung Galaxy Buds Pro review: A little bit of everything

    Priced at just $199.99, the Samsung Galaxy Buds Pro are worthy options for Samsung-focused Android users who want a little bit of everything packed into their wireless earbuds, whether it’s attractive audio performance, excellent waterproofing, a comfortable fit, or active noise cancellation. With their unique voice detection feature and impressive waterproofing, they even manage to come out ahead of other earbuds aimed at a similarly wide market. Unfortunately, you’ll need to be fully committed to the Samsung ecosystem if you want to get the most out of them, but their versatility makes them a solid choice for anyone with an Android device.

    The right look

    They certainly look good. Elements of both the Galaxy Buds Plus and the Galaxy Buds Live reveal themselves in the design, and I consistently found myself admiring the glossy exterior. But I most appreciate them for the many times when I barely noticed them at all. They don’t protrude from my ears as much as Samsung’s previous efforts, and I was able to find a perfect fit among the three silicone tips that come in the box.

    To read this article in full, please click here

CNN.com - RSS Channel - App Tech Section
CNN.com delivers up-to-the-minute news and information on the latest top stories, weather, entertainment, politics and more.
CNN.com - RSS Channel - App Tech Section

Ако решите, че "как се прави сайт" ръководството може да бъде полезно и за други хора, моля гласувайте за сайта:

+добави в любими.ком Елате в .: BGtop.net :. Топ класацията на българските сайтове и гласувайте за този сайт!!!

Ако желаете да оставите коментар към статията, трябва да се регистрирате.