In the last few years process has been popularized as an important contributor to success. Newcomers and veterans in the field want to know how can they bring their ideas to life and be successful. The hope has been that process and perseverance will be enough. So which process is the the right one to use? Agile, waterfall, scrum, XP, lean, lifecycle or the “PINK p90x atkins south beach process.” (I made up that last one.) There isn’t a single ultimate process that everyone can use to achieve all their goals. And there shouldn’t be. Process often gets confused with strategy. Here are the definitions from wikipedia:
- A process involves steps and decisions in the way work is accomplished.
- A plan of action designed to achieve a particular goal.
Strategies and processes should be congruent and so should the teams involved in the project. Unfortunately, strategies can get passed down as business fantasies locked in to a spreadsheet that contain columns such as milestones, vanity metrics and important dates.
A process might be great, but if the strategy is shit then it doesn’t matter how bug-free the code is or how easy a product is to use, because more then likely the product is something people don’t want to use. I believe that a great strategy must included processes that delivery results.
Process is often viewed by the management as a means to produce an estimated date. Process is often left to the departments executing the strategy. In this type of environment process is separated from the business strategy and more importantly the processors are separated from the strategists.
But wait things can get worse! Sometimes the people executing the strategy, the processors, often separate themselves from other processors. Different departments and even teams within the same department use different processes that seem incompatible with one another. This can start little skirmishes between teams.
Strategy & Process are Buddies
Strategy and process need to come together to both work towards achieving the same goal. Eric Ries’ book The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses demonstrates how to combine a hyper-agile (continuous deployment) development process, a user-centric design process with a strategy focused on testing the business’s ideas, hypotheses and assumptions will help the business make accurate and timely decisions to help achieve their goals. The book walks the reader through the Lean Startup strategy while demonstrating how real startups have applied these methods. The book is broken into three main parts with subsections. Here is the table of contents:
- Pivot (or Persevere)
Notice that there isn’t chapter on communication or collaboration. The power of metrics and user research can best be realized by sharing the information with everyone who is working on the product. Communication is so important it’s just assumed to be part of the culture. Eric Ries’ describes great communication through the book without actually focusing on communication as a skill that should be practiced and refined. I really enjoyed the book and I highly recommended it, but remember that without communication every process will fail.
There are some great books and plenty more to come such as Agile Experience Design as well as the upcoming book by Jeff Gothelf called Lean UX: Getting Out of the Deliverables Business which are going help startups become successful faster. The reason I enjoy the lean movement approaches isn’t just because I think they are teaching people about a good process, it’s because the book emphasizes a scientific approach and ample communication. The lean processes emphasizes getting better results with less work, which for startups means testing ideas, designs and software quickly. But ultimately it’s not the process that makes a startup successful it’s the team’s output, the product or service.
As designers we are generally judge by our ability to output artifacts of our work. Pixel perfect Photoshop files, task-flow models, wireframes, specifications, personas and usability reports. The documents’ goal are to communicate design. But generally designers are tasked to hand over one of these documents before a certain date. The goal should be to communicate what needs to be communicated so other people in our team can do the work they need to do. Sometimes a document will serve this purpose, but many times it’s just a simple conversation or a presentation, a rough sketch, design studio or a finger pointing to something on a screen.
The best thing a designer can do is spend as much time with the team asking and answering questions. This leads to a better product or service that gets built with a lot less friction then you’ll encounter in a waterfall style process. Spending time doesn’t need to be face to face, although a good dose of that is helpful. You can use tools such as basecamp, groupme, skype, hipchat, IM to stay in sync with each other. I think the best tool if you are collocated is actually sitting with the developers, QA engineers, BAs and PMs. The second best tool is having a shared wall where the team meets everyday to discuss the work being done. This wall is where you can hang all you sketches, wireframes, visual design and post-its related the design work you’re doing.
I’ll work on a follow up post that will focus on effective ways to communicate designs that goes beyond just creating wireframes, PSDs and other design documents. I’ll talk about sketching sessions, agile walls, and other methods that can be used to effectively communicate design.