We start all new relationships with a few good conversations. We want to be sure we're the right partners to work together. You do your due diligence and we'll do ours. The world of design and technology is so vast, there are just certain things we're not well suited for, or don't do. If this is the case we'll be sure to let you know.
Request For Proposals (RFP's) and pitches are so 2010 (but sometimes unavoidable). We'd much rather sit down and talk about what you want, and how our expertise can help. In our experience a detailed and honest discussion over some tea or coffee provides more insights, solutions, and value to you. Often times replacing the need for extensive RFP type paperwork. We'll share past experiences that are relevant and brainstorm as much as you want. By the time we're finished we both should have a much clearer idea of the direction we all should be heading.
Once a project starts we'll set up the folks we will be working with on our online project management tools. These are not complex, but increase efficiencies. It make sense to invest a couple of hours getting set up on the right foot. Our process is flexible and it keeps us all moving in the right direction.
Ok, now let's get started building something amazing. An overview of our framework follows:
In a nutshell this is where you tell us EVERYTHING you know. What the project is, what it isn't. What are the dependencies. Who's involved. Who is going to use it, etc. We will talk a lot, we'll ask questions. And then we'll ask some more.
We then build documents with all the information, emotion and data collected during Discovery. This becomes the written foundation for what we're building. The main deliverable is a Requirements document that details the application specifications. We'll also build some greyscale page wireframes, site maps, logic flows. Whatever is needed to communicate the functionality and user experience of the application. Presenting the wireframes as a clickable prototype helps visualize how the final product will feel.
This is all about planning the technology behind the experience, in the same way an architect specifies construction methods and materials to build a house. What programming language, frameworks and tools will we use. How we weave together all these pieces defines the application architecture. This is dependent on having clear, and finalized requirements from the previous phase.
Everything that has happened before feeds the visual design. All the documentation, plans and flowcharts evolve into the user interface. This is where we combine your brand language into the build. A creative expression that makes sense to the audience. Something to look at that everyone loves, and serving the functional objectives.
What's the content (text, images, video, audio) going to be? Who's responsible for creating it? Where does it live on the website or application? If it shows up in many places how are those connections made? Every project is unique when it comes to content. It requires a strategy behind it.
We have Technical Development and Creative Production. Developers code and designers build the approved designs and specifications.
The technical lead ensures that all the functional bits and pieces work together without conflict. We save code in the cloud, back it up, and keep logs of everything that happens to it. We build on development servers and provide separate servers for QA and UAT (see below for what those mean). We have front-end specialists (what you interact with in a browser). And back-end specialists (behind the scenes functionality and data storage).
The creative team produces everything needed to bring the designs to life. Graphics, illustration, video, 3D design, motion graphics and image retouching, are some of what happens. We have a myriad of tools and disciplines that complete the visual experience.
Before the client sees what we built, it goes through internal QA. This is where we make sure it works as expected, and removes the client team from having to do QA of their own. They just review the functionality to ensure it's what everyone had envisioned.
This is when a sampling of actual users review the application. This should be the last phase of testing. In reality though everyone has opinions and needs once they start using software. At this point it is our job to define: What are bugs that need fixing now. Added functions that will get built in a later phase. New ideas that fall outside the original scope. Training opportunities (why doesn't it do ______?).
Launches are not an end point. They are the beginning of a new life that needs care and nurturing. Once everything works and is stable we go live on Production servers. This is cause for celebration but the work involved to maintain a live application or website can be a surprise to the client. We want to set expectations.
A custom support agreement defines the best way to nurture and build upon what we just launched. These can include any combination of the following:
Customer/User Support Systems (help desks, documentation, who to call)
Analytics & Improvements
After doing this for so many years it is the rare project (usually a very small one) that does not need ongoing support. Either to help the client get familiar with a new system. Or to look for improvement opportunities and add them. So of course, we do that too.
See how we’ve helped some existing clients.