Page: A 7-step digital development workflow (7SD)

The Flow (7SD)

1. Purpose, Pu
2. Journeys, Jo
3. Structure, St
4. Content, Co
5. Visualizations, Vi
6. Assembly, As
7. Upkeep, Up

Baseline Assumptions

1. We speak of “client” (the one to report to) and “contractor” (like K16E handling the website)
2. We approximate the product or project as “website” since 7SD was really born of K16E’s website projects, where we tend to have a greater amount of client-contractor interactions and task assignments
3. We have chosen to call the rubric and its graphic 7SD
4. This article, as with any other filed under Workflows only makes a presentation of “what is” and consequent interactions between client and contractor. More “how-to” materials are to come.

Purpose, Pu

Client should document a purpose for the website. Purpose can then be followed up with a set of goals that client hopes to achieve.

From the very kick-off meeting, establishing Purpose, Pu should be #1 priority, and neither contractor nor client should proceed to anything else till a clear purpose and achievable set of goals are documented and signed-off on. If we know what we’re building we must equally agree on and easily articulate why we’re building it.

Before you can establish the journeys you think or know or want or expect people to take to get to their desired destination with your website, these journeys have to be anchored on your purpose and goals, your expectations. Because how else would you measure success?

Purpose, Pu falls into the non-intersecting set in 7SD with 100% responsibility of creating it on client. While contractor can help here, this is really the client’s time to shine, to show that they know what they’re asking for.

Discussions

1. When to have a Purpose, Pu conversation?
2. How to have a Purpose, Pu conversation and how and where should Purpose, Pu be documented and archived for shared reference?
3. Can the Purpose of the website change midway or at some point during or after development? If yes, how should that affect the process or outcome?
4. How do you state and make sense of Purpose, Pu? What all is involved in doing so?
5. Can Purpose, Pu be framed as/like a “problem statement”, describing what needs to be addressed, and possibly followed with some “value proposition”, establishing to potential users why they would/should need the website?
6. Can Purpose, Pu self-point and define in itself what would be a measure of success or effectiveness? By how much?

Journeys, Jo

If the question of what you want people to do as well as why is answered, the very next one is how do you want them to get there, to your purpose, on the website? Where might visitors be coming from? Where might they land first? What should they see first? How should they interact with the website?

Then what, where? Where should they go next? How would you get them there, how might they get there (by you leading them or as self-directed) and eventually to take the action you desire them to? These are journey questions, which we need to establish, to delineate.

Journeys, Jo start out as guesses or preliminary interpretations from data (or findings) that the client has about their product or company. They’re very predictive in nature but can be accurate, if Client (or Contractor) has good knowledge of the users. Eventually, when the project has been live, analytics data can help make these journeys even more scientific, as insights will have been gained — (a case of Upkeep, Up interplaying with Journeys, Jo). But even before analytics data starts filtering through, some clear and easy to reason about journeys for the design must be established.

Sections of pages and the pages themselves emanate from a grasp of these journeys. Even manners of design during Visualizations, Vi may be dictated by Journeys, Jo. So, delineating journeys is equally as important as documenting purpose(s) and goals.

Journeys, Jo falls in the non-intersecting set of 7SD with responsibility fully on client. Client can be assisted by contractor. But in the case where client waves responsibility, contractor has an opportunity to reflect it in their contract/billing.

Discussions

1. How much should be involved in the delineation of “user” journeys?
2. How detailed should Journeys, Jo be? Detail can be tested in terms of multiples of user flows drawn (a tangible UX deliverable or artifact [if activity is guided by Contractor]).
3. Can and how can journeys be tested?
4. Can Journeys, Jo expose a possible folly in Purpose, Po? If so, should Purpose, Po be redone or both steps invalidated and thoroughly reviewed?
5. How can Client or Contractor avoid “designer bias” in doing Journeys, Jo since the website is yet to be done at this point and tested with real users?
6. How much consideration to accessibility (including a good range of users with disability) should be made while doing Journeys, Jo?
7. Is there a rubric to score a user journey at this stage? How do we know when/if a map of such journey(s) is sufficient?

It’s worth noting that user journeys here may be based mainly on assumptions about the intended website. However, such assumptions would closely approximate reality eventually if some secondary research is done (into how things might look with similar website) before they’re concluded on. It’s also possible to conduct surveys in order to gather quantitative findings about some of these understood journeys.

Structure, St

Structure, St is the organized listing (and delineation) of all the pages (or “screens”) and sections of pages, including external links and their titles, constituting the website. Structure, St can incorporate user behaviors defined in Journeys, Jo and contextual decision points in flows. As a blueprint, Structure, St fully accommodates delineated journeys and stated purpose(s) and goals. It is the whole website on one page!

Structure, St captures all of Journeys, Jo and presents the skeleton to be fleshed out with Content, Co. Although Structure can be returned to and updated, it leaves no guesswork regarding the website. Structure, St is an exercise in “information architecture”.

Presumably, one should be able to understand and state the purpose(s) and journeys of the website from just looking at the structure. Stakeholders should at this point see that the website design has captured the stated purpose(s) and goals and be able to understand what content and/or types of content to produce.

Structure, St falls in the non-intersecting set of 7SD with 100% responsibility on contractor. While the client/company can help here, this is the contractor’s great opportunity to prove their in-touchness with the website.

Discussions

1. What key/core pages seem apparent from Journeys, Jo?
2. What other pages (or sections) of the website may lead to or succeed from these core pages in order to fulfill a journey or two?
3. How should seemingly isolated but equally needed pages be placed to relate with core pages, even external pages that are to be linked to?
4. Might other pages be added that are optional but good to have in keeping with obvious industry standards?
5. Can the additions (as in #4) be justified?

Content, Co

Content, Co is the ultimate step in the flow and sits in the middle of 7SD. It’s what people are coming to the website for — information, to learn/know something. It’s mostly the written work that forms the bedrock of the website. Content, Co interprets and communicates all preceding steps of 7SD, as if these ones only exist first because of it.

So, fittingly, Content, Co draws on purpose, journeys, and structure to become the right messaging of the website and what persuades visitors (or buyers) to take the action they’re invited to (again, by Content, Co, as “calls-to-action” rightly are content). Still fitting, Content, Co feeds the website’s visualizations, which are themselves “content” except distinct enough to warrant a step of their own — more or less the “visual assets”.

Still yet worth noting that Content, Co should be the inspiration for what design direction is ultimately chosen during Assembly, As. It’s such a decent coincidence that Content, Co straddles an equal portion to the leading and trailing edges of 7SD — it makes or breaks any digital project.

Content, Co falls in the intersecting set of 7SD and is a shared client-contractor responsibility, with contractor providing guidelines and guidance. Client may have in-house resource to write their content or outsource this responsibility to contractor.

Discussions

1. Who will create, measure, and maintain content?
2. Will above party be available for when additional formats of content might be needed? This scenario likely happens when during Visualizations, Vi formats considered best to meet users’ needs may then require additional content or context.
3. How should content be structured, tagged, written, and organized with “on-page SEO” in mind?

Visualizations, Vi

We want to visualize (depict, complement/supplement) mostly text-based content with more easier to grasp and appealing graphics. Visualizations, Vi will produce images, image-treatments, postcards, vector graphic elements, illustrations, animations, videos, charts, etc. Generally, visualizations (or visuals created) are regarded as “assets”. That is, visual assets, as opposed to other digital assets in web design such as fonts, styles, and scripts.

At this step, the client’s design system gets called up. If none, then a quick one can be collaborated on and created as a good reference for the rest of the design work. This reference is more like a “design style guide”. Depending on the size of the client’s company and/or project needs, a more thorough design system can be produced as a separate activity/project. All assets eventually created can then be based fully on the design system.

Of course, any design system has at its heart the client’s brand. Now does the client have a defined brand, then it already has some kind of design system (brand appearance guidelines, for example). Otherwise, creation of a brand identity (system) should be discussed. A “brand style guide” can be created ad hoc here or done as part of the foregoing design style guide.

Visualizations, Vi in 7SD falls in the intersection zone, responsibility to be shared between contractor and client, as an ideal scenario. If client waves 100% responsibility to contractor, then that should affect how the project is billed.

Discussions

1. Is the context of all content to depict understood, and can it or has it been documented? It’s good practice to create visuals from “text drafts”, more like scripts for a scene. This document can be called a “visualizations brief”.
2. Is their a brand identity or design system available? If not, can a “styleguide” be put together first?
3. Will all assets be created from scratch? Think of fonts and some intricate illustrations. Or will the work already done by other creators be leveraged and adjusted to fit client’s brand and website needs?
4. Are the assets or visual elements created consistent with the established “tenets” in the brand style guide as regards color scheme, imagery, and typeface, etc?
5. Some Visualizations, Vi work can/should/may only be done in code (certain scroll-driven animations, for example). Although such visuals may come later in the steps, they should then be documented in the Visualizations Brief. Thus, future potential visualizations (or animations, in this instance) can be based on brand justification, artifact.

Assembly, As

You establish a purpose for the website. You delineate the different (even varied) journeys potentials or users are on and may take to get to the website (and possibly while on it). And then you map a structure satisfying those journeys, guiding users to desired actions (the website’s overarching goals in mind).

You then give body to structure with content, which, of course, is consistent with your purpose and brand. Then you bring content to life with fitting visuals, making them pop to users, as you gear toward fun in function.

And, finally, you assemble them, applying good design principles — concerning yourself with composition and styles that gel with content and visuals, which themselves tell a story aligning with the purpose and goals of the website.

There’s typically two phases of Assembly, As — prototyping (in a tool like Figma) and coding (with a web framework like Astro). These two divisions (which coalesce to one in a tool like Webflow) are the funnest 7SD step for practitioners. But there’s need for caution not to rush to Assembly, As no matter how tempting.

Assembly, As must be treated as a step in web design, and not the web design as a whole. Otherwise, contractor runs the risk of producing a beautiful website that converts zero visitors, achieves no goals for client. Even if some quick sketches or prototyping is done early on, such outcome should only be useful as a coincidence of entire 7SD followed in lockstep, not that of the process being bent just to fit some idea of design.

Discussions

1. Are preliminary sketches done to capture structure enough? One way to know is to check if all “top tasks” as identified in journeys surfaced. Does the final prototype pass the “top-tasks test”? A pass means these tasks are successful, leave users satisfied, and lead to the main call or calls to action of the site.

Behind the scenes

• I wanted each step to be reduced to one most representative word
• I didn’t want any procedure to clash in the two-character abbreviation for itself
• I wanted to represent each procedure by a two-character, Periodic Table-style lettering (a preference just for the fun of it)
• “Writing, Wr” became so instead of “Content” because Content clashed with “Composition” [Co]. But writing eventually reverted to “Content, Co” when I dropped composition in favor of “Assembly, As” in later reckoning.
• I really love to call the actual web design “Composition” instead of “Design” since Design would clash with Depictions, and besides, Composition is really what we’re doing — where, I could’ve easily called this “assembling”, because, yes, you get the idea. And, yes, it then came to be called “Assembly, As” because we’re assembling sections on pages and pages into the entire website.
• But I well may go with Assembly, As because Content feels much more befitting than Writing. That is what eventually happened. (See above)
• I really wanted it to be 7 steps, so I added “deployment”, De, which meant I had to redo Depictions to Visualizations, Vi.
• Now, Deployment, De can further talk about what happens to the site going forward, maintenance, post-mortems, etc.
• Well, Deployment, De later on became Upkeep, Up, which I really love because you’ve got to keep the website up after assembling and deploying it, everything that goes into keeping it running for the contribution it makes.

References

1. Content Strategy 101, Anna Kaley, Nielsen Norman Group. Accessed Nov. 03, 2022
2. On-Page SEO: The Definitive Guide, Brian Dean, Backlinko. Accessed Nov. 03, 2022
3. The Comprehensive Guide to Information Architecture, James Pikover, Toptal. Accessed Jun. 16, 2024
4. What is information architecture?, Figma. Accessed Jun. 16, 2024
5. The Difference Between Information Architecture (IA) and Navigation, Jen Cardello, Nielsen Norman Group. Accessed Jun. 16, 2024
6. Visual content creation: strategy, tools, and inspiring examples, Valerie O’Connor, Filestage GmbH. Accessed Jun. 19, 2024
7. Web design explained—key elements and best practices, Figma. Accessed Jun. 16, 2024
8. 7 visual hierarchy principles for web design, Webflow Team, Webflow. Accessed Jun. 23, 2024
9. Macro vs. Micro Conversions, Tim Neusesser, Nielsen Norman Group. Accessed Jul. 22, 2024
10. Level up your UI design skills Start learning Design Systems, Nolan Perkins, YouTube. Accessed Jul. 22, 2024
11. A Lesson on Top Tasks from Hurricane Beryl, Evan Sunwall, Nielsen Norman Group. Accessed Jul. 23, 2024