Updating the User Profile on mobile

How do you use the profile area to drive engagement?

Why Did I Prioritize This?

Our original design did not adequately take into account the real world use cases we were seeing. Above the fold content was often static or formatted badly. I felt that we could improve time spent in app and user interaction with a new design.
In addition, our developers were complaining that technical debt had built up from piecemeal iterative additions that had occurred over the previous year.

Problems To Solve

  • In order to improve our registration funnel, we’d progressively moved toward a delayed registration model, so users could see our product before giving us personal information. Consequently, new users' profiles now appeared sparse.
  • The profile should look and feel equally good for those who have lots of content and those who do not. Initial designs seemed geared toward the ‘perfect’ user who fills out all their info.
  • The profile should be a place to learn what makes a user unique and to encourage interaction.
Original Look with typical problems

The Solution

I began with a competitive analysis, studying the profile sections of other social networking apps, noting how competitors addressed things like empty states, user content, interaction, and messaging.
Then I took a closer look at our own solution on different sized phones and tablets, noting the usability and aesthetic issues that cropped up in real world use.

Then I began blocking out structural ideas in Sketch, looking for ways to compartmentalize less important information. A series of small improvements over time had jumbled the hierarchy of content.
Moving quickly, I iterated through multiple concepts, then whittled them down until I had a set of seven structural ideas. Then I fleshed out the design of each one. Every brand had its own established color scheme which mapped to a fixed set of color IDs. I worked hard to avoid adding new ones to the schema.

At this point, I created InVision prototypes and talked solutions over with the designers on my team as well as the head of engineering and other folks in the company. From this, I received solid feedback on usability and technical implementation. I strove to get as broad an in-house response base as possible.

Eventually, the designers on my team, the head of engineering and I had a solution we hoped to move forward with. However, since this would be a major visual change, we needed buy in from stakeholders and the CEO. I'd seen other projects get torpedoed when stakeholder concerns bubbled up to spook the collective mind. My job was to produce demonstrable results every sprint, so I did not want that to happen.
Consequently, I wanted to be sure we had a minimum-viable-change solution to our problem set as well as the more radical change we hoped to implement. Our team’s morale would suffer if nothing were approved and we had to start over.

At the stakeholder meeting, I discussed the nature of our problems and the competitive environment. Then I progressed through possible solutions, explaining the manner in which each one solved our problem set. After discussion and a few notes, I received approval for our desired design from the CEO.
Then I fleshed out the remaining screens in Sketch, working to map out empty states and the manner in which we would ask users to complete their own profile.
I wrote the Product Requirement Docs, and worked with the head of engineering to add our tickets to the cross-functional teams that would work on the project. In so doing, there were analytics calls to be defined and functional diagrams to create. Development of the entire project would take more than one sprint, so our redesign was broken into segments.
Competitive analysis
User's view of empty states

The Result

Have not received analytics yet, but the web and mobile experience is consistent and unified, and more individual content is now viewable on landing.