A technical expert's guide to software product design
When initiating a new project, there are a number of dos and don'ts when it comes to software product design you need to be aware of.
In the last article, we witnessed the power of user stories to form the basis of end-user value in your mobile app. There's admittedly a lot of water to go under the bridge before your app makes it live in the app stores, so what's the next step in releasing your awesome app? This article will walk you through software product design, a critical process that is largely mysterious to technical folks. We'll take the perspective of an engineering manager who is not an expert in interface design, but is well versed in software development best practices and mobile platforms.
A useful and attractive user interface defines an app's core user experiences and supports the end goal of delivering end-user value. As a specialist in technical aspects of app development, you may be asking yourself, "What role could I possibly play in software product design?" It's a fair question, and it turns out you must make an active and critical contribution during this process.
Provide time estimates for building out the design. This task is critical for product, marketing, sales and executive stakeholders.
Engineering dos and don'ts in software product design
First, let's describe what is not part of a technical specialist's role in the design phase of building an app, so we have a clear idea of what we can safely leave to other domain experts:
- Don't design the user interface. Detailing or drawing the screens, UI elements and workflows necessary to drive the functional end-user activities is a design task and very likely not your core competency.
- Don't opine whether or not a design is good. Although there are a couple of caveats here that we'll cover later, the design team is accountable to project and executive stakeholders for designing optimal user interface elements and user experiences that define the app.
- Don't determine whether the design is delivering on creating end-user value. This is an interesting topic of conversation between product and design that you would do well to listen to, but again, is not likely one of your core competencies.
With the don'ts out of the way, let's take a look at the valuable contributions you and your team can make:
- Provide time estimates for building out the design. This task is critical for product, marketing, sales and executive stakeholders to understand the timeline and costs of undertaking new product development.
- Provide technical feedback on the designs. This can range from ways to simplify the development of the app by making changes to designed workflows that provide similar behavior with much less engineering effort to identifying reusable components in the designs.
- Identify edge cases. The design team is unlikely to know the system architecture or transactional data structures with the capabilities and limitations that you know the code must handle. For example, has the design team accounted for all of the error conditions your data source provides such as no matching search results?
- Recommend taking advantage of mobile-specific capabilities. GPS location, sensor data, integration with other mobile services and similar device-specific capabilities can differentiate your product in the crowded mobile app market.
- Help the design team understand app usage patterns. Many designers come from a Web or graphic design background and may not be familiar with the typical or specific usage patterns of mobile app end users. You can likely provide advice based on real-world analytics for typical session times, how often a user launches your app and other patterns to help the design team hone workflows.
Now what?
Your engineering organization can make a big difference in product time to market, product quality and ultimately your company's return on investment, based on providing valuable feedback to the design team. Let's now take a look at how this goes into motion on an Agile team.
After the product specification and design are complete, it should be published in a known location with any necessary animations, drawings and other material that fully specifies what the engineering team should build. Then, your engineering team often will be tasked with roughly sizing the project. This is a natural point to provide some of the feedback covered above and helps your entire organization understand the scope of the proposed product development. Once the design is sized and the project development approved, it's time to start working in earnest to implement the designs.
User stories and their attendant designs will get scheduled into sprints. The development and design teams will need to openly communicate around the specifics of implementing the design such as interaction details, screen transitions, animations and layout issues on an ongoing basis. It's a good practice for the development team or the product manager to open tickets against the design to work out the inevitable issues that arise when implementing every last design detail. These tickets should be committed to by design as part of the Agile team to be resolved during a future sprint.
At this point, we're getting a little bit ahead of ourselves by talking about development based on the software product design. As a manager of a development team, you will need to take time with your team to discuss how all of the product designs and requirements fit together into a coherent built product. In the next article of this series on mobile application best practices, we'll cover the role, tasks and challenges present in software architecture.
What software product design pitfalls have your projects run into? Let us know.
Next Steps:
The difference between UI design software and manual coding
Ten good design elements
The rules of software design
