00:00:11.000
Hello, world!
00:00:12.120
Good morning! I'm Jessica Roper.
00:00:14.839
I'm a senior software developer at Spiceworks. We create software applications for IT professionals.
00:00:16.960
While this talk won't focus on that specifically, I do want to share what I’ve learned while working on a variety of products over the last five years.
00:00:24.279
I've had the joy of working directly with our clients and users, as well as collaborating with several product managers. Some projects have gone smoothly, while others have not.
00:00:30.640
Today, I’ll discuss how I’ve learned to build better applications from the start. Although this talk is a bit geared toward early career developers, these tips are still relevant for everyone in the field.
00:00:42.800
The key issues I want to address are feature creep, managing expectations, and avoiding lengthy design iterations. It’s crucial to prevent discovering fundamental flaws at the end of a development cycle.
00:01:00.920
I've personally encountered pitfalls, such as missing delivery deadlines by weeks or even months, receiving poor feedback from managers, and spending time on features that, in the end, were never used. These experiences taught me some essential tools and tricks to prioritize the most critical features.
00:01:20.920
I've utilized these strategies both individually and in teams of various sizes, which is why I believe they are applicable across the board.
00:01:57.640
To illustrate these tips, I’ll share an example project called the Sales Audience Sizing Tool. The purpose of this tool is to help sales associates understand how many users they can target with a product.
00:02:17.319
For instance, if we want to know how many users in Germany subscribe to our mailing list and have HP devices, it previously took our sales associates days to get this information.
00:02:40.219
They would send requests to a business analyst, who would analyze the data, run SQL queries, and return results 48 to 72 hours later. Our primary goal was to reduce this wait time from three days to just 10 minutes.
00:03:01.840
My first tip is to clearly define the problem before jumping into development. It's essential for everyone involved to focus on the same problem and target user.
00:03:05.720
For example, the requirements for a banking application for a manager differ significantly from those for a regular user. Each has distinct informational needs that impact product design.
00:03:13.960
Asking the right questions is vital. Do users need prior knowledge to use the product? What integrations or design conventions should we expect users to be familiar with?
00:03:26.400
In the Sales Audience Sizing Tool project, we aimed not to burden users with understanding complex data. The tool was designed to display information clearly and quickly. We even provided a brief training session before users started working with it.
00:03:42.560
Additionally, I recommend documenting everything, including features, user personas, and timelines. While I don’t formally require management sign-off, I consistently refer back to our documentation throughout the project to ensure everyone is aligned.
00:04:02.200
The second crucial tip is to observe the user as much as possible. Seeing users interact with your product in their real environment offers invaluable insights into their daily challenges and workflows.
00:04:29.640
For IT professionals, interruptions can drastically impact their ability to focus. It’s important to understand that even simple tasks can take significantly longer due to these disruptions.
00:05:02.720
If direct observation isn’t feasible, use metrics or analytics tools to track user behavior and identify potential problem areas. This data can help refine features and enhance user experience.
00:05:21.680
In our example project, we initially observed the wrong user — the business analysts instead of sales associates. This mismatch led us to create a confusing interface that didn’t meet the actual needs of our target audience.
00:05:40.919
As a result, when we tested the tool with sales associates, they were baffled by questions intended for business analysts, prompting us to completely redesign the interface. This oversight resulted in unnecessary time spent on revisions.
00:06:07.840
My third tip is to focus on the majority. It’s common for clients to voice their desires for extensive features, but often these requests are unnecessary for a majority of users.
00:06:30.000
At Spiceworks, we apply the 80% rule, concentrating on features that benefit at least 80% of our user base, prioritizing solutions for widespread problems. This method helps balance user demands with our development capacity.
00:07:01.200
While discussing our tool for sales audience sizing, I would ask account managers how many other accounts would benefit from a requested feature, allowing us to gauge its broader applicability and prioritize accordingly.
00:07:35.520
If a feature only benefits a handful of users, it often helps clients value the reasoning behind prioritizing more impactful features for the broader audience.
00:07:58.400
You may not always have direct access to users, so researching industry standards and competitor features can help identify common needs and gaps you may address with your product.
00:08:19.079
Moreover, analyzing product usage data can reveal features that are critical for user experience, as well as ones that generate little interest.
00:08:47.360
The next step is to prototype with users. Jumping straight into development can be tempting, but iterating designs and gathering early feedback can save countless hours.
00:09:05.200
For the Sales Audience Sizing Tool, effective prototyping might have simplified the user flow and highlighted potential confusion before extensive development.
00:09:25.600
Low-fidelity prototypes allow for quick iterations and feedback collection, focusing on the user flow rather than the exact visuals. After testing with five users, commonalities typically emerge in their feedback.
00:09:44.740
If real users aren’t viable, obtaining input from colleagues or even friends can yield valuable insights.
00:10:03.000
The first kind of prototype is low-fidelity and low-functioning. This type doesn't look like the final product and is typically not interactive. Paper prototypes are a good example, enabling you to observe user interactions and adjust based on their feedback.
00:10:26.000
Next is the low-fidelity and high-functioning prototype, which provides basic interactivity while still not resembling the finalized product. Wireframes serve this purpose well, focusing on usability rather than aesthetics.
00:10:53.200
High-fidelity and low-functioning prototypes emphasize visual design but not functionality, which is useful when collaborating with stakeholders who prioritize appearance. This phase involves fine-tuning aspects like color and spacing.
00:11:22.800
Finally, high-fidelity and high-functioning prototypes are closely aligned with the final product in terms of design and some basic interaction, though they don't have real data. These prototypes are excellent for outsourcing work, as they clarify expectations with external programmers.
00:11:58.600
The next piece of advice is to under-promise and over-deliver. For instance, if a project requires eight weeks, communicate a timeline of four weeks, which helps maintain the perception of reliability in your work.
00:12:29.360
At our company, we have a rule that doubles the estimated development time to account for testing and bugs readily. This helps mitigate unforeseen challenges and outcome disruptions.
00:12:56.360
Whenever we encountered delays due to data corruption or other problems, we felt the added time would have prevented chaotic scenarios of scrambling to meet deadlines.
00:13:32.480
If you find that you've overestimated, you can introduce bonus features that no one expected, elevating your reputation instead of being late.
00:14:06.000
Creating a feedback loop is also crucial, whether at the beginning or end of a project. Collecting user feedback via online forums for feature requests helps gauge interest and prioritize development more effectively.
00:14:33.000
Tracking usage data also helps ensure that your development aligns with user behavior. For example, monitoring page views and search actions can inform future iterations based on user confusion or interest.
00:14:57.740
Google Analytics can provide insights into user sessions and flow, which can help assess whether users are finding value in your tool.
00:15:29.680
Finally, speaking to users who uninstall your tool can provide insights into challenges they faced, which can guide your future improvements.
00:15:42.480
To summarize, I've covered several crucial elements, including setting clear expectations and timelines, clearly defining problems, and prioritizing user needs. It's vital to under-promise and over-deliver as this promotes better stakeholder relationships.
00:16:19.480
Understanding user feedback and adjusting features based on majority needs ensures you remain on track to meet user expectations and timelines.
00:16:38.960
Iterating efficiently through designs and employing prototyping techniques saves development time and enhances final product usability.
00:17:01.720
This is not an exhaustive list, but these strategies have been instrumental in refining my development workflows, improving accuracy in timelines, and easing communication with stakeholders.
00:17:30.320
By understanding where to focus efforts, I can avoid dedicating extensive time to less impactful features.
00:17:48.160
I encourage everyone to pursue these methods to foster better project outcomes. Now, are there any questions or further tips you’d like to share?
