My process for designing software products
Part I
Throughout my design career that spans just over a decade, I’ve had many conversations about a process designers of all types utilize to deliver their best work. I started my career as a self-taught designer, specializing in communication design; building websites for a wide range of businesses, designing promotional materials for printed media, and creating complete visual identities for new enterprises.
Naturally, conversations around process were very different back then. At the time, my colleagues and I were not building products for everyday use that solved a specific set of problems. Instead, we helped marketing departments and business owners get their message in front of potential buyers in a manner that appealed to their audiences.
About five years ago, my focus shifted towards designing software products. I found myself surrounded by colleagues who looked at design very differently: conversations around the process for designing products vs. communications have changed dramatically.
Since moving to San Francisco in 2011, I had multiple conversations about design processes with founders of startups, software engineers, product managers, and other designers in tech. After taking leadership roles at a couple of startups (Kabuto, LeadGenius) in the past few years, during interviews I always make it a point to initiate discussions about candidates’ design processes. It helps me understand how job candidates think about designing software, how they solve problems when building complex systems, and how they engage with their colleagues to reach optimal results.
So what exactly about design process makes it a subject of so many conversations in the tech community? Can it make or break a product? Does this process travel with the designer when switching jobs, or does it change with their environment? Do we adapt our process to products that we build? I decided to take some time and reflect on my own process of designing products in hopes of shedding some light on the subject, and perhaps soliciting some input from my peers.
I often tend to compare my current role as a product designer to my previous roles as a communications designer. In communication design, my success was mostly determined by the aesthetic quality of design artifacts across various mediums. The guidelines were provided by the client, so naturally the level of success was based on the client’s level of satisfaction. In communication design, my work was used as a marketing tool to communicate a certain message and help sell a product or service. In contrast, product design solves a problem, it enables users of a software product to do a job they couldn’t do without it.
That’s precisely why people pay for software products and use them over and over again to solve their problems. A product’s success is then measured by its degree of efficiency. Thus, any effective process for designing software should begin with understanding your target audience and properly defining the problem that your product aims to solve.
Understanding Your Audience
I cannot stress enough how important it is to really understand the people who are supposed to benefit from using a software product. It’s crucial to understand their habits, existing workflows, and how they think about problems. This will affect not only what your product aims to address but also how. In order to build great software, a channel of communication with the users of your product should be open at all times.
A great deal of conversations with users and potential users should happen well before your team starts building. These are vital for defining the problem your product aims to solve. Well-structured conversations also help uncover valuable insights that oftentimes guide your team to build a better product faster.
Every tech company where I contributed as a product designer paid a great deal of attention to user research; however, my involvement in collecting user insights varied from company to company, partially because products at these organizations were in different stages of development.
When I joined Kabuto to build an Android app for their multi-platform collaboration tool, most of the initial user research had already been done prior to my joining the team. The product team was at the stage of building out components with functionality that was already vetted with a group of potential users. During the design phase, however, we were very quick to test prototypes with internal stakeholders before jumping into development when additional validation of certain features was required, and we certainly spent a good deal of resources on user testing our beta releases.
In another situation where a small team was building a SaaS product for a new market from scratch it was imperative for us to have structured conversations with potential users to uncover the pain points our product could help alleviate. Before we set out to collect initial insights from our target audience, our team used The Business Model Canvas to better understand what we were building.
It helped us identify our customers, hammer out the value proposition and understand the business implications of a product we set out to create. A combination of data assembled during The Business Model Canvas workshops and insights from initial customer development interviews helped us clearly define a set of problems that we would be solving for our users.
The main take-away is that before any product design work can begin, it’s crucial to learn as much as possible about the users of your product, and most importantly how your product can help them solve specific problems.
Problem Definition
Whether your and your team are designing a new feature of an existing product or a completely new product, it’s absolutely crucial to make sure that the problem your are attempting to solve for consumers is well defined.
A problem that’s well defined keeps the team focused, leaving no room for speculation about what components make it into the product. Without a clear understanding of a product’s building blocks, teams run the risk of building a piece of software with components that detract from the key functionality and increase complexity.
It’s worthwhile to mention that defining a product or feature is not the same as defining a problem. Let me illustrate the difference with an example from a past project. Our team was building a mobile app for tourists who wanted to learn about local restaurants and discover the regional cuisine. We were certainly not the first entrants in the already crowded space, yet we approached the task at hand from a different angle.
“A mobile app that allows tourists to learn about local cuisine and discover nearby restaurants”.
The statement above could have easily served as our product’s definition that guided what we build. It’s not impossible to build an app that fits such a description, but it would certainly cause unnecessary speculation about what components to include in the initial release. Instead of broadly defining a product, we carefully defined a problem that our users could solve with the app. We relied on a set of user stories that followed a specific format to precisely define these problems. Here’s an example of one such high-level user story:
“As a tourist, I want to have convenient access to current menus of local restaurants so that I can avoid spending time searching for that info across multiple online resources”.
During initial conversations with people who used competing products, we uncovered that they neither cared much about restaurant ratings, nor did they identify in-app reservations as a feature that would be useful to them. They did, however, care about updated menus and high-quality images.
Coincidentally, due to the nature of our primary product, it was super exciting for us to hear about the importance of menus. In retrospect, it was a good call to spend time with potential users of our product and identify the problems that we would be attempting to solve because it helped us build the first version rather quickly and deliver a simple yet compelling app, as post-launch user testing would inform us.
Business Objectives and Design
In my current role at LeadGenius, I’m often involved in strategic product discussions with the founders where high-level product objectives are outlined and definitive KPIs (Key Performance Indicators) are set. In my previous roles, more often than not, high-level strategic decisions that inform product roadmaps were made without my direct involvement.
It is not uncommon for specific business goals to guide user research efforts, although sometimes there are situations where user insights collected during discovery interviews impact the very core of a company’s business. The latter mostly happens in early stage startups without a solid product-market fit.
In my opinion, the business goals that a product aims to achieve form the second half of “why” a product or feature is being built, the first half being the user’s problem it aims to solve. Regardless of my involvement in the high-level strategic decision-making process, I always strive to understand the business implications of products that I design. It helps me focus my efforts in order to produce a win-win situation for both the company and the user of a product.
Part 2
This article will cover all of the components that fit into my design process. That being said, no process should be set in stone. Depending on the product and its stage of development, these components can be modified or completely taken out of the process. Building software is not a linear process. Sometimes design works in parallel with engineering, other times the two teams work in a staggered format. Sometimes I move right along with outlined processes, other times I have to take a step back, so the end result can be greater. I look at my design process as a preferred roadmap, one that’s flexible enough to adjust to the right cadence within every organization with a focus on building great products.
Organizing for Success
When a group of designers and engineers is working together, it’s imperative to make sure that everyone is always in sync. There is a great deal of interdependencies when it comes to tasks required to complete a feature. Carefully organizing these tasks across design and engineering provides transparency and allows product managers to track progress.
In most of my previous positions PMs were responsible for setting up development milestones and tracking progress across the product team. In my current position as the lead product designer at LeadGenius, we use GitHub for both design and engineering issues. Even though milestones are set by product owners, I spend a lot of time in GitHub to see how things are going not only with the design but also with engineering. It gives me a better understanding of our progress and provides insights into areas where I can be most helpful.
When I worked on a product of my own, a platform for restaurants to help manage and distribute menus online, I acted as a product manager on top doing all of the design-related tasks, and tracking progress of our small team of engineers was on my daily to-do list. I prefer tracking progress against specific product components that are being built as opposed to separating progress milestones into front-end, back-end, and design tasks that often relate to multiple components. Grouping task lists and issues on GitHub around product components allows me to assess where we are in the process at-a-glance. It also keeps team conversations focused on features as opposed to disconnected tasks related to front-end or back-end issues.
In order to provide organizational clarity to the product team, I usually create issues and attach them to a milestone in GitHub. Milestones contain everything that must be completed in order to ship a certain feature. Issues are assigned to individual contributors and then labeled to provide additional clarity about the building blocks of a feature.
User Journeys and Feature Prioritization
Once a design team has a clear understanding of the problem that they are aiming to solve, and the KPIs that will measure success have been clearly defined, it’s time for product designers to start doing what they do best.
When designing a new product, I usually start with high-level user journeys. I see user journeys as maps with very little detail that help me understand how users might navigate the product that I’m designing to achieve desired results. When I create user journeys, I keep all of the user stories that were outlined earlier in the process in front of me. They help me focus on key user flows that actually address specific user stories; these key user flows are often called red routes.
While creating user journeys, I make a list of all possible features that might become key milestones for designers and software engineers to achieve during the build phase. At this stage in the process it’s important to identify high-level features. Let’s take for example a web app for team collaboration. A bunch of potential features come to mind: initial signup, product walk-through, profile setup, new project creation, user management and so forth. Creating user journeys and features lists often goes hand in hand. I usually revisit both when I’m near completion of the first step in the design process, before diving deeper into the features that will make up the app.
Each feature is comprised of its own components that need to be addressed by both designers and engineers. For example, a new project creation feature of the collaboration app might require a component for adding content to the project, or a module to invite collaborators to the project, which in turn would require email notifications. Before getting too deep into these smaller components, I get together with my team of PMs and engineers to prioritize global features. Sometimes product managers prioritize features and provide scope for the rest of the team. Other times I step into a project manager’s shoes and create a feature prioritization proposal for the rest of the product team.
When prioritizing features with the team, I always focus on the problems we are attempting to solve for consumers of the product. Relying on previously defined user stories helps product teams keep the required focus.
Initial UI Design
Once all of the internal stakeholders agree on global product features for the initial release, I begin to dive into interface details of each feature. This is where a great deal of heads down work happens either on paper or on screen. Every global feature has a number of smaller components that need to be identified. Let’s take a new project creation feature for our collaboration app mentioned a few paragraphs earlier. It consists of several smaller components that require design, and as I start sketching the main UI of that particular feature, I quickly make a list of these components. This list will help me remember what items require design. Sometimes I jump into sketching the smaller UI components right away, other times I go to the next global feature and repeat the process. As long as I have a list of smaller components that make up a global feature, I can be sure that nothing of importance is omitted.
Task Flows
Sometimes it makes sense to create detailed user task flows to communicate the architecture of the product and visualize all of the ways in which a user might navigate through the product. It’s especially helpful for complex products where users may take some unexpected turns, so to speak, and all edge cases must be accounted for in the architecture of the product to prevent unexpected software behavior.
When there’s no need to map user task flows in a separate document, I present overall product experience using flushed out UI wireframes. I select key user flows and organize my wireframes in a way that visually communicates a user’s journey through a particular feature. This helps stimulate discussion with internal stakeholders about individual UI components without leaving out the important conversations around user experience and technical implications of the proposed design.
User Experience in Wireframes
When all of the UI sketching is completed, I informally run some initial interface concepts by my teammates, and then I start flushing out and organizing these concepts. I primarily use Sketch to produce detailed wireframes quickly in digital format. At this stage, smaller UI details get attention, and a good deal of time is devoted to thinking about overall user experience. At this stage I start thinking about UI interactions and how to make these interactions fit into the overall user experience. I make a lot of notes on my wireframes to explain key interactions. I’ve found that these notes help me present my product thinking to the team during team meetings. I have also worked with plenty of remote teams who find great value in careful annotations that accompany my wireframes.
Wireframes result in a collection of interface features that make up the product. Once all of the wireframes are complete, I tighten up my designs and present them to the product team for feedback. I believe it’s a good idea to solicit high-level product feedback from the team using wireframes because these design artifacts visually communicate that work is still in progress, and everyone on the team should feel encouraged to contribute to making any necessary adjustments. In my experience, when designers present highly polished work to the team at this stage of building a product two things happen. First, the focus shifts to smaller visual details that are irrelevant at the current stage of the design process, and away from overall product functionality and user experience. Second, on a psychological level, highly polished visual designs communicate a certain level of completion, which does not invite any further iterations or ideation on the functionality of the product. I actually encourage my teammates to participate in design discussions and push them to mark up my designs with their ideas, write notes and rearrange them. A great deal of communal product thinking and understanding happens during these feedback sessions; new ideas are born, and everyone on the team usually becomes tightly aligned on the direction of product features.
After presenting initial product wireframes to the team and collecting as much feedback as possible, I spend some time to review how we as a team think about the product, and then make the necessary adjustments to existing designs before uploading final work to InVision. In my recent roles I’ve been relying on InVision to organize my work in one place and keep valuable feedback from my teammates flowing as new designs become available, without having to spend time in frequent review meetings.
Usability Testing with Prototypes
Before an internal design review, it’s often useful to create low-fidelity prototypes to validate high-level product assumptions. In other situations, it makes sense to build these prototypes after the design review, in case the team finds it helpful to solicit additional feedback from the actual users of the product. Prototypes can take many shapes, and timing of prototype testing often determines what exactly is being tested.
When I was working with the founder of a mobile-first product in the social networking space, there were still a lot of unanswered questions about the validity of the proposed app. Before any product work could commence, it proved necessary for me to build multiple prototypes that we used during customer development interviews. We needed a better understanding of our target audience and a clearly defined set of problems that the proposed app would solve for its users. I created a set of prototypes with which users could interact right on their mobile devices. We tested a number of product hypotheses during the interview process and collected a great deal of information that helped us build a product better suited for our target audience. In general, conducting prototype testing early in the process usually addresses high-level fit of users’ problems with the proposed solution. Later stage prototype testing usually focuses on specific usability issues.
Nowadays there are plenty of tools to create interactive prototypes on-the-fly without huge resource expenditures at any stage of product development. Usually, there are specific product questions that require answers, and prototyping critical user flows to test usability internally or externally becomes a breeze with tools such as InVision, Marvel and Pixate for mobile products.
Interactive and Visual Design
A great deal of thinking about macro-interactions happens during wireframing and prototyping stages. These interactions shape how people navigate through products. The design of micro-interactions usually happens much later in the process, and for me it happens almost in parallel with designing of visual elements. Many designers would agree that designing visual systems is a whole lot of fun. Designers get to weigh the pros and cons of numerous color palettes, explore a number of suitable fonts, experiment with interface layouts and eventually create style guides that co-exist with products as they mature.
I’ve had the pleasure of working with a number of young companies where my responsibilities included designing visual systems from scratch. I usually spend a good deal of time researching competing products, putting together inspirational boards and vetting visual concepts with the community of peers. I’m a big fan of creating live style guides; they help maintain visual consistency across the interface, lower the margin of error during implementation and make developers’ lives a whole lot easier. I usually include system-wide micro-interactions, such a messaging and form field behaviors, right into the live style guides.
Getting feedback on visual and interactive design work is always exciting, because people on the team start to clearly visualize how the finished product might look and feel. When getting feedback on visual design, I think it’s always a good idea to present two or more directions for developing the visual language for the product. Initial feedback sessions usually do not require fully flushed out visual systems, so it’s better to explore a number of approaches in order to collect the most useful feedback. Presenting several options at once provides an opportunity for the team to compare and contrast these options.
A good designer is usually able to pick up on comments about each option, and group the commentary in a way that helps produce new iterations with higher precision, while accounting for everyone’s input. There are times when I moderate visual design feedback sessions, and even defend the design choices that were made. In my experience, when you produce highly polished design artifacts, the discussions around visual components at times get quite heated. I believe it’s the designer’s responsibility to help steer conversation clear of heated debates by providing reasonable explanations about the choices that were made during the design process.
Working With Engineers
I make it a priority to start collaborating with software engineers on the product team very early in the process. Depending on the organizational structure, I start a dialogue with engineers right after sketching the first versions of the interface. Getting early feedback from engineering in the past proved to be valuable and helped identify critical roadblocks early in the process. It should come as no surprise that it’s a good idea to involve engineers in discussions of high-level user flows of the features that are being built. Mapping and molding these flows together with the people who are in charge of implementing new features into the larger system makes sense because they have a much better understanding of how new components might fit into the existing structure without impeding overall performance or causing significant and unnecessary restructuring of the existing codebase.
When the time comes to implement visual and interactive UI components of a product feature, I work closely with front-end developers. They also help me when it’s necessary to create quick prototypes for user testing prior to building out the entire feature. I have general knowledge of HTML and CSS, so communicating with the front-end team is usually a breeze. Depending on the situation, sometimes I create detailed visual UI specs for the front-end developers to follow or help build live style guides (sometimes called pattern libraries) that usually take some time to create but are super helpful for maintaining visual UI consistency as the product grows, plus they add efficiency to implementing repeating UI components. I’m a huge fan of creating live style guides, and most recently I led the charge on creating the LeadGenius style guide with the help of our front-end team.
I pay a lot of attention to the smallest of details when it comes to designing interfaces, and it’s important to me that all of these details are implemented correctly. From interaction that happens during in-line form field validation to animations of drop-downs and flash messages, it’s crucial to make sure these little interactive bits get implemented as envisioned. I have devised a number of ways to communicate the intricacies of interface design to front-end engineers. Sometimes creating custom animations helps communicate these design details, others finding similar interactions used elsewhere solves the problem. No matter the technique, however, it’s important to have a solid relationship with your team, that of mutual respect and understanding. When people work together in an environment that promotes collaboration, it’s always easier to find solutions to problems just by clearly communicating with one another.
User Testing
I partially addressed usability testing in paragraphs above, when describing my approach to prototype testing during the product design phase. I think it’s crucial to dedicate resources to receiving feedback from users as early as possible. It’s also equally important to conduct thorough usability testing after launching a product in beta, or releasing a feature to a limited audience. Companies with more resources sometimes conduct closed usability studies before releasing new products and features to a wider audience. They simply hire people to come in for usability testing sessions behind closed doors. These sessions are great for completely new products, because testing new features of existing products without larger product context is not the best approach to achieving accurate results.
I always find it useful to test newly built features with the help of scripts. Well-written scripts that are aligned with user stories written earlier allow me to focus on testing critical user flows, and determine how easy it is for users to reach a specific outcome. I have conducted both moderated and unmoderated tests, remotely and in-person. During moderated tests, especially in-person, it’s important to make sure the testers feel at ease, because most people naturally don’t want to be critical of other people’s work. It’s usually a good idea to explain that the point of these sessions is to help the team build a better product, and that critical commentary is required. I ask testers to provide a narrative as they perform a series of tasks outlined in the scripts. It helps identify problem areas and ask follow up questions when testers react to what they are experiencing. Asking questions during user testing sessions is a skill in itself.
It’s important not to ask leading questions, such as “Do you think it was an easy task to perform?” These types of questions tend to produce answers with no real insight. Since people find it easier to agree than disagree, the answers to these questions might not reflect what people really think. Perfectly timed follow up questions usually provide the most value. For example, if someone says “That’s cool!” or “Hmm, that’s confusing!” when they experience a certain part of the product feature, it’s a good time to dig into the reasoning behind that statement. Getting people to talk in these situations is crucial because so much more value can be uncovered.
Usability testing sessions usually result in a bunch of notes, quotes and recorded videos of users going through product screens. I categorize the results into groups, put together brief recommendations on how to address critical issues and present the findings to the product team. When usability issues are uncovered, some members of the product team might be tempted to re-work the entire feature or specific user flow. Sometimes that’s the decision that product teams make together, but most of the time I find it useful to make incremental changes and potentially test again with a prototype if the issue significantly impairs usability. More often than not, the sample size of most usability tests is rather small, and spending a great deal of resources on re-working entire features sometimes seems illogical due to an absence of substantial data.
Design Tools and Collaboration Platforms
My tool set varies only slightly with each company where I contribute as a product designer. Below is a list of tools that I have used in the past and use currently for design, user testing, and project management.
- A dot grid notebook with a good pen and pencil is perfect for sketching
- Sketch by Bohemian Coding is amazing for creating wireframes
- Photoshop is my go-to app for visual design, sometimes I fire up Illustrator for iconography
- InVision gets daily use to collaborate on designs at all stages
- Marvel, Proto.io and Pixate for prototyping
- Lately I’ve been using GitHub to track issues and manage projects
- I’ve used Basecamp, Jira and RedBooth for project management
- UserTesting.com for remote unmoderated user testing
- Voila to record and edit screencasts from usability testing sessions
Thanks for reading about my design process! I’d love to hear your feedback about this post and my design process, or discuss how other folks structure their process when designing software products. If you found this post to be helpful in any way, I would appreciate you sharing it with your followers. Cheers!
