As the author eventually understands— users almost always want the features they ask for, but they may not the interpretation of them you've created.
I recently started working in design after being a developer for more than a decade. Back then, planning how things should work for users felt frivolous compared to coding. Beyond that, getting working code in the editor just felt so good that I never wanted to put it off. These are the excuses I'd make to avoid really thinking about the users:
- I can clean up the interface later
- I'll figure out what features I can support when I figure out how it's going to work
- I've got a good intuitive sense of what would be most useful and how people want things to work
Unless the tech requirements are extreme, knowing what features are helpful and how users will use them should inform development— not the other way around. Also, overestimating your understanding of how people want something to work almost always leads to suboptimal results. Unfortunately, this mindset led to clunky, miserable interfaces that many people rejected. Worse, core users would learn to love it because they had no choice, and they'd develop bad UI Stockholm syndrome. Nothing carves a lousy user experience into stone for all future users like reliable core users demanding nothing changes.
Obviously, solo intern projects are an edge case, but this case study perfectly illustrates the necessity of user-focused design is in software projects. All the better if you can find someone who specializes in it.
UX expertise brings:
- deep experience reasoning about the way people use things
- knowledge of many workflows, working styles, and personalities
- understanding of how much deviation users will tolerate
- familiarity with user research techniques and their shortcomings
- ability to distinguish between research signal and noise
- knowing where to dig deeper or seek more data
- understanding what needs to be prototyped vs. mocked up vs. textually described for tests, and ideally the ability to do all three
That perspective built into this project from the beginning would have completely changed its trajectory. Users would be less irritated, and the developer could have used wasted rewrite time making a more valuable end product.
I recently started working in design after being a developer for more than a decade. Back then, planning how things should work for users felt frivolous compared to coding. Beyond that, getting working code in the editor just felt so good that I never wanted to put it off. These are the excuses I'd make to avoid really thinking about the users:
Unless the tech requirements are extreme, knowing what features are helpful and how users will use them should inform development— not the other way around. Also, overestimating your understanding of how people want something to work almost always leads to suboptimal results. Unfortunately, this mindset led to clunky, miserable interfaces that many people rejected. Worse, core users would learn to love it because they had no choice, and they'd develop bad UI Stockholm syndrome. Nothing carves a lousy user experience into stone for all future users like reliable core users demanding nothing changes.Obviously, solo intern projects are an edge case, but this case study perfectly illustrates the necessity of user-focused design is in software projects. All the better if you can find someone who specializes in it.
UX expertise brings:
That perspective built into this project from the beginning would have completely changed its trajectory. Users would be less irritated, and the developer could have used wasted rewrite time making a more valuable end product.