My job was to investigate, define, and establish the structure and practices that would work best for Jive and their chosen approach to software and web development. The UX group would also be primary product owners and designers, acting in the role of product management in concert with the product owners.
The stated purpose of UX at Jive was to “make Jive a meaningful company to its customers.”
The newly hired CTO of Jive was seeking out someone to build and lead a UX focus within Jive. The company was undergoing a positioning shift and was building out a large software development organization. As part of that initiative, the CTO wanted to start off on the right foot and build UX right into the new development org. and establish user-centered practices from the beginning.
Jive was starting from the beginning with an agile environment, going so far as to be a full time pair programming shop. The goal of the UX team was to research, test, define and design the products and incorporated features, and then build and deliver assets to the developers in rapid iterations. As a “ground up” effort, there were no real development habits or practices to “undo”, ie waterfall methods or the mindset of “adding UX as a resource.”
- No UX process existed
- No clear boundaries between UX and product ownership
- No company experience with Agile methods
As with any net-new strategy, the development organization had no real structure or process. Methods of how everyone was going to work were fluid and in constant experimentation, including my role as the primary UX contributor.
Another interesting challenge was my relative blank slate within Jive. Since there was no real existing development team or design, I was free to establish the UX process however it seemed best for Jive. This wasn’t as easy as it sounds, and there was quite a bit of trial and error on what exactly would work. Jive wanted to follow a practice of continuous deployment, so there were no roadmaps, release dates, or product lifecycles. That meant that UX had to deliver and continue to work in parallel with development, and also try to get out ahead with research, designs, and asset building so that we could provide more vetted and higher quality specs to the developers.
With UX being the entity that fulfilled a product management style role, projects had to be fed right away with ideas, features, and designs.
Project wall with user stories, development stories
The first task of the UX organization was completing a set of personas for everyone to share and agree on. This was my main concern from day one, if we started with personas everyone would have a shared understanding of the user-centered process we intended to follow. Even if the personas were a “version 1” and needed ongoing iteration, having them there as full size foamboard cutouts would constantly remind everyone we were a user centered organization.
The next task was to build a cursory style guide for the upcoming new products. As my purpose at Jive was to help start things out on the right foot, building this guide would help ease the demand for UI and interaction specifications and let me stay ahead of the process. As a secondary effect, the style guide also helped motivate and excite people with this “all new” look and feel that would help define the company’s new direction and future.
Project planning and feature “street map”
The inclusion of UX into the company culture at Jive established a strong presence of user-centered design from the start. Working right alongside the pair programming teams, the UX artifacts were welcomed and quickly integrated into sprint tasks.
Time will tell how UX moves forward. With the solid foundation of personas and a style and interaction guide, I think it will progress really well.