Category Archives: MICROSOFT

WINDOWS APP STORE / CUSTOMER FEEDBACK




Windows Store App Publishing Platform.
Microsoft was feeling pressure from Apple regarding their App Store. Microsoft made the business pivot to modernize its own Windows OS and build an App Store to compete with Apple. I was hired to be on the Windows 8 design team and relocated to WA.

Lead UX designer for the first public release of the Windows 8 App Store publishing platform. Responsible for adopting the Metro Design language and many core feature e2e experiences.

The Experience Design Research (XDR) team’s core responsibility was modernizing Microsoft Windows OS. Each designer had a researcher counterpart to conduct deep customer research and to validate a scenario. Designers would prototype an experience, and research would bring customers into mirrored, fully furnished rooms with eye-tracking software. Within 5-10 customer interviews, I would receive a full breakdown analysis report. Viewing and listing customers talk about the experience gained valuable insights. One of Windows’ principles was “Change is bad unless it’s great.” We used this principle to move forward with development

APP ONBOARDING PAGES
Responsible for shipping the app submission onboarding workflow pages to publish a Windows Store App for free or a paid download.



Customer Feedback Feature — From the App Store, a customer could have two-way conversations with the App Developer by allowing the customer to send a private message. The goal was to help developers improve the quality of the App. I prototyped the idea and pitched this leadership as an innovation to improve product experience.

The Insights – From my own experience publishing Oscar’s Adventure as an early adopter, I received a few negative comments. I would have liked to be able to respond to customer feedback.

· Reduce the amount of negative app feedback shown in the app store.
· Reduce the perception of poor Windows App Store becoming a bug triage location.


The concept – In the Windows App store, a customer can communicate directly with the developer and get real-time customer feedback under Ratings and Reviews. From working with researches this made me think of could this be done through software.

Problem Statement – The Windows App shell/SDK (tech stack) was still in early development, causing Apps to crash, which wasn’t necessarily the developer’s fault. App crashes were hard to test in the production world since Windows was in private beta mode, thus driving customers to write public feedback through ratings and reviews.

Business Partnership
Due to the number of images and time I could spend on the application, I orchestrated an advertising partnership with dreamstime.com. In exchange, I had full access to their entire illustration library. I also gave them splash screen advertising throughout each game transition. This was a significant business deal and a win-win for both parties.

Taking Initiative
While working on the App developer publishing platform, I was curious about publishing my Windows app and better understanding the customer pain points. I contacted a developer, and we agreed to build Oscar’s Adventure, a children’s learning app for ages 3-6. We successfully designed, built, and published the app in less than a month. The process helped me understand the customer journey, enabling me to influence product decisions since I was a customer.

Oscar Sketches – Some early concept sketches of Oscar the Otter to the final .svg variations.





WINDOWS OS – DIGITAL TRANSFORMATION


WINDOWS – Metro Design Language
When I was on the Windows Design Team (XDR), the team was on a mission to re-image every customer touchpoint digitally for the Windows OS and Web Apps. Part of the team’s responsibility was to introduce the Windows 8 Design Principles and Metro Design Language as the foundational building blocks to modernize the system patterns, and I was able to leverage the UI Kit library elements for the Windows Developer Platform.

The Vision
Through consolidation, Microsoft can build an App Store marketplace by supporting various technology platforms. A newly re-imaged App dev center could onboard Windows XAML apps, Xbox, Win32, Web Apps, and Android through a unified ingestion pipeline.

The Insights
Apple leads the industry with great design, and the Windows organization was pressured to attract the cool kids back to stay relevant. The chatter is that if Apple allowed its OS system to be installed on any PC hardware (hypothetically), how detrimental could this be to Microsoft’s Windows OS cash machine?

The Beginning – Design Challenge
When I joined the Windows App Store team, a product manager from the India Development Center (IDC) presented me with a PowerPoint concept deck showing the dashboard. I spent the next few years art directing and influencing product decisions while working with the remote team.



APP ANALYTICS / KB API SYSTEM




App Analytics – Dev Portal
After completing the development platform, I was moved to the App Analytics team. The Developer Platform needs a way to measure App Analytics, and I was responsible for designing the first App Analytics application journeys. The team wanted the App data to be transparent so marketers could see their application’s success.

App Analytics – Pivot Pages
I shipped all the supporting analytics pages in less than a year. The platform has various key App analytics pages, including Downloads, Usage, Purchases, Conversions, In-app Purchases, Financials, App Quality, and In-App Advertising. The data needed to show analysis/insights on a much more granular level, including source path tracking, store listing pages, Store spotlight pages, and Social references, while aggregating the data from top locales.

Metro UI Kit – Loading Spinner
My contribution to the Windows 8 Metro UI kit was the loading spinner. The original 8-24-bit (.gif) loading spinner was dated technology. I partnered with a dev 1:1 to update the dated loading spinner with the new Windows 8 (OS) operating system loading spinner. Millions of people have seen the Windows 8 loading spinner for the web at one time.





MICROSOFTS DIGITAL TRANSFORMATION


WINDOWS – METRO DESIGN LANGUAGE
When I was on the Windows Experience Design Research Team (XDR), part of the team’s mission was to digitally reimagine every customer touchpoint for the Windows OS and Web Apps to modernize those experiences. The entire Windows Design Organization was responsible for introducing the Windows 8 Design Principles and Metro Design Language as the foundational building blocks for modernizing the Windows ecosystem.

App Analytics – The Beginning
After designing and shipping the app developer platform, I created the initial style guide for all histogram charts, including Line, Area, Bar, and Pie charts, to be used across the platform.

Design Challenge
When I joined the Windows Store Dev Portal, an India Development Center (IDC) product manager presented me with a PowerPoint concept deck showing the dashboard and described the vision. I spent the next few years art directing and influencing product decisions while working with the offshore team. The other change was having to refactor the systems library UI kit. At that time, Microsoft didn’t have any prebuilt react component libraries. We had to build the systems library besides building the technology. Luckily has already worked on the framework Windows Metro Design Language.





WINDOWS (XDR) RESEARCH CASE STUDY


Windows Apps API Documentation
To personally tailor our documentation to the developers’ needs and requirements, thus improving app quality. Let developers set their preferences so the developer documentation can deliver an experience that meets their individual needs, regardless of whether they are first-time visitors or have been developing on Windows for 10+ years.

Re-architecting the navigation would increase productivity and reduce developer frustrations. Developers will have more time to focus on important tasks such as writing code, instead of spending extra time scouring search engines, hubs, blogs, and MSDN looking for software APIs.

Navigation starts with the Superset/Subset filter controls. A drop-down menu is used for the Platform, and the other is for the Presentation model. The initial version will include the Windows 8 App platform using the following presentation models JavaScript, HTML5, XAML, and DirectX.

Conceptual Overview
My proposal is a complete redesign of the navigation and functionality based on filter controls (drop menu) + Subset controls + Hide/show disclosure triangles. The outcome is a complete overhaul to a dated tree model structure and the use of modern web controls. In a world of object-oriented programming, the tree navigation model (Parent/Child nesting) is unintuitive for development, especially when the associated (siblings) APIs drop out of context.

In the proposed new navigation tool, the APIs seamlessly bucket together and vertically grouped. A dev can expand and scroll through every level of the TOC without navigating up or back down – all while using fewer clicks and keeping corollary APIs visible and clickable. I built POC prototypes to present concepts to internal developers to validate the model UI model.

Concepts & Prototypes
Supersets/Subsets: When a filter is selected, the navigation control loads associated namespaces (the primary subset). Then when a namespace is selected, the APIs within that (the secondary subset) are displayed, so that the secondary subset is based on the Primary selection:

1. Namespace – Primary subset
2. Classes/Objects – Secondary subset
3. Members – Tertiary subset
4. Corollary – Additional Reference

Comparison with existing tree UI navigation model: The following diagram shows the current model and the new model side by side. In the current “tree” model, you have to expand parent nodes if you want to see neighboring (aka “corollary”) APIs. The expander must be clicked every time you load a new page. Many developers are unaware that the expander exists; without it, you must navigate up a level (reloading the page) every time you want to see APIs alongside the one you landed on.

Top Customer Pain Points
The current reference section TOC frustrates developers and hinders the development process. As hundreds of APIs continue to come on board, the TOC will grow and the current tree UI model will continue to be cumbersome for developers trying to find specific APIs.

P1 – I need the Dev Center to retain basics about my dev environment
P1 – Show me related classes, properties, and members without losing context
P1 – Context is lost if levels are hidden and neighbors as reference
P1 – I want to sort/filter APIs by language
P2 – Currently fixed page width is restrictive due to lengthy documentation

Developer Research Feedback
1. I wish the Dev Center could retain basics about my dev environment, and when I search for content, the site should reflect the primary language I use.

2. Need the ability to filter on platform development – I want to see related classes, properties, and members without losing context. The TOC control takes a lot of time to load and find related APIs.

3. Search results are not what’s expected – Searching for an application programming interface (API) often doesn’t land within the top search results. There is a lack of trust due to cross-site navigation doesn’t behave as expected.

On-Premise Field Research
I was lucky enough to have a dedicated researcher assigned to understand the developer’s pain points. First, I outlined two likely scenarios in the ongoing search for the proper API.

Developer 1 needs to identify and learn the right JavaScript API to accomplish a specific development task. He starts by investigating which API is right for his needs.

He’ll first search using keywords in Google until he finds an API that strongly resembles what he needs. He’ll then forage by browsing reference pages (and all related “See Also” pages) for sibling APIs to build a mental map of the API surface. Ultimately, Dev 1 wants to be confident that he’s using the optimal, best-matched API for the task. For example, in implementing a fly-out menu, Dev 1 reviewed related APIs to check whether the best solution may be a subclass of the API he was looking at.

Then, he’ll learn the API and follow the link from the API page to the applicable code samples, download them, and play with the samples to learn the API space – and confirm he’s indeed found the right API. About 80% of the time, he’ll find what needs to identify the right API and know how to use it through this strategy.

Developer 2 starts by finding the right class/API. When he isn’t sure what JavaScript API or class to use, he’ll start by typing stuff into Visual Studio to see whether IntelliSense helps him find it. But often, it just gives a list of every object available – this doesn’t help him.

If he can’t find the proper API or class using IntelliSense, he’ll next search his browser bookmarks (via autocomplete) and then search MSDN via Google. He’ll pick the class or function that looks highest-level or most relevant and browse through the QuickStart, Code Samples, and Guides to understand the API.

If it’s still unclear how the API works, Dev 2 looks harder for code samples. He’ll start with a Samples Gallery search, and if that doesn’t work, he’ll search through a downloaded .zip file of our code samples. If Dev 2 isn’t sure how to use the API to implement his feature, he’ll try searching Google and/or Stack Overflow more broadly. He’ll abandon implementing the feature if he still can’t figure it out. Dev 2 has also abandoned less essential features that would have added improvements to his app – such as a neat visual effect or transition – when it’s unclear from the online docs what he needs to know to implement them.

Improve Search – MVP
This section describes a typical usage scenario for a developer arriving from a search landing (parachuting in) on a deep API reference page and adding checkboxes to the navigation control to quickly and easily navigate to a different presentation API.


Overview & Scope: Windows store APIs are the backbone of any app. For Windows apps to be successful, developers must be able to quickly and easily find relevant APIs, thus improving app quality and speeding up development time.

Research: From developer feedback, the AppBar API control uses similar namespaces for two different platforms; devs are frustrated by not being able to quickly pivot to their type of platform from so many languages (VB, XAML, HTML, JS, C, Win32 + DirectX, etc.) when searching. Research validated that developers are confused by the MS namespaces and are not finding the appropriate APIs for their application.

Hypothesis: Developers have difficulty finding relevant code examples quickly. The dev content resources are spread over multiple sites, making it virtually impossible to find them. App quality suffers due to a lack of needed documentation. Plus, Windows has numerous dated support systems.