Table of Contents
Welcome in the second part of the 21 tips to improve your development process article. In the first part you’ve learned about the first 12 tips and tricks to speed up and improve your development process in many ways. Today, you will get the rest. These tips will cover different areas to remain universal and useful for broader range of people. Enjoy it, share it and recommend it.
First 12 tips are in part 1.
No.13: Eat the Elephant (or, for Vegans, Tree) the Right Way
If you were to eat an elephant, who would you do it? The answer is simple. You would do it piece by piece. The same principle applies to solving problems that will emerge through your development process. So, no matter how big the problem is it will be much easier to solve after you break it down to more manageable pieces. Don’t stop with problems. Do the same thing with your time. Meaning, stay in your breaking down mood and split the timeframes you set for the whole project into smaller chunks. For example, break 12 week project to 12 week-long projects.
Next on your list are tasks. Instead of relying on your ability to predict the future, break all the tasks in front of you down into more realistic 6-10 hour chunks. Then, get your hands dirty proceed one step at a time. The beauty of this approach is that you can apply it everywhere. No matter how big or small issue or problem you are facing, you can make it more manageable and solvable by breaking it down. The same with your goals. Just keep dividing what you have in front of you into smaller and smaller pieces until you are able to digest it.
No.14: Small Victories Count
Creating something new is a long and often painful process. One of the most things that can make your development process more comfortable is motivation. What’s more, if you aren’t motivated by what you are working on right now, then chances are, it won’t be as good as it should be. In fact, it will probably going to suck because you will rush the development just to end that torture. No matter how awesome thing are you building, long release cycles are motivation killers. On the other hand, smaller and quick wins you can celebrate are great motivators.
The takeaway is simple. Whenever you will develop some new product or service, dedicate some time to celebrating small victories. This can be done on a daily or weekly basis. When deciding what to celebrate you don’t have to look for big feats. Anything that will move your project closer to finish is worth celebrating, no matter how big it is.
To encourage you furthermore to share your work every day on social media, I want to mention one great book by Austin Kleon called „Show your work“. In this book, Austin will give you ten pieces of advice and tips on how you should share your work and get recognition. This book is not just for people in product development, but for anyone interested in creating something.
No.15: Design First
What is the first step you do in your development process? If you are developing a digital product, you should design the interface before you start programming. Before you start arguing, let’s agree on couple things. First, design is relatively light. Second, paper is cheap and simple sketch is easy to create and change. You can create sketches using digital tools. Third, prototyping in HTML is still relatively simple to modify. On the other hand, this does not apply to programming the thing you are working on.
Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs. Another reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show. We start with the interface so we can see how the product looks and feels from the beginning. It’s constantly being revised throughout the process. Does it make sense? Will user understand it? Does it solve the problem at hand? These are questions you can answer only when you’re dealing with real screens.
Designing first keeps you flexible and gets you to those answers sooner in the process rather than later. Epicenter design focuses on the true essence of the product–the epicenter–and then builds outward. Meaning, at the very beginning you should ignore all the unimportant extremities such as the navigation, tabs, footer, colors, sidebar, logo and so on. Instead, you start at the epicenter and design the most important piece of content first. Whatever it is the page absolutely can’t live without is the epicenter you are looking for.
For example, if you want to create a website, say a blog featuring the latest blog posts on homepage, the blog post itself is the epicenter. Not the categories in the sidebar, not the header with navigation at the top, not the comment form at the bottom, but the actual blog post unit. In other words, without the blog post block, the page is not a blog post. Only when you are sure that this block is complete would you begin to think about the second most critical element on the page. When you get finish work on the second most critical element, you will move on to the third, fourth and so on. This is what epicenter design is about.
Epicenter design avoids the traditional “build the outer frame and then drop the content in” approach. In that archaic process, the page is built and formed as first. Next, the navigation is included. After that, you would throw in the necessary marketing “stuff” and then (finally) the core functionality–the actual purpose of the page–is thrown in to whatever space remains. This is a completely backwards process. It takes what should be the top priority and places it in the end as the last element. Epicenter design flips this process and allows you to focus on what really matters on day one. Meaning, essentials are first, extras second.
With this approach, the result of the whole development process is a more friendly, focused and usable for your customers. What’s more, it allows you to start the dialogue between designer and developer right in the beginning instead of waiting for all the aspects of the page to fall in line first.
No.16: Manage Your Development Debt
We all know how development of a new product looks like. You hack together some bad code that is working just enough to get the job done, but still a bit rough. Doing this, you are building up something we can call “code debt”. The same thing is happening when you put together a design that’s good enough, but nothing exceptional. Make no mistake, it is OK to do this from time to time. In fact, creating a bit of development debt is often a needed technique that helps you build your product and ship as soon as possible.
The problem arises when you forget that there is some debt that has to be paid off. Paying off this debt simply means cleaning up the messy code you used the other day or redesigning that good enough page. You can think about this just like about regular financial debt. Meaning, when you are in a debt on your credit card, you should regularly put aside some of your income to lower this debt and to one day, finally, pay it off.
The same applies to your development debt. Otherwise, if you forget about paying your dues, you will find yourself paying interest–implementing more hacks to fix previous hacks–instead of reducing the overall debt and moving forward. This is downwards spiral.
No.17: Simplify Documentation
There are basically two types of people in product development (this is not a binary joke). First type don’t care about putting together any documentation for their projects at all. The second type, on the other hand, obsess about the smallest details and the result is document longer than War and Peace. No matter on which side are you, keep in mind that you don’t create the documentation for yourself, but for the user. Meaning, even if you will never look at it again, some one might find it helpful while using your product.
That being said, you should focus on create document that is simple to understand and easy to use. Don’t write a functional specification document. These documents don’t reflect the reality. Create all the docs with your users in mind–go with a briefer alternative that moves you toward something real. Instead of writing a long in-depth description, create a one page story about what the product needs to do. Use plain language and make it quick. Remember that if it takes more than one page to explain it, then it’s too complex.
In the end, product development is about building, not writing. Any time you need to explain some feature, functionality or whatever, try to create mockup or prototype instead of writing a wordy document. Remember that mockup of interface or prototype is one step further to become a real product. A piece of paper or PDF file is only one step before ending up in the garbage can.
No.18: Focus on Stories
The best way to convey a message to the user is by stories. Instead of getting too much into the technical details or design jargon, it will be much better to tell a quick story. Movies, books or even music. No matter the age, we like stories. Telling a short story about the product will get you much further and get more attention. When telling a story, do it in a human way. Think about it like a normal conversation. It doesn’t need to be a ten-page essay. Just give the flow of what happens. If you can include the brief story in context with screens you are developing, all the better.
Next step is to stick to the experience instead of getting hung up on the details. That is the difference between strategy and tactics. Strategy gives you direction in which you work. The tactics will fall into place once you begin building that part of your product. Right now, your goal is to get a story going and initiate conversation with your users. This will get you on the right track.
No.19: Switch Lorem Ipsum With Real Words
Lorem ipsum dolor is one of the tools designers and developers used often. When you need some content for project you are working on, it is much easier to use lorem ipsum instead of coming up with something real. Lorem ipsum, also called a dummy text, helps people get what the design will look like once it is finished. But dummy text can also be dangerous. Why? When you use lorem ipsum as a replacement for the real content, it changes the way copy is viewed. Using lorem ipsum reduces text-based content to a visual design element.
Using dummy text will prevent you from seeing all the inevitable variations that show up once the users will enter real information. Meaning, you will not know what it is like to fill out forms on your site. Sure, you can come up with many variations of what can be entered here or there, but you cannot cover all options. For example, how would “Hubert Blaine Wolfeschlegelsteinhausenbergerdorff” fit into that form input on your website? Understand that lorem ipsum text is a veil between you and reality.
Instead of relying on it, use real and relevant words as soon as you can. If your site or application requires data input, enter the real examples. However, type in the text by yourself. Don’t just copy and paste it. You have to feel the experience on your own skin as any user will when using your product. For name input, type a real name. For a city, use a real city. If it’s a password input and you ask user to repeat it twice, do the same thing by yourself. If you don’t know what content to use, take a look at similar products on the market.
No.20: Promote It Before It’s Ready
Promoting your product is very important, if not the most, part of development process. You can do it in three simple steps, beginning with teaser, proceeding to preview and ending up with launch. In teaser phase, a few weeks or months (depending on the project timeframe) ahead of time, start releasing some hints. Use social media and let people know that you are working on something and share some info about what it is. This can be a logo or piece of wireframe or mockup. Dribbble is a great example. Just one small shot. Not too vague and also not too specific.
You can also use your blog and post about the development. Your goal is to plan a seed while still staying vague. You don’t want to give people more information than necessary. Also, create a landing page where you can collect email addresses from people interested in your project. This will also show you how viable your product is.
Next phase of the promotion process is preview. Just a few days or weeks ahead of launch, start previewing the main features. Now it is time to give people more of the behind-the-scenes access. Meaning, describe the theme of the product. For example, you can post screenshots showing the features the whole beauty. And as in the teaser phase, encourage people to sign up so you’ve got a pile of emails to contact once you launch. Remember that the more email addresses will you collect, the more traction will your product able to gain.
The last phase is launch. It is the moment when all your efforts will meet the reality and your product will be released. Now people can finally see your product. Remember that emails you’ve collected? Now it is time to get the message out to those who signed up. The landing page you’ve created will now become a full marketing site. Spread the word as much and as far as possible. Contact blogs related to your products and get them to link to you. Write posts about your progress. Blog about ow many people have signed up and what updates and tweaks have you made. Build a momentum and keep it going.
No.21: Be Like Water and Go With the Flow
Do you remember that tip on flexibility? Well, I will repeat it for one more time. To succeed in product development, be open to new paths and changes in direction. Your product should stay fluid. It is not about wrapping it up in a box, ship it and then let the users wait months for the next release. You should tweak, update and change the product as you go along. Keep your development process agile. No matter what, stay open to the fact that your original idea may not be your best one and always be on the look for better.
Great example of this approach can be Flickr. Did you know that it all began as a multiplayer online game called The Game Neverending? No joke. Only after a time working on it, its creators realized that people were more interested in photo-sharing than the game itself. Seeing this, they decided to make a pivot, terminate the development of the game and focus solely on photos. Do the same thing. Be willing to change the course. Think about it like surfing. Watch the ocean to figure out where the big waves are breaking and adjust accordingly.
Closing thoughts on improving your development process
That’s it. Here you have the second part covering the rest of the tips to improve your product development process. I hope these tips will help you work better and build products your customers and users will love faster. Thank you for your time. Now go and build something!
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
Become a Patron
