CENTRALIZATION (DIY) vs. DECENTRALIZATION (DIT)

The first part of this post built an analogy, that centralization is like DIY (Do-it-Yourself) and decentralization is like DIT (Do-it-Together).

If we can agree on that analogy, simply for the sake of conversation, then we can take it a step further by looking through that lens into some specific contexts where this approach can add value to our efforts by breaking down our silos.

This seems to have been a huge theme ever since the DevOps movement began in earnest. While there is much overlap here in the context of DevOps, this post is focused more on the software development lifecycle and how a UX practice can help both internal and external teams work together better.

AGILE PROCESSES HELP DISMANTLE SILOS

Agile Methodology and Design-Thinking have helped drive the current shift from centralization to decentralization. Making something shouldn’t be driven by the decisions of a single person but by the whole team. This is a definitive move away from centralized thinking about problem-solving to a decentralized one.

In short, thinking about and designing the things we make is no longer a single person’s role. It is a collective responsibility. Whether our company is big or small, a certain adaptability is required for creating valuable products. The processes that produce them require that we leverage the talents, interests and skills of the whole team.

Sounds lovely, but it is disrupting a lot of people’s mojo in direct proportion to the amount of information, process and procedure they have hoarded into tidy silos over time where none of it, or only incomplete sets of it, are accessible to the collective.

This is why any process should be agile.

This tendency of silo-ing fostered the idea of agile in the first place, in order to decentralize knowledge of specific processes and procedures, to create and drive a truly shared vision. It opens up those silos so the whole team can participate more readily in the entire process of producing products and services for the Web, be it site, app, SaaS, PaaS, IoT or any of the hidden machinery (ie infrastructure) that powers them.

Agile breaks down the silos that waterfall built.

WIREFRAMING AS CENTRALIZATION (or DIY)

A great example to consider in this shift to decentralized thinking is the basic process typically used to build for the Web. Web design has been around for a while now and is subject to the same philosophical shift. Historically, sites have been designed and built in isolation, in waterfall fashion, driven by one person’s ideas and handed downstream to a team to figure out. The tools and methodologies varied wildly for a while until the idea of a centralized process emerged: wireframing.

Wireframes were introduced to illustrate placement of content, how pages will be organized and basic user interactions. In waterfall workflows, wireframes do this: define everything, including structure, content, design and development. Who creates them has long been a fuzzy deal because they are most often created by a single person who uses them to define the rest of the process, to the cost of not getting the best input from the team.

Sometimes this might be an information architect who focuses on the relationship between information, content and business categories. Sometimes it’s a designer focused on visual relationships and aesthetics, but there are other scenarios, too, all typically misaligned with getting the best the team has to offer.

In any case, what wireframes do not do is this: create a VISION for the team.

The primary problem with wireframes is this:

Wireframes give too much information, way too early and, because they are too often the first thing a stakeholder approves, it locks in decisions in which designers and developers should have been involved.

Wireframing cuts the design team out of the design process. Only after all the most important decisions have been made by a single person is the team permitted to begin their work. This limits everyone involved from exercising their creativity and from building a shared vision.

Compared to more dynamic processes, such as building simple prototypes that take a fraction of the time to build, the static and isolated processes of creating wireframes are incapable of demonstrating interactions and instead attempt to describe them and require heavy explanation that leaves clients with eyes crossed and frustrations beginning to build.

SILO’d PROCESSES = ONE WAY COMMUNICATION

The wireframes are created in isolation then handed to a designer (along with an explanation of all the decisions that have already been made) to translate them into something that actually looks like colorful, pleasing and friendly-to-use Web pages. Then they get passed to the development team to actually build (along with more explanation about why decisions were already made).

Communication using this methodology is one-way. The same problems always emerge. Members of the team downstream feel they’ve been cut out of key decisions. Key decisions in the overall design. Wireframes are designed to be prescriptive. Designers are given these paint-by-numbers drafts to essentially paint over the wireframe. This produces derivative work and limits design teams’ collective power to problem solve based on each project and create work they believe in. This is reflected in the team’s energy in front of the client, too.

Depending on the complexity of a project, wireframes also need to be heavily annotated, and the resulting documentation as part of requirements and specifications can get unwieldy. Team members downstream need to have a clue but people don’t interpret documentation well and, try as we may, describing the functionality of complex interactions is challenging, to say the least.

Then, wireframes are passed to designers, who then pass their iterations to developers, who receive the mother lode of documentation from everyone and their Aunt Jane. By this time, the wireframes are already being changed. Wireframes become moving targets very quickly and create a cycle of revisions where the team upstream gets out of sync with everyone else.

I haven’t ever once heard clients praise wireframes, not like they mean it. Nor have I ever met a designer who loves spending hours on wireframes. It may have made sense ten years ago to include the wireframe in a Web design process as a rule. Now, it only makes sense as an internal tool, when occasionally needed. It’s time to let wireframes die, already, and here’s why.

PROTOTYPING AS DECENTRALIZATION (or DIT)

Prototyping, in contrast to wireframing, solves communication challenges across disciplines and creates better outcomes.

In prototyping, the process is not as inflexible and does not isolate decision-making because creation and design decisions are made as a team.

Prototyping is quicker, too, because it doesn’t require that everything is decided on and/or created at once, only what’s necessary — just enough to gather client feedback without dragging them down into every single unnecessary detail.

Another advantage of prototyping is creating systems, an approach that designs for problems holistically instead of focusing on designing a single page at a time. Especially if we have already created a couple of projects, start-to-finish, this approach allows components to be reused across entirely new sites.

Prototyping also creates less waste. Wireframing gets everyone out of sync a lot. All the back and forth to get back into sync burns up time and resources. When the team is riding the same wave, a la prototyping, the resources invested in the process are more focused and there is less time wasted on back and forth to solve for being out-of-sync. Being in sync creates less waste, which also optimizes margins.

Prototypes are their own specifications. HTML is the best documentation tool. Stuff that might otherwise be isolated into a Word document instead goes into a single location where it inherits better and better annotations and comments throughout the process.

Building prototypes at the front-end empowers all the disciplines to work together, combining their strengths and side-stepping weaknesses by working together, learning from each other and improving the process as a single organism.

Prototypes allow the team to quickly iterate and validate their design decisions and gather feedback from something that makes the most sense to clients. Iterations are simple HTML, CSS and JavaScript with little aesthetic, at first. Focusing initially on content and functionality won’t distract clients, improves communication and team morale by getting something built that everyone can relate to and that begins to build a collective VISION.

THIS IS HOW WE DO IT

“Okay, sounds great,” you say? How do we do it? Here’s something to try:

1. Strategists interview stakeholders and define needs. The needs may require more or less user research, stories, personas and content, depending on complexity. This information is collected quickly, synthesized and shared with the team to make design decisions.

2. Wireframes exist to create structure but sketching works better, faster, plus anybody can do it. Sketching sessions explore concepts with the team before they are committed to the client and/or code. It can be done in notebooks, on whiteboards, sticky notes, napkins or digital sketching tools.

3. Create aesthetics separately from structure and not full mockups, rather only minimal artifacts, just enough to transmit the bigger idea. These artifacts illustrate color, typography and general concepts with a focus on brand. Too much detail derails huddles with clients by drawing focus to pieces that aren’t as important. Instead, draw attention to style tiles and explore ideas, including clients in the process but giving them a framework within which to absorb it all in a friendly and guided way. This also allows the team to abstract a design system that can be used as a style guide moving forward.

4. Sketches are then iterated in HTML, CSS, and JavaScript using existing code. Again, aesthetics aren’t yet necessary and our discussions now focus on interactions, usability, and the flow of content. Iterated initially as a bunch of gray boxes without aesthetics, as the design system (colors, grids, typography, etc) is decided and completed, they are themed in CSS. Ready to show the client!

As a result, the collective is empowered to do their best work, reduce waste and deliver more and in more meaningful ways.