Legal & Accessibility – What WebDev Projects Really Look Like, Part 9

Submitted by Sam Moore on Thu, 01/28/2021 - 10:26
Image
Legal & Accessibility in Websites

After all the creative work is finished, there are many administrative loose ends to tie up before your webdev project is completed:

Governance

Content created for posting on a website must be legal. This is especially critical for pharmaceutical, financial, healthcare, legal, liquor sales – any industry that requires a legal department. General industry compliance doesn’t always indicate content is approved for website use. You could create a workflow system in which new content gets posted as draft for approval, then gets published after legal authorization. However you handle it, you need to really pay attention to the legal factor.

Accessibility

Content editors may have challenges: Maybe they can’t use a mouse, have vision issues, are hearing impaired. Know your internal and external user population. In general, it's always best to implement good accessibility into any interface. There are quite a few resources to help guide you, and w3.org is a great place to start.

Training – What WebDev Projects Really Look Like, Part 8

Submitted by Sam Moore on Thu, 01/21/2021 - 13:53
Image
WebDev Training

With the site now live in its first complete iteration, it’s time to provide training to whoever’s job it is to update and maintain the site.

Documentation!
When handing the site over to the client’s IT department and content creators/editors, you need to provide documentation on how to perform necessary tasks. Match your options to deliver documentation to their strengths:

  • In person
  • Written
  • Videos/Recorded webinars
  • Powerpoint with screen shots – Standalone or attached to the back end of the site itself, prompted through pop-ups or icons.

The important part is that the guidance system you design be flexible. As always, put the user first in designing this.

  • What do internal users like?
  • Get comfortable with the idea that you may need to come in to revise it later.
  • One proven method of client training is the creation of a “Mentoring Model:” Train one client staff member who is good at training to teach the rest. In the best of cases, this can leverage the positive efficiencies of “hive mind.”

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

Submitted by Sam Moore on Thu, 01/14/2021 - 13:48
Image
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
Image
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
Image
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
Image
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
Image
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
Image
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.

Planning

  • 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
Image
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
Image
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.