Alayabox - An accumulation of ideas

Architecting a Lead Acquisition Platform

www.directdegree.com

Approach

Direct marketing on the web is the business of acquiring individual users’ contact information, plus any additional information deemed relevant for a sale. Once stored in a database this information becomes a sales lead, and in marketing a lead is product.  

What makes that product valuable is the applicant’s honesty and accuracy.  Are they honestly giving that information for the purpose of making a purchase? Are they able to interface with the form and accurately key their information? Honesty and accuracy significantly increase when advertising is contextual.

This is the perfect problem for an IA, and I started with the holy trinity of context, content, and users.

Context - In this case it was the online education industry. The timeline was tight. Stakeholders outside of the development department were unresponsive to use-cases and blueprints. They wanted to begin with prototypes. This inflexibility was mitigated by the fact that the project was a redesign. Information could be gleaned from the state of the already present site and stakeholders’ criticism thereof.

Content - Luckily, a wealth of copy already existed. I used this information to create card-sorting exercises that solidified taxonomy amongst team members. This began the basis for keyword research and labeling system development.

Users - With no analytics from previous sites, I was starting from scratch. The search engine marketing team helped as with analytics from their affiliate sites. These findings gave me insight toward basic user demographics, browser stats, and operating systems. These demographics included

 

Strategy

The initial purpose of this site is to funnel users to an offer. From a natural search perspective, we knew our high-traffic item would be articles and information. A content management system was key. This system allowed content experts to link articles to offer categories. This meta-information could be used for future component linking such as video and audio feeds.

Search and browse functionality was nascent of the facets we had chosen. We based our selections on labeling systems of competitive sites and their value in the keyword market. This served two functions, 1) To improve our chances of internal findability  and hence traffic to imbedded ads, and 2) implement a keyword campaign.
Knowing that leads convert at a much higher rate if they are presented contextually, the paradigm was content/offer mapping, and that was the object we set out to achieve. The development departments employed MVC methods using the Symphony framework. Designers used semantic markup and CSS to implement front-end. Wireframes were designed to express class and id labels for elements.

Outcome

The site launched within the deadline. With analytics running on every page, the development team is able to make design and functionality changes that further improved the funneling process. Natural traffic improved and conversion rates increased.

A Custom Workflow System

Approach

In General, the approach was narrowed to three facets,

Context - Because this is an intranet application, the project required heavy research into corporate culture and specific processes.

Content - The defining content in this system is the process queue itself. In order to get the development team out from under the continuous stream of email requests, a queue was necessary. In design the queue was seen as the trunk of the tree. All other views and tasks branched from this concept.

Users - One of the real challenges in designing this system was the variance of users. Besides the web development deparatment, accounting, client services, sales and distribution departments also had to be considered as users and user groups. Use cases and user scenarios were much different from department to department, and the system development had to reflect those differences.

After some preliminary research on workflow as a theory and concept, I decided to use the GTD (Get Things Done) model developed by the David Allen Company as a springboard for development. This model isolates five distinct workflow phases of in an information worker environment.

Collect

Process

Organize

Review

Do

This model allowed us to organize each task by general phases that could later be mapped to the actual business logic.

As with most email-based request systems, the front end development team in my organization was inundated with with an unorganized and relentless request flow. Besides weighing my day with the task of organizing and assigning tasks, managers outside of my department and salesmen themselves were constantly interrupting the team to request information about their projects and processes. Without a centralized queuing system, trackign requests was nearly impossible. The clear solution in this case was a workflow system.

Our first failed approaches were invested in out-of-the-box solutions. In hind-sight, we all knew that our curious production method, and the types of features we would come to demand from a workflow solution, could never be found out-of-box.

I assembled a team which consisted of of 1 back-end developer, 1 designer/front-end developer, and placed myself in charge of information architecture as well as lending some assistance with front end development. The backend was based on the PHP MVC framework, Codeignighter, and standard CSS2 and XHTML 1.0 Transitional were used in development of the front-end.

Strategy

I began this project with some basic flowcharts to describe the flow of 'requests' from one user group to the next. I separated each flowchart by department. These diagrams were intended to unify stakeholders and developers on the particular requirements of information passing. Each group had different data requirements which required different views.

In order to simplify the process, we limited the first stage of development to three departments, accounting, client services and web development.

The following controls were used to indicate success after implementation. These issues were recorded in the time before workflow implementation,

Web development was experiencing a 1/30 failure rate. For every 30 requests made by email, one was completely overlooked.

Decentralized prioritization of tasks done through email and phone call. One manager was unaware of another manager requesting priority. Realistic time estimates were impossible in this environment.

70% of web development supervisor's day spent organizing team tasks and following up with them.

Absolute lack of visibility for all stakeholders in a process.

Outcome

Though it was initially difficult to encourage adoption of the software over sending emails, all three departments fully integrated the use of the software with their actual workflow. After about 6 months of beta testing, a clear need for expansion became apparent as the initial controls were more than satisfied.

Failure rates in finding and completing improved 100%

Prioritization culture of 'most important' for every task was mitigated by visibility among upper-management. Each manager saw the priority of each task and was able to scale their priority to the present expectation. A 1-5 number scale resulted in a manageable heirarchy of priorities.

Web development supervisor was able to free 60% from process organization and prioritization

Visibility obviously improved. Less status requests = more time to work

Intranet Wiki for Department Documentation

Approach

Finding a word document in a directory can be taxing when that directory contains hundreds of documents. Moreover, the versioning of those documents can be a nightmare when multiple users are making edits to documents, saving them under different names and over-writing each other's work. Over time, the documentation becomes deprecated and undependable in content and relevance.

I explored two solutions, a version control system like the one we use for our development projects called SubVersion, and an enterprise wik.

In the end, the Wiki won out because of it's ease of install, built in back-ups and versioning, built in search and indexing, and web accessibility.

Strategy

We used the mediawiki install package on an internal server running Lamp and PHP5. The install was simple. Organizing the documentation was not.

I created a quick taxonomy where the global navigation was labeled by department. Each department link led the user to an alphabetized index of their documentation.

I quickly realized the installed search functionality on mediawiki lacks a great deal. It operates by parsing each document in total scanning for keyword matches. There is no variance in this functionality, so if the user's search term isn't exact, to relevant documents are returned. To remedy this, we began a folksonomy by enabling tagging of documents by associated department and relevant keywords. This workaround enables users to find documents by clicking tags and linking to alphabetized indexes of associated documents.

Outcome

This simple project improved our productivity an indescribable amount. Instead of fishing through emails and corrupted shared-drive word documents, departments are able to find documentation that is version controlled and opened to their revisions.

Though wiki vandalism was a concern at the beginning of the project, no vandalism has occured, one year into the release of the wiki to employees.