Testing & Going Live – What WebDev Projects Really Look Like, Part 7

Submitted by Sam Moore on Thu, 01/14/2021 - 13:48
WebDev testing and going live

Having moved through the initial creative and production processes, now’s the time to test your work in the real world.

Testing – Round 1

  • Often, testing is only done by site owners, but end users should be put in front of the site, too, before it’s considered launch-ready.
  • Behavioral testing is a huge part of this practice: “If I click this, that should happen.”
  • Behavior-driven Web development is becoming the norm, through practices such as BEHAT. This is an open source Behavior-Driven Development framework for PHP. It’s a tool to support you in delivering software that matters, through continuous communication, deliberate discovery and test-automation. It’s essentially a series of “if-then” scenarios.

Review and Going Live

  • Only after your draft site is put through its paces against these tests should you allow the client to review it.
  • Either make requested revisions or explain to the client why the site should remain as is, then take the site live.

Coding & Marketing – What WebDev Projects Really Look Like, Part 6

Submitted by Sam Moore on Thu, 01/07/2021 - 13:46
coding and marketing

Now you’re ready to tackle the backend coding that brings creative concepts to life. Coders must be mindful of the ways our work can help or hinder our marketing team members’ efforts. Always, this must be driven by the foundation of empathy for the user.

Tech and Usability Design & Coding
We need to make sure we can afford users the pathways they need. We must allow for anything they may need to revise: Typos, number of units ordered, etc. on eCommerce sites; save your work and start over, etc. on other types of interfaces.

Functionality Coding
Sometimes functionality drives the interface, but to the extent that we have control over how things work, we need to make sure that if users press the wrong button, they get feedback. Concise but gentle and understandable guidance is key to a successful user experience.

Marketing & SEO

  • How much do content editors need to know about keywords and the organization's search strategy?
  • Do they need to learn to create content that's in line with the marketing department's priorities?
  • If so, who will provide that guidance: a brand strategist, a guidebook?
  • Will there be a content approval process? Who will be responsible for that?

Graphic & UX Design – What WebDev Projects Really Look Like, Part 5

Submitted by Sam Moore on Thu, 12/31/2020 - 13:41
WebDev Projects

The tenets of good user design fill at least a dozen books, and there will be more. This discipline grows in importance as retail moves more and more online. The learning curve was already picking up speed, but since the rise of the coronavirus and COVID-19, that speed has grown exponentially. We must grow with it, if we are to keep ahead of the very real needs of site users.

  • Graphic design is critical to every item seen by the site visitor, from the overall page template, fonts and color scheme to the look of buttons and other repeating elements. The person responsible for this should have a good balance of experience and knowledge in both 2D design and how that applies to an interactive, virtual experience.
  • User Experience (UX) design applies to everything from micro-interactions to the whole customer success journey. You test it by walking through the actual process a site visitor must go through. Then ask yourself: How hard was it to do what the fictional user wanted to do? How many hoops do you have to jump through? Could any of them be eliminated or made simpler? Do systems collaborate with each other smoothly?

Content Writing and Assembly – What WebDev Projects Really Look Like, Part 4

Submitted by Sam Moore on Wed, 12/23/2020 - 11:18
content writing and assembly

Now that you’ve moved through the Visual & Structural Layout, the next step in a thoroughly planned webdev project includes:

Content Writing and Assembly 

  • Who will be the actual generator of points to be covered? Will it be a subject expert, or will a dedicated writer do the research and interviews needed? 
  • Then who will write up final content?
  • Will that person actually post it to the site, or will that task be passed on to someone with more technical knowledge and comfort?

Content Editing 

  • Are end users subject to moderation in some way, such as legal representatives or guardians of proprietary data or practices? 
  • Does someone need to review or vet the content before it goes live? This is a good time to understand exactly how your particular client’s content workflow will look, especially if this will be an ongoing issue.

Content Workflow

  • This should not just organically happen. It needs to be designed as surely as the content itself, if the process is to be sustainable. 
  • Figure out a content workflow that makes sense. Consider realistic scheduling and establish reasonable turnaround expectations among all team members.

Layout – What WebDev Projects Really Look Like, Part 3

Submitted by Sam Moore on Thu, 12/17/2020 - 11:13
What Web Dev Really Looks Like

Once the planning phase of the project is completed, you move to the first creative production work.

Visual & Structural Layout
The best way to start this phase is to ask a number of questions about the salient points of the site's graphic/visual appearance, and its structural requirements.

  • Is the UI visually attractive? Get inspired with the resources at Mockplus
  • Might some users be visually challenged? (This includes colorblindness, partial impairment due to eye injury or macular degeneration, etc.) How can we use visual cues to help people find their way through the site? 
  • How can we make sure nothing important is buried or ambiguous?
  • Does the layout have a consistent appearance?
  • Is the physical location of a visual cue consistent?

You will undoubtedly come up with questions of your own, especially if you tend to work in very specialized fields. But these questions again give you a place to start. The process will continue in our next post. 

Quoting & Planning – What WebDev Projects Really Look Like, Part 2

Submitted by Sam Moore on Thu, 12/10/2020 - 15:08
Quote and Planning

Quoting & Planning – What WebDev Projects Really Look Like, Part 2
After you've gotten through the Discovery process to find out what your objectives should really be for a webdev project, next steps include:

Quote Submission

  • Your "quote" should actually be more of an estimate. We're all familiar with the concept of "scope creep" and—as with any act of creation—it rarely ends up being exactly what we anticipate. Allow yourself flexibility to compensate for this next point:
  • Allocate enough time and money for concepting and ideating about UX and testing, and reworking things according to what you find out during testing.
  • With any quote, you are setting client expectations. Write it with the thought in mind that you will need to stick to whatever promises you express or imply, so leave room to over-deliver.
  • Check out Muffin Group's great web design suggestions and quotation templates to figure out the best way to price your services.


  • If you're going to put the project in front of end users and act on feedback (and hopefully you are), you need to plan for the time and money to do this. All sustainable webdev projects are iterative.

This takes us up to the start of creative production work, which we'll cover in our next post.

Ready To Start – What WebDev Projects Really Look Like, Part 1

Submitted by Sam Moore on Thu, 12/03/2020 - 15:03
Ready to Start Webdv

A Place to Start

There are any number of ways to start a web development project, but all contain the following basic functions. They tend to occur in pretty much the same order, though there can be some back-and-forth between stages during the development process.

In this and the next few posts, we'll offer our suggestions on how to break down the process into something relatively replicable. This makes it so much easier to plan and cost each webdev project.

Discovery This is where you gather the requirements of your project.

  • What, exactly, are you trying to build?
  • What do you want it to do?
  • How does it fit into your business?
  • Know thine client: If their content creators and editors are not tech-oriented, you need to know that from the beginning. It's hard to bolt on helpful functionality at project's end.

If you're comfortable with the concept of mind-mapping a challenge, there are some excellent examples at Mindmeister.com. Even if you've never done a mind map before, this site is like a large handholding exercise in the process.

Mindmeister will walk you, step by step, through the creation of your own mind map for each potential webdev project. It will take you from beginning to end of the discovery process, right up to the point when you're ready to pitch the project with a cost estimate.

Defining the Internal User/Content Editor With A Persona Story

Submitted by Sam Moore on Thu, 11/26/2020 - 15:55
User Persona

In our last post, we discussed the need for our marketing departments to create Persona Stories to build the representative fictitious Internal User/Content Editor(s) for which we will be designing the UX of any new website project. Here, we’ll outline the questions through which to build such a Persona Story. 

It’s important to remember that, especially in enterprise-level organizations, there may be more than one and even several Internal Users/Content Editors. There must be Persona Stories for each of them, if we’re to create an effective UX. To develop these pseudo-personality profiles/needs assessments, we need to ask a set of questions that will determine our direction.  

These include:  

  • Who are the users? – There might be more than one set. For example, in a healthcare setting, they might be:
    • patients and family members (End Users/Customers)
    • referring doctors (Internal Users, possible Content Editors)
    • nurses/clericals (Internal Users, Content Editors)
    • potential residents and fellows (External Users)


  • What are each of their needs, and levels of sophistication?


  • What are their skill sets regarding the Web or CMS?


  • What’s their frustration level with current Web tools?


  • What kind of time do they have available for content editing?


  • How will they need to interact? How can that interaction be scheduled or otherwise made consistent, able to be anticipated and fit in a workflow that’s as least disruptive for all parties as possible?


  • Do they have digital assets, or will those have to come from some other source
    • Copy
    • Will they be writing their own text, or will someone be doing that for them?
    • Will they be responsible for editing and proofing, or will someone else do that?
    • Will they be writing in a word processor and just providing files?
    • If they will be writing directly into the user interface of the CMS, they will need to focus on writing and ignore the tool.
    • Photos, Illustrations and Video Media
    • How many will be needed?
    • Do they need scale and crop tools internally, or do they have a graphics department to use?
    • If they use stock services, which ones?
    • Who will manage those accounts for access and payment?
    • Who will actually search for, find and download those images?
    • Audio Clips
    • What will audio be used for?
    • Who will provide it?
    • It will need to be edited and ready for uploading to the site. Who will make that happen?
    • Asset Management
    • What tool(s) will be used to place, store and archive digital assets?
    • In what location will the files be stored?
    • How will they be backed up?

This is really just a starting place. Every webdev project will have its own needs, and every developer will have their own process. But these are some basic points from which to launch your own.  

Defining Users for Good UX Design Requires Good Research

Submitted by Sam Moore on Thu, 11/19/2020 - 15:48
Define Users

In our last post, we discussed the need to recognize that there are two real users we’re designing for in a webdev project: Internal Content Editors and External End Users. 

Web developers must serve each of these user sets, so the users must be defined in as much detail as possible, to set up the needs and expectations of each, which we will use as our design requirements. We call this the Discovery process. 

External Users – End Users/Customers

The site's external end users may belong to a monolithic group, but more likely, they will belong to several subsets, differentiated in terms relevant to the client/site owner’s business or purpose. Your marketing department should research and create a Customer Profile for each subset of typical customers.

  • These profiles should be generated using known demographic information as much as possible. Relevant demographics will change according to client needs.

  • Other salient points about them will have to remain conjecture, until use of the new site reveals observable data about external users.

  • When building the project timeline, the webdev project manager should be tapped to follow up on this information, which should help determine anticipated needs and desires for the website's ongoing features and functionality. This way, all future updates are based on actual feedback.

Internal Users – Content Editors

In reality, the Internal User is the first one to consider, because the content editor will be the first one to use the site before actual customers do. They will be inputting and updating text, images and media before the customer ever sees it, so they are key to the success of the site.

  • Because there can be several levels of internal users, each should be represented by a Persona Story, also created by your Marketing department.
  • A Persona Story is a pseudo-personality profile and needs assessment that will help determine the features and functionalities needed on the site.  

We’ll cover the questions used to build the Persona Story in our next post.

Good UX Design Starts With Defining Users

Submitted by Sam Moore on Wed, 11/11/2020 - 22:09
define for users

When we start a webdev project, good UX design must be foremost in our minds from the beginning. And good UX design begins with empathy: We must design the entire user experience to fit the type of person who will be using it most. This determines who we’re really working for. The client may be paying for your time and expertise, but the real “boss” — the one driving our decisions and choice s— is the user. So it’s necessary to define our actual user base. 

For any website, there are actually two main types of users:

  1. External (Customers/End users)

  2. Internal (Content Editors)

Every web designer knows of and thinks about the first category, the end user. But if we’re going to be designing for successful, long-life websites, we need to consider the fact that all such sites will be continually updated at least with content, if not functionality. That means someone inside the client’s organization, or at least someone contracted by them, will also be using the site from the back end.

Web developers need to build interfaces to function well, for visual attractiveness, and clean coding. They must serve each of these user sets, so the users must be defined in as much detail as possible, to set up expectations. We’ll discuss specifics in our next post.