4 Things to do before starting a Drupal Project
Duo recently started working with an up-and-coming startup to determine a set of requirements for the company’s new mobile app. Based off of phone calls with the startup team, there were a lot of elements that they considered to be important to the project, but due to time and scope limitations, the team wanted us to determine what the minimum viable product was. The team really wanted us to push through all the ideas and find the core element that would tell their story in an engaging way.
Photo by rawpixel.com
This process could have quickly turned into a disaster, but fortunately, it didn’t. I traveled to the startup’s office for a three-day sketchboarding session to hone in on what it was that was truly important and essential for the project.
Sketchboarding, at least in my eyes, is part of a collaborative meeting where we take ideas from a nebulas state and transform them into a set of requirements. The requirements could be for a specific phase of a project, or it could cover the project as a whole. The goal of sketchboarding is to develop and articulate the approach for a project, and because it is so early on in the process, the session can set the tone for the overall project. Because of that, it really is an important step in order to make sure everyone is on the same page.
Whenever I go into a sketchboarding session, I always do these four things:
- Ask the stakeholders to compile their goals/requirements
Believe it or not, this first step is sometimes the most challenging. Many times, clients will talk to me about a new site they want, and they come with a solution they are looking for. We’re not looking for clients to present solutions, though. We’re much more interested in knowing the problem a client is having and the goals they’re looking to accomplish — we can partner with the client to determine the ideal solution. In order to do that, though, we need to know what those goals are.
These goals can be presented in any format — a Word doc, a spreadsheet, etc. All we’re looking for is a list that helps articulate the client’s needs and the pain points they’ve been encountering. This can, and should, include front-end components and back-end components so that we can make sure we’re starting with as broad a view as possible.
For my meeting with the startup, we had several phone calls prior to the sketchboarding session to talk through the company’s goals, and the stakeholders were able to give me their list of requirements. These phone calls were incredibly helpful because they gave me an opportunity to ask a lot of questions, and they also allowed me to confirm several assumptions and clarifications I had.
- Never go to a strategy session empty handed
It is always easier to get people to react to something than to get participants to try and create something from scratch. I use the list of goals and requirements initially provided to me as a guide to help me sketch out some possible solutions. There is a delicate balance that needs to be maintained. You don’t want to come into these meetings with a solution so far planned out that the stakeholders don’t think they can make adjustments to it.
In the last few months, I’ve tried rethinking my approach to this step of the process. In the past, I used to make PowerPoint presentations that went through my thinking and potential solutions to the clients’ problems. The problem, though, is that presenting on a computer allows stakeholders to zone out and not offer the type of engagement these sketchboarding sessions truly benefit from.
So, I’ve gone old school. I use paper and pens, or a whiteboard and dry erase marker, and Post-it notes. Lots of Post-it notes. At the startup, I had a large sheet of Butcher paper and we used it to begin thinking about an ideal user flow. Based on the requirements they gave me, I was able to think about how to group parts of the site together, and then we were able to take that and examine how we wanted users to flow through the site. I had people get up and mark the paper up or draw their own ideas. Using paper encourages people to be hands on, and it fosters far more engagement than a PowerPoint presentation.
- Get everyone involved
For my sketchboarding meetings, the people I meet with generally are a bit out of their comfort zone. Thinking systematically about how a website is structured just isn’t what they’re used to doing. And that’s fine. It’s important to recognize that early on and make the meeting become something they’re comfortable doing. Whether that means adopting a warm-up activity to get meeting attendees in the right mind frame of simply acknowledging that this will be a new experience for them, it’s important to identify the different backgrounds and experience present in the meeting.
Speaking of different backgrounds, I always say that sketchboarding sessions should always have someone from the client’s technical team. It’s great to come up with all sorts of solutions, but if your development team can’t create the solution you propose, then you’ve wasted valuable time and resources. This also gives the technical person a chance to do their own discovery on the project and know what type of request may be on the horizon.
Here’s another tip. Consider the space where you meet with the stakeholders. It’s crucial that you’re in a setting where you can make eye contact with attendees. It also is important to be a in a room that fits the number of participants in the meeting. If there are only four of you, you don’t need to meet in an auditorium.
Lastly, encourage everyone to disconnect from their screens. Like I’m trying to do with opting for paper instead of PowerPoint, push your meeting attendees to not focus on their computers or phones. One way to do this is to have a standing meeting — it’s a little harder to discreetly look at your phone or computer while standing with the other meeting attendees.
- Start broad and move to the specifics
You never quite know what direction these sketchboarding meetings will take you, but it’s important to recognize when the conversation is helping the overall project, and when you may just be heading down a rabbit hole.
For example, a client may know that they want to incorporate a specific API into their website. Don’t start the conversation with that topic. If you do, you could easily spend 45 minutes or an hour just talking about that API without ever having discussed why the API is necessary and what problem it helps solve. Start broad. Then get detailed.
For my startup meeting, we spent the first day sketching out user flows. I brought some samples with me, and we were able to use Post-it notes to rearrange the flow and move the project forward.
The second day was spent talking about requirements the client wanted on specific pages and screens. We were able to decide what fields and functionality would be available on each page, but we were only able to do that because we spent the first day deciding on the bigger picture. By day three, we were drawing up the screens and showing the client an idea of what they’re finished product could look like.
We went from Post-it notes to a pretty firm idea of how the site would look on different screens and what details would be present on each screen.
I talked with the client afterward and they said they loved the sketchboarding experience since they came out of the meeting with a strategy for the project. What they were surprised by was that the sessions actually brought the individuals on the team closer together because they worked together through the sketchboarding sessions.
As an activity to gather requirements for the project, the client said sketchboarding was great. As a team building activity, they said it was even better.