User Experience Portfolio
The following collection of work describes an outlook of user experience somewhat separated from the common visual design aspect. Each project will highlight a part of the experience that is truly a solution to a problem, versus a focus on a polished interface. To be clear, putting the final bow on a visually engaging product has importance but, it is only a part of the whole story.
Why do we check the weather?
If you ask this to many people, a common answer is to prepare for the day. If it's going to rain, we might need an umbrella. If it's going to be warm, I might not need a jacket. We check the weather on any of the current weather apps today and it tells us there's precipitation, or a number of degress that the high temperature will be.
If it's 60 degrees today, what does that mean? Is it hotter than it was yesterday? How can you tell? Most often, without looking up historical data, your weather app doesn't tell you. You have to remember how 60 degrees feels and if you need a jacket or not.
As a person getting ready to go out of my home, I want the weather to tell me how much it has changed.
The solution is very simple. We save the forecast data from yesterday and compare to today. If there's a signifigant change, we notify the user with the qualities that have changed and by how much. They can make the determination on what to do with that information (bring an umbrella, wear a jacket).
The interaction is a simple button that asks for permission to lookup the user's location (or optional postal code input), and the result is a link to their area's weather feed. A user subscribes to a notification feed for weather in their area and they'll begin getting notified of signifigant changes.
Sometimes a single button can prepare you to tackle the coming days better than you did before.Try out deltazeus
Sometimes people get paralyzed by choice. This is common in navigational patterns with many options that a user can choose from. If we instead consider removing some choices from the main navigation, users may direct themselves toward their goal faster, thereby creating a better experience. This project is an exploration on how much navigation can be removed to get to a very specific user need.
As a person getting ready to commute in New York City, I want to know when the next train is arriving for the line I take most frequently at my location.
The problem has a few asks; the user wants:
- The time(s) of the next arriving train
- For a specific line
- At their current location
A common solution would be to provide an app that allows the user to choose the line from a menu, choose the station that is closest to them and find the next arrival time from the given schedule. Oh, and don't forget what direction they will travelling in, that's another choice the user needs to make. How can reduce the steps?
We certainly can take out a step with geopositioning; the app can determine the closest station but perhaps we remove another step. However, can we remove the selection menus entirely?
Almost! The solution is to provide a dynamic URL scheme;
https://SUBWAY_LINE.willarrive.in that a user can favorite in their web browser where
SUBWAY_LINE is the number or letter that represents the subway to which the user needs the schedule. Examples:
The only selection the user needs to make is the direction they are traveling. Certainly, if the user is at a terminal, we can simply provide the only direction we expect them to travel in. For stations located in the middle of the line, even the most accurate positioning will be confused within a subway station with some direction from the user. This ask has very little congitive load, since the choice is presented as either this way or that way (eg: uptown or downtown, Manhattan-bound or Brooklyn-bound).
Removing choices for the user can mean the difference between getting to an appointment on time or seeing the doors close from a missed opportunity.Try out willarrive.in
One of the parts of the product development process that is often overlooked is quality documentation. So much time is spent curating the best experience or delivering performant code that many forget to provide resources into this task. Granted, it could be said that the best experiences do not require documentation but in the world of development, being verbose might mean more code.
To create documentation for engineers, it is often rewritten or curated as a translation from the source code. This takes time to edit and methods (eg: Markdown) have helped speed up the process but can we just use the code we've written as the documentation?
As a person writing code, I want to provide documentation without rewriting what was written as documentation.
The solution was a proof-of-concept to document the code within the code using JSDocs (ie: comments that live with the code) and having a process that runs to combine the commented documentation with the code itself. Examples are written as testable code to provide quality code coverage.
Enhancing the developer experience is important to keep focus on when creating performant quality products. This allows teams to move fast without breaking things and instead providing clarity for future collaborators.Try out DOM-Tricks