A modern website should be clean, simple, and easy to use, right? Well, just like there is a ton going on behind the scenes in even the simplest moment of your favorite TV show, a simple website is likely anything but under the surface.
There is an endless number of questions and scenarios to think through when planning a new site or a rebuild of a current one. For example, does this form need to connect to CRM? Where is the data for this list of clients coming from? What in the world actually happens when you click this button?
It can be intimidating to attempt to capture all of that information so that, 12 months later, when your team is finishing up that last feature, you still remember what it’s supposed to do. That’s why I wanted to share some of my hard-won-by-making-all-the-mistakes experience with you and hopefully make your next discovery project that much more effective.
This first one seems obvious but can be more challenging than you might realize. Why? Because oftentimes, it’s easy for us to categorize some things as “small or trivial” when in reality, they end up becoming very important down the road during implementation.
We’re constantly taking in information from everything around us; way more than our brain can process, so it prunes out information it doesn’t see as important, so you can focus on what is. (Fun fact, did you know that your nose is in your field of vision all the time, but your brain just edits it out, so you don’t see it? Weird, right?). With that level of experience editing information as it comes in, you would think we’d be pretty good at it, but unfortunately, that skill doesn’t quite transfer here. So my rule is to write down way more than I think I should. I can’t tell you the number of times some random off-handed remark that I jotted down was the answer to a question we had weeks or even months later.
Of course, you can’t get it all. Unless you’re a court stenographer, writing everything down is hard and, if you’re doing that, you likely don’t have much bandwidth left over to think through and respond to what is being said. You know the “analyze” part of the Business Analyst title? So if you miss something, don’t beat yourself up. Just make sure to always, always, ALWAYS record the meetings, so you can go back and review them later, remembering that digging through hours of stale conference calls can be time-consuming, so consider it more of a last resort.
More data is only better when it’s the right data. Otherwise, you’re just creating your very own proverbial haystack for yourself to find the proverbial needle in. Thinking through the architecture and taxonomy of your documentation is as important as the architecture and taxonomy of the project itself. Obviously, it is extremely important for a developer to know what a feature needs to do. However, knowing the strategy about why the client decided on that particular shade of blue for the background color of the feature is likely not.
Keep every shred of information you gather filed away somewhere, but be mindful about overwhelming people with lots of information irrelevant to what they need to do. It usually just leads to confusion and opportunities for varying interpretations. As you may be able to tell from this blog post, I rarely use 1 word when 20 will do. That’s not usually a good idea when providing information to a developer to complete a task. Context is great, but it’s rarely necessary to read the whole novel to know how they need the contact form wired up.
I was going to suggest a drinking game where you take a shot for every one of the tools above that you’ve used in the last year, but I care about your safety. Those of us of a certain age might be familiar with the phrase “The truth is out there” from the X-Files. That search for the truth was compelling for a TV show but should not be a feature in your documentation.
So you’ve written down as much as you can. You’ve organized all your notes and recordings. You’ve distilled that information down to focused tasks without too much fluff in their descriptions. But, ultimately, there needs to be a single place that documents the way things are going to work. At BizStream we utilize Jira. Discovery notes and internal meetings turn into tickets and, once the client approves the tickets, those become law. My notes are still there for reference and context, but the Jira ticket trumps everything else (again, once approved by the client).
That doesn’t mean there won’t be external documentation that fills out the information on the tickets. Things such as designs, sanitized test data, and other items that don’t make sense to add to the Jira ticket live in our shared Google Drive. The key here is to link those assets directly to the ticket. That way, there is no question about which design, flowchart, etc., applies to this exact task.
OR
OR
After spending so much time talking about how things should work, taking notes, documenting final decisions, distilling that information into actionable tasks, etc., it might feel a little, well, embarrassing to ask the client for more information. Especially when you know it’s something you previously discussed, but it didn’t make it to the documentation for one reason or another.
In development, we know that doing your best to hit all the acceptance criteria right the first time is far more efficient. Otherwise, you can get into a cycle of back and forth with QA finding bugs and sending them back to the developer, the developer fixing them and sending them back to QA, and then QA spending time re-evaluating those bugs. That is all with the specifics clearly defined and rock solid! Why make a guess, however, educated, at what the client wanted on a certain feature rather than just confirming it with them? Does that mean emailing the client 12 times a day? No. After all is said and done, though, the client is the one paying for something to be built the way they want it to be. So make sure everyone knows what that is.
So none of these concepts are exactly groundbreaking research. They are all pretty common sense things you may have looked at and thought, “duh” (people still say “duh”, right?). My experience, however, has been that we all need reminding from time to time. Things get busy, we fall into bad habits, we get lazy, and so on. There are even times when we think we’re doing a certain practice well but, when you really stop to think of it, you realize it was more of an… ideal you had in your mind rather than something you’re actually doing. Sometimes it takes hearing something you’ve heard before one last time before it finally clicks into place. Whatever the case may be, I hope you found something useful.
We love to make cool things with cool people. Have a project you’d like to collaborate on? Let’s chat!
Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.
