Steps for a Successful Development Transition
There’s always a lot of talk about process, and rightfully so. One thing we believe is that your process should always be in a state of evolving. Working in smaller teams allows us to be agile and adjust our process whenever necessary. We are always looking for ways to reduce pain points within the way we work, both as individuals and as a team.
Getting started- Initial planning. As a brief summary, before beginning a project certain questions must be answered. Things like “why are building this application?” and “what features does it need to be capable of executing?” are just a few things that come up. There are many things to consider here among which are, but not limited to, defining a target audience, setting site goals, laying out technical specifications, assigning resources, developing a timeline and setting a budget.
Side note: Littlelines is a full-service consultancy and therefore we come into projects at various stages. Sometimes these early steps are already fleshed out by the client other times we are asked to assist with these steps.
Creating a flow- After we’ve gathered technical specifcations and site functionality we can create user stories. These are simply tasks a user should be able to execute in the application. For example, as a user I need to save payment information.
Having the user stories and core functionality listed we began work on the user experience. The foundation of this starts with planning the site flow and pages, better known as a good ol’ sitemap.
Once that’s completed we move into brainstorming and laying out what content these screens themselves will require. We’re currently utilizing Sketch and the Invision app as a powerful, rapid prototyping combo. Sketch is incredibly flexible and with its ability to create elements as symbols you can quickly make global updates and edits. Within Sketch we utilize a plugin called Craft which allows you sync these screens to Invision and create clickable prototypes.
// Photo: Laying out a sitemap defines the pages of the site while flow charts help define user interaction and site fuinctionality
We can’t stress enough the power of having a clickable prototype is to the process, both for client reviews and approvals. Also these prototypes have proven helpful for user testing and presentation to our development team, who we like to have involved almost every step of the way.
Tip: Get the development team involved sooner rather than later. They can help highlight potential problems within the application while also suggesting things that may make the overall usability and/or development go smoother. This ultimately gives them a better understanding of what they will building long before the project is handed off.
Moving into design- As a result of creating better, working prototypes, we’ve been able to move away from doing full site static page designs by incorporating things like style tiles and pattern libraries. Style tiles allow us to quickly get initial stylings and design options in front of clients. We can quickly nail down things like color choices, as well as font pairings and sizing. We can even explore things like photo treatments. Pattern libraries make things like having a consistent user interface much easier and help facilitate reusability. Don’t get me wrong, we still end up doing full designs for high level pages like the homepage or if the app has specific features we want to highlight. Since we tend to work on a lot of larger apps that are heavy in terms of functionality, having to design every screen can prove to be costly.
The hand off- Now that we’ve established base styles for all of the applications assets, we use those in combination with the approved wireframes and full page designs to hand over to our dev team who begin piecing the app together. Our developers build out interactive style guides of reusable elements that will be used throughout the application. Because developers can grab elements and piece pages together it allows more flexibility in development, removing the need for our developers to make assumptions can lead to some less than desired results. Companies have adopted the common practice of pairing which plays an integral part of our process.
Two is better than one. Pairing is when two people are working on one problem at one time. In this case me as a designer sitting with a developer to make design tweaks to a website or app. Developers often pair up to tackle difficult tasks or to settle a dispute on code should be written or even just to knock out code reviews.
So why do we pair? That’s actually a pretty easy answer, while our designers and developers work together on a fairly consistent basis they are in most cases still separated in terms of tasks. This can lead to miscommunication as a designer might say something like “there needs to be more space between the header and sub head”. This can easily be seen as vague and misinterpreted by a developer. Do they adjust the space by .125 ems or .25? So rather than the dev guessing the correct answer then finding out it wasn’t exactly what the designer wanted, it’s much easier to pair up to make these adjustments.
// Photo: To start, our developers build out interactive style guides– a repository of styled elements that will be used throughout the application.
How it works. Once the frontend dev gets a decent amount of the site built we will have them pair with the designer and refine these stylings. It’s been said that time is money and this is especially true when we have two members of our team sitting on a project. So how to make the most of this time?
Schedule some time and take notes.
A time should be agreed upon to meet between he designer and dev to pair up. All of our projects are housed on a staging server, the designer can use this site to start collecting notes. Make sure to put these in order of importance, and you may also want to think of what tasks might be easier to accomplish vs. what things may take a considerable amount of time.
// Photo: Using the browser to edit site styles before meeting and pairing with a developer.
Tip: Improve your notes. Inspect the web page and provide suggestions for changes. Example: in Safari press cmd + opt + i to launch the web inspector. Once launched you can inspect the page and make recommendations to the dev. For example, “I noticed the body copy weight is 700. I adjusted it to 500 and this is closer to what I had intended”. Not a developer, don’t know code? Not a problem you can use this as a way to learn. Even if you’re incorrect in the exact piece of code that needs adjusted at least pointing the developer in a direction will help save time.
Speaking of… The most important factor is time itself. Make sure you set a limit for the amount of time you are going to pair. Setting these types of restraints helps keep everyone focused on the task at hand while prioritizing what is really important to the project’s completion. Second, as I’m preparing to meet with the dev I start with a list of small achievable goals that I believe we can fix while we sit together and other larger items that I can walk through in detail but may not be able to get changed right away while we are sitting there.
This is just kickoff to successful development, from here there are still several rounds of pairing, internal testing, user testing, and client approvals. What I’ve painted here are broad strokes of a very detailed process.
