Your role in building a product
Even though you might not be writing any code or designing, you still have an essential role to play as your app or website is being created.
You’re the owner of the project and responsible for the overall direction, communication, and processes that are used during its development. As your project progresses, your team will be relying on you for everything from login credentials to feedback.
Here are the main things you’ll likely be responsible for putting together:
1. Outline the goals of the project
By the time the project starts, you should already have put together a project brief that communicates the goals and purpose of the project.
Without a project brief, you’re leaving it to the designer/developer you hired to take what little they know and move the project in the direction they think is best. It’s safe to say this ambiguity usually doesn’t end well.
Your project brief needs to communicate everything you know with the designer/developer you hired so they can make effective decisions without constantly checking in. Share every piece of knowledge you can, such as:
- What is the problem you’re solving?
- Why is it a problem?
- Why is what you’re building a unique way to solve the problem?
- What are the goals for this application?
Who is the target audience for your project?
When we created this series of lessons, we worked with a Crew developer and started by sending a project brief with everything we knew about the project at the time:
‘TIGHT’ PROJECT BRIEF EXAMPLE:
DESIGN AND DEVELOPMENT FOR HOW TO BUILD AN ONLINE BUSINESS LESSONS
We’re creating a section on crew.co with a collection of interactive guides to help people who are interested in building a website/app learn more about the process (i.e. what to send the designer, how to give feedback, etc.).
We have the copy for the first guide pretty much ready and we’re looking for a front-end designer/developer to create the HTML/CSS style for the different elements (i.e. definitions, images, video embeds, etc.) and layout for the first guide.
To stay consistent with the site, we would like to use similar styles to what we currently have in our stories section.
We follow an OOCSS pattern and use SASS as a pre-processor. Your code will be reviewed by our front-end engineer for quality and consistency.
The Expected Delivery
- All .psd’s associated with the design of the first guide
- A README file should be included with instructions for building and deploying the codebase
As the project progresses, you may decide to tweak certain approaches, but at least you’re both starting with the same information.
For instance, with this Knowledge section, we started off thinking we wanted to create lots of different design elements within the page. Here was the first design mockup we created:
After looking at this together, we decided to change routes and simplify the styles of the design. Since content was the most important factor (which was highlighted in our project brief) we quickly agreed to switch to a design style that had fewer elaborate elements.
Outlining the project and compiling your business goals and objections is one of the most important jobs you have as the project owner. Take the time to lay these out beforehand and you’ll have much fewer headaches as the project progresses.
2. Supply assets and logins/passwords
As you build your product, the designer/developer will likely need to setup accounts or have access to certain things such as your website domain name, your logo, or your developer account.
Here are some common things a designer/developer might ask for access to and some suggested services to make your job easier:
- Your website domain (see Namecheap, Hover, etc)
- Your Developer Account (see Apple, Android, etc )
- Your branding, specifically a high resolution version of your logo (see Brandfolder, OpenBrand, etc)
- Your data analytics account (see Google Analytics, Mixpanel, etc)
- Your code base (if you have existing code: Github, Bitbucket, etc)
- Your project management tool (see Basecamp, Slack, etc)
- Your 3rd party platform login (Shopify, WordPress, Squarespace, etc.)
If you have some of these accounts created already and you know the designer/developer will need access to them consider preparing them in a file [see example] or use a service like Meldium to manage logins before the project starts so they are available once you get rolling.
3. Write copy
Unless you’ve outlined in your project brief that you’d like the designer/developer to write copy for the website or app, you’ll be responsible for putting this together.
No matter what you’re building, you need to think about your customers and what they need to be successful. This is known as interface writing or microcopy (since they’re usually short snippets of text).
Whatever the copy—from navigation and button text to product tours, form fields, and error messages—everything is an important instruction leading them down the path from new user to customer.
When you have clear instructions and a warm tone, you can help your customers find what they need quickly and without having to ask you for help.
This means you’ll need to think through common copy elements like:
- Your tagline
- Errors and alert messages
- Form labels
- Instructional copy throughout the product
- Transactional emails
Let’s take a look at how the Mailbox app onboards new members to get an idea:
You can always hire a writer to prepare this copy, but remember, unless you’ve clearly stated that you want the designer/developer to be in charge of it, it’s your responsibility and shouldn’t be an afterthought.
At times, you might be tempted to get started on your designs before the copy is ready, in which case the designer can always use placeholder text but this is rarely the best option.
Your tagline and copy might be much different than what the web design layout is calling for. So, if you can get the copy incorporated in the design process from the start (perhaps by even starting with the copy) that will help in creating a cohesive experience.
4. Give feedback
As your project moves along, the designer/developer will send over mockups, screenshots, or test links for you to comment on.
When you receive these elements, you should try to give feedback as soon as you can, ideally within 24 hours.
Giving feedback can be a bit of an artform. You want to give the right comments to keep the project moving forward, while keeping your team motivated.
Techniques for giving feedback
While there are many ways to give feedback as a project owner, two popular and effective methodologies for giving feedback are the ‘feedback sandwich’ and ‘stop, start, continue’.
The feedback sandwich method
The feedback sandwich is where you make positive statements, discuss areas for improvement, and then finish with more positive statements.
- Identify the positive aspects of the progress. This could be recognizing the aspects that you consider completed and complimenting improvements made to the overall project. Make sure to let your team know what’s working so they can continue to do those things.
- Discuss what needs to be improved. These comments should be direct and based on facts rather than emotions. An example would be “I don’t like the color blue” vs “Please change the blue we’re using to a shade similar to what’s used on Twitter.com”. This lets the designer know exactly what you’re looking for and doesn’t leave them guessing. If you’re unsure, explain your reasoning and thoughts so they can make an accurate decision based on your feedback.
- Compliment. When we’re coaching, we want to make sure we’re not de-motivating our team so we always want to leave things on a positive note. Give them a pat on the back and let them know you appreciate all the hard work they’re putting into the project. An example would be “Keep up the fantastic work, I can’t wait to see what you create for the next version”.
Stop, start, continue method
If the feedback sandwich doesn’t feel natural for you, try the ‘stop, start, continue’ method. This method consists of three main elements:
- What they should stop doing
- What they should start doing
- What they should continue doing
An example would be:
“[Stop] Great work on the header section of our site, I’m really happy with where the design is currently and I consider it completed. [Start] We’re ready to move forward with the rest of the homepage design. [Continue] Keep sending me regular updates through InVision, I think that flow is working really well for us.”
If you have a deadline for the project, it’s important that you move quickly to give feedback to the designer/developer so they can move forward with any changes and the project doesn’t stall.
Deadlines are dependent on you as well, not just the designer/developer you hired.
Here’s a few tools you can use to offer feedback quickly:
Perfect, lightweight tool for easy annotation on mockups. Great for simple workflows and landing pages.
Recommended for: Static mockups and marketing websites.
Allows for easy annotation and sketching on mockups. Integrates directly with Evernote for easy organization.
Recommended for: Static mockups that need quick feedback.
Easily create realistic mobile mockups and web prototypes. Allows for annotating mockups as well as turning sketches into prototypes.
Recommended for: Creating realistic web and mobile prototypes.
A powerhouse for design prototyping. Allows you to annotate, create click-through mockups, and a robust workflow for project management.
Recommended for: Larger design projects that also involve an element of prototyping.
When you’re working on a project, it’s rarely the case that you can give a brief and then disappear for a few months. This is your creation, and you’ll be expected to have an active voice in the overall direction and outcome.
By breaking the project up into parts and working through the components with regular communication you’re sure to make something exceptional.
Give the designer/developer the space they need to do what their best work, but make sure you keep in communication and on the path you envisioned.
If you can do this, you will create something everyone can be proud of.