Discovery in the Web World

The discovery process has been growing and adapting for years in the creative world. It seems that UX and design studios have mastered discovery process, research, and synthesis of captured of information into a valuable product for clients—all while making a tidy profit. While there are countless processes, books, and blog articles for discovery in creative fields, there’s far less available information about discovery for the web. How does this valuable process translate in the world of websites, apps, and technology? I posed this question in one of our GRupal sessions this spring, and we explored different discovery possibilities for the web.

What to discover?

Let me preface this by saying that I am a huge advocate for collaborative discovery. I firmly believe that the discovery process should be done together with the client, not behind closed doors. Engaging in discovery meetings and exercises with the client helps them have mutual responsibility and accountability for the outcome. With client collaboration up front, it’s easer to understand and remain aligned with the project vision and goals. While this discovery can mean something very different for a web project versus a UX or static design project, it is still important for a successful outcome.

Discovery for web needs to be a blend of design, user, and technological information. Discovery for web is just as important of an internal process for a web studio as it is a value-add for a client. As valuable as design and user research can be for a project, there are many practical elements that need to be analyzed and synthesized in order to create an effective solution. For a living project like a website that will continue to change and evolve after its launch, function is just as important as form, if not more so. A designer should always be able to answer yes to the question, “is what I’m designing possible to execute cleanly and well?” A developer needs to be able to fully understand the intention of the client and the design and UX involved so they can come up with the best solution for implementation. Figuring out all of the relationships between these can be key to a great discovery process, both for studio needs and a great viable product that can be delivered to the client.

I have also found it beneficial to plan out communication details during a discovery phase. This can help clear up ambiguity of who has sign off potential and schedule regular checkins with the client to help keep the project within scope and moving along on a good timeline. Without these things in place and agreed upon by both sides, there is potential for scope creep or disagreements on budget and project completion that are a headache for all. It also helps keep both sides accountable as well as the project progresses.

Elements of our discovery process

Here at Rapid, we have been working to develop and hone our own discovery work, and have come up with some key elements of the process that we can gather information from, looking at form and function together. 

Users

Users are key to a website’s success or failure. Not only does the user experience need to be planned out and designed, but it also translates technically in terms of user hierarchy and access. Considering user archetypes and their web preferences and habits can drive design decisions and make an easy relatable product. Much of this information can drive a client-facing report product as well, as it helps drive the visual outlining of user paths and design options.

Site Features

Knowing what features are required is key for budgeting and successful implementation. It helps designers know what to mock up or plan out, and developers know what technologies, platforms, plugins, etc. are required. Getting an idea of these features can also help to drive a more accurate budget and scope. For Drupal or other content-driven sites, ERD (entity relationship diagram) mapping can be useful to help determine content types taxonomies, and other elements as well as how they need to be built to relate to one another.

Sort Priorities

This is key for both the client and for us. It really helps with the project scope and to define a ‘launch-ready’ viable product. In other words, “what are the actual requirements to make this a functional website that accomplishes the client’s goals?” Most of the time there is a difference between this and a product with all the bells and whistles. We’ve found it helpful to sort the features into a few categories that in the process identifies the launch-ready product, elements for a future phase of the project, and gray-area items that clients want but may not include in the first phase based on budget, time, or complexity restraints.

Project Particulars

There are endless design and technical questions that could be posed here. Are the designs provided or do they have to be created? Are we working with established design standards? What are the hosting, SSL, and devOps requirements? What kind of analytics or third-party integrations might be needed? What level of flexibility does the CMS need to have for client admins? When conducting discovery, getting answers to as many of these questions as possible up front can help prevent the project from being blocked later on.

Final thoughts

At the end of the day, web discovery should be a practical tool that aids smooth and efficient project implementation. It shouldn’t just be some research and a report that you give back to the client with a “ta da!” and proceed to charge $40,000. Discovery should be useful not only for clients, but also for designers and developers. With collaborative discovery that covers both form and function, web firms can collect and synthesize valuable information into a valuable, profitable product for the client as well as the basis for internal project workflow.