SKILLS |  ILLUSTRATOR / VISUAL DESIGN / WIREFRAMING / PROTOTYPING / PRODUCT MANAGEMENT / INTERFACE DESIGN / EXPERIENCE DESIGN

This is easily my most exciting project to date. I was the sole product designer given the responsibility of designing the tool with which Rowan Technology would build the majority of its educational products in the future. These products include a digital update to West Point Military Academy’s History of Warfare textbook and a supplement to the US Army’s handbook on Leader Development. I worked with the COO of the company, project managers, was able to pull on internal resources, as well as external resources from the development company we contracted. It’s a project filled with the design, product management and systems thinking problems that I love.

Problem

When the project began, Rowan had an CMS that was built using a piecemeal approach, adding on features without a holistic design approach. This lead to a buggy and difficult to use product that generated substandard products. We needed to redesign the CMS from scratch, with a UX-centered approach. Rowan needed a tool to build products that was both stable and easy to use.

Process

“A tool to build products” is an extremely simplified way of stating the goal of this project. Everyone who touches a product at Rowan has a stake in the CMS and therefore has their own problem that needs a solution in the system. Designers need to be able to create dynamic layouts and interfaces, copy editors need to be able to view text in a focused way, content experts and stakeholders need to be able to view unfinished products without fearing that they might accidentally interfere with the work being done on that product. I became intimately aware of all of these processes by beginning with use research. I like to begin the process by gathering a large breadth and quantity of feedback. This time I did so by emailing all employees at the company and providing them with a google spreadsheet that they could add any specific requests they might have for features, as well as important tasks they need to complete using the CMS. In retrospect, a google form would have been a better solution, because it would have allowed me to get more pointed feedback by asking more questions and it would have avoided burdening employees with having to look at a large spreadsheet. At the same time, I contacted members of each department within the company: design, cartography, history, management, copy editing and scheduled in-person meetings where they could voice all of their grievances about the old CMS and walk me through all of their hopes and dreams for the one I’d be designing.

Many of the major needs that I found were connected to the ability of users to have complete control over text editing and formatting, including making universal changes to text styles, dynamically controlling the layout and adding “end note” links to the text wherever it is necessary to link to a reference. A more unique requirement is the ability for users to build “interactives”: standalone .html pages that use techniques like timelines and modal hot spots to provide an in-depth experience to highlight important topics in our products. Overall, it was important to the stakeholders that this be a WYSIWYG (What You See Is What You Get) editor so that as users are building a product, they have a good understanding of what the end product will look like.

Once I had a handle on the needs of my users, I broke down how the products that Rowan would be building with the CMS are typically structured.

The three main components are structure: how our end users navigate through the product; content: the centerpiece of the product which holds the majority of the text and guides the user through it; and assets: images, video and interactives that allow the user to take a deeper, more immersive dive into specific parts of the content. This, I saw could be reflected in the CMS, making it more understandable, and bringing the experience of building a product closer to using it.

At this point, we had brought a product architect from our development team into the design process in order to inform the upcoming development phase. Luckily, this product architect had extensive experience in product and UX design, and this process became enjoyable and extremely informative for me, as he shared his knowledge. He was even able to share a UX reading list with me, including Lean UX, which sparked my desire to read and formalize my knowledge of the UX process.

Now that we had a general idea of what the product would look like, and the needs of the users, we invested the time into creating a large-scale user-flow diagram  in order to see what the product would look like as a whole. Doing so allowed us to walk through all of the necessary workflows and insure that we wouldn’t miss any major pages in the system.

We also began building our user-story document based on my user research, breaking down needs into outcomes, avoiding the trap of the solution-focused feature list. This was an early list, which we knew would have to be iterated on, but it would guide design and future development.

From there, we dug into each page, wireframing each one collaboratively with the product architect, stakeholders, and, when possible, developers in the room. We initially did this using a whiteboard. This was a challenging and educational process, but it allowed us to vet designs while using the lowest cost-solutions and weed out problematic interfaces. From there, I developed interactive wireframes using UXPin, which allowed me to validate interactions with stakeholders before development began.

 

 

Once these wireframes were tested, I began working with a visual/UI designer to refine the visual language of the product. I was able to resource this designer to create a style guide, and later on to create pixel-perfect designs.

 

At this point, the designs were handed off to the development team and I shifted into a partial product management role, meeting with the product architect on a weekly basis, communicating on slack to clarify designs and interactions, and checking on progress. Unfortunately, a series of missed deadlines and communication issues eventually lead to Rowan terminating our relationship with this contractor. We have since invested in our internal development capacity and brought production of this project in-house. I continue my role as a product manager/owner, albeit with a much more hands-on and attentive approach. We launched a beta version of the product (dubbed the “Builder”) in the first quarter of 2016. Here’s a video of the current version in action. If you’d like to learn more about the products created with the Builder please contact me directly.

Conclusion

There were many, many lessons learned from this project. The most glaring, was that I shouldn’t be lulled into a false sense of security by a positive relationship with a contractor or any outsourced team. Had I been more involved in the daily standups and other meetings with the development team, I may have seen signs of their problems earlier and saved my company the headache of  2 month’s worth negotiations and a delayed product launch. Luckily, I’ve had the chance to improve with our internal development team. I also learned a lot through working with a more experienced UX designer/product architect, specifically the value in continually educating myself in the UX profession. Overall, this project has made me a stronger designer and allowed me to expand my knowledge of UX.