After a recent acquisition, Microsoft needed a way to integrate the recently redesigned Knowledge Base with the new portals, a customizable web interface to service the knowledge base, help desk, sales, community, and event management features of the product, while reducing costs for live support. A total of six default use cases were identified as the greatest need; a basic portal, a customer self-service portal for users to look up and solve their own issues, an employee self-service portal for employees to browse and troubleshoot internal information, a community portal for users to support each other via forums and propose ideas to the company, and a partner relationship management portal, where users could become a partner in addition to managing opportunities and orders. In the second release, an Event Management portal was added, for companies to create websites for their conferences and events. These portals could be combined and interchangeable, with room to grow into further iterations.
With five different use cases identified, each portal had its own set of personas to consider, from a portal admin to the end user. In addition, each of these portals could be combined and customized to fit any set of needs. These mix-and-match scenarios needed to be seamlessly interchangeable. This meant that in addition to ensuring each default user flow worked independently, each module needed to fit into the flow as unobtrusively as possible, and the applied theming was uniform throughout. Since the underlying portal structure was being rebuilt, this meant an opportunity to design the portals from the ground up; this also meant there was no underlying structure to base the designs off of. I was truly starting from scratch.
Before diving into the design phase, I wanted more information about what I was dealing with. I talked in depth with each of the project managers to fully understand the needs of each portal and who our target users were. Once I had a firm grasp on the requirements of the project, I researched popular trends as well as best practices in each industry. As I compiled the various examples, a total of four common layouts emerged, and roughly ten main common controls. I experimented with them, taking elements from each to best fit our scenarios.
As I watched the patterns emerge, I began to adapt these layouts into our use cases. Since all of these portals could be viewed on different form factors I used a "mobile first" approach. From my research, I found that users often view portals from their tablets and phones, and it is always easier to scale from phone to desktop than the reverse. By testing the wireframes I created for our various scenarios, it was easy to see which layouts were most easily adapted to each use case. These wireframes were also useful in doing quick-and-dirty user testing within the office. Since these were meant to be templates, it was important to ensure the layouts were adaptable to a variety of products and industries.
Prototypes & Mockups
Once the general flow and structure of the screens were laid out, and the reflow was proven to work at all sizes, I enlisted the help of a new hire to create a versatile theme that would work for each of the portals, in whatever industry they may be. This meant that any defining branding elements had to be easily swapped out. After some debate, we settled on a minimalist layout with strong typography to ensure the information hierarchy was clear to the end users, and lots of easily swapped out images that would allow our customers to add their own visual branding. In order to ensure this theme met our goals, we applied three different brandings that could be achieved through minor CSS changes and new images. After getting sign off from upper levels of management, we were ready to move forward.
Implementation and Redlines
Now that we had determined the theme for the portals, it was time to hand off to the developers to implement the designs. I made an inventory of all the layouts and controls on each page, so that I would only have to redline each element once. This way, I did not have to redline each page in the flow and instead, I could hand over my wireframes and the definitions for each component. As the developers worked, I kept an eye on the build to ensure they were following the design and made suggestions such as using the form-factor CSS classes built into Bootstrap to ensure proper reflow. If the devs came to me with an issue, such as not being able to implement a control within the timeframes, I worked with them to find an interim solution until the full design could be implemented.
Re-Theming the Portals
After the initial implementation of the minimal theme, a request from upper management was made to have more colorful and engaging visuals for demos. In order to achieve this within our original deadline, we collaborated with a vendor team to quickly create a variety of options. I molded these new visual styles to fit our flow and layout for each portal, and upper management signed off on the new feel.
As lead designer for the Portals project, this is the most comprehensive and encompassing example of my skills. Starting from the very begining of the redesign, I researched, wireframed, prototyped, redlined, filed bugs, and recently completed the next version, set to release this October.
The Portals Project
Over the past two releases I have been on this project, there were a great deal of successes and learning opportunities. As lead designer, I learned a lot about effective communication within a team - by understanding my team member's communication styles, I was able to better delegate workload and ease transitions for handoff. This came in handy when communicating the designs to the developers.
I also learned about managing late-state requirement changes. When upper management revised the prioritization of the goals from interchangeable one-size-fits-most to a colorful example of a fully customized site, I had to quickly adapt a new set of visuals to the existing user flows without threatening the release date.