As lead designer for the Portals project, this is the most comprehensive and encompassing example of my skills. Starting from the very beginning of the redesign, I researched, wireframed, prototyped, redlined, filed bugs, and iterated after the initial release.
The Portals Project
Allow companies to reduce customer service costs by allowing them to publish "self-service" portals, flexible enough to fit any potential customer needs.
Project Goal
Discovery: 3 months
Define: 6 months
Design: 6 months
Iterate: 1 year
Overall: 2.5 years
TimeFrame
-
Competitor Research
-
Ethnographic Research
-
Website Analytics
-
Survey Design
-
Mobile-First Design & Responsive Reflow
-
Wireframing
-
Mid-Fidelity Designs
-
Design Systems
-
Redlining
Methodologies
The Goal
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
-
A partner relationship management portal, where users could become "partners" with increased access, in addition to managing opportunities and orders
-
An event management portal, for companies to create websites for their conferences and events.
These portals were designed to be combined and interchangeable, with room to grow into further iterations.
The Challenges
With so many 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 on. I was truly starting from scratch.
The process
Research
Before diving into the design phase, I wanted more information about what I was dealing with. When Parature was acquired by Microsoft, I wanted to better understand how to incorporate our user base into CRM, and my first project was sending out and compiling quantitative information from a survey with 334 responses. From there, I had established patterns and built out a variety of personas for each role. I was able to leverage this existing research for preliminary insight.
Next, 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.
Wireframing
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, I decided to create a design system to have elements build on each other into a more complex system and help with developer handoff.
To keep things flexible for a variety of brands and use cases, I 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 met our goals, I "stress-tested" it by applying three different brandings that could be achieved through minor CSS changes and new images. After getting signoff 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.
LESSONS LEARNED
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.
Using consistent design rules in an early form of a design system also helped with team collaboration and delegation, as well as keeping design between portals consistent and making developer handoff easier. In previous projects, I had always had a general set of "rules" but formalizing the simpler "atoms" and building them into more complex components and eventually, layouts helped speed up the process and ensure continuity.
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.