Making Software that Users Love to Use

Scott-Maxwell-500 by

I just read yet another article complaining about a software user experience. It has been an issue since the beginning of software and will probably be a perpetual issue. Measured in decades, the user experience and software has gotten significantly better…anyone who ever interacted with a computer using punch cards, command line interfaces, or pretty much any interaction prior to graphical user interfaces will understand this point clearly.

That said, every interface can get much better and a great user experience helps with competitive positioning and in creating competitive advantage for an ISV. In our experience, the core issue is that the User Interface and User Experience design are separate thought processes, separate activities, and separate specialties from other product and development activities, but software development companies are not treating them that way.

The problem that most emerging growth companies have is that a founder or senior development head really enjoys tinkering with the user interface and user experience even though they can only devote limited time to the activities and in many cases have no training or formal experiences with the best practices in user experience design. In many cases, the user experience design does not even include the basics of developing very clear use cases, prototyping and user feedback of the prototypes, let alone the more advanced user experience practices.

As OpenView Venture Partners gets involved with expansion stage companies, the development units generally have all of the product and development processes and people contained in a single unit, including all of the product management processes, user interface, user experience design, as well as the engineering and development implementation processes.

Our advice to the companies is to start systematically separating the different processes and people into more specialized positions and groups so that each methodology can be separately brought to best practices, which will both create better software and allow the product and development effort to scale better.

The ideal (high level organizational) result from our point of view (which depends a lot on the product and development team’s size and stage of development) is to separate out:

– Product Management, whose overarching role is determining the best products and feature/function to address the target user segment (this includes the work of determining the right target segment, getting a great understanding of the product that will create a competitive advantage for the company, and translating the product from “user space” to “developer space” which generally means a prioritized product backlog that has been sized by the development team).

– User Interface/User Experience design, whose overarching role is determining the best touch point design for the users (including things like graphical elements, information architecture, and generally what happens with each user interaction with the software based on a lot of user research, prototyping, and user interaction observation as well as great skills and user sensitivity).

– Architecture, engineering, and implementation, whose overarching role is expressing the design into well functioning bug free software while working to remove impediments and increase the team’s velocity.

– Continuous integration, automated testing, and quality assurance (QA) specialties, whose overarching role is to completely evaluate the software and to get useful and complete feedback back to the developers as quickly as possible after the developers have completed each chunk of code.

For clarity, these distinct groups need to work together collaboratively and the distinction is not as sharp as I have written (i.e., it is not a “throw it over the wall to the next group” organizational model), but allowing each of these groups to have separate focal points and develop their specialties has a meaningful effect on making software that users love to use, and if the groups work iteratively with 2-4 week iterations, both the methodology and the software get better at an accelerating rate.

A lot of people would read this and say “this is obvious,” but what appears to be conceptually obvious is a struggle for every emerging growth company to implement…Once they implement parts or all of this, however, they do see the benefits and do create better software from the perspective of their users (which is the most important perspective that a company can have if they want to make software that users love to use).