Flows, Fidelity, and Testing
Over the past quarter, we have been working to redesign the overall experience of the AT&T account management application. When we started, we gathered the pain points of the application by asking uses to express what they would like to do with the app, and what they were unable to do. This was done with actual users of the application, but also many points were taken from reviews of the newest releases of the applications on their respective app stores. Many people thought the app was confusing, or limited in functionality. While this seemed to be true, once working through the application, I found most of what people would like to do is there, but not displayed in an understandable capacity. The multitude of options and paths a user is able to take to get to the same screen is baffling. The application ultimately seemed to be trying to do too much for the way it was laid out. The hamburger menu is full of headings that lead to different spaces, and having the menu weighted on the right, while nice for some people, shies away from an accepted industry standard. Navigating through the application is tedious as it is simply a gui laid over a custom html browser optimized for mobile views.
What does all of this mean? It seems the actual user experience was not fully considered while the application was being developed, these pain points potentially rise from a lack of user centered design processes for the application. While undertaking the basic redesign of the application, we started by sketching simple mocks on sticky notes, just to show the flow and understand what would drive a user to move through the application to accomplish a specific task. This lead to the creation of the concept model (which is explained in an earlier post). From the concept model of the current state, I thought of what would make using the application a better experience. A few things came through for this; a simpler navigation scheme, less busy screens, and a smaller amount of functionality. The trade off in functionality gives a much cleaner user experience and removed much of the unnecessary fluff.
When I moved to creating the first digital prototype, I wanted to make a simple navigation function for the application. My idea was initially a hidden bottom menu, allowing for a larger viewing screen. Feedback on this was negative though, and the navigation should persist for easy access and simplicity of navigation. The sketches of this are below, they were in the rougher stages of sketching out screens, so the idea didn’t make it too far.
There were a lot of edits, and a lot of pointers of things to change in the following iterations. The next set was still pretty rough, and I didn’t do myself any favors trying to keep things within a small frame, but liked the idea of having screens where everything was laid out and didn’t need to be scrolled. Using Wroeblewski’s idea of the bottom navigation, I changed my initial system a bit to have a consistent icon bar on the bottoms of the different screens. These were the screens I did a first round of user test with. By and large the navigation went well, other than missing a few screens that felt necessary, I had only a few pieces of feed back on the overall experience. The user told me going directly from a plan change to a confirmation felt too final for changes or purchases. This was resolved in the next iteration. I learned that things should be well accessible and spaced with weights on the more important texts.
This set of screens was also when I was given feedback on the text sizes and buttonlessness of my buttons. They were quite small and not very articulated from the background of the application. My next iteration shored this up, and added the screens I felt were missing. This set below was also user tested with no hangups in navigating to complete the tasks requested. Of the user test in the first round, the same in the second commended the improvement of the visual style and ease of use. Which made me feel great.
The subsequent revisions have been more superficial, adding proper pop up menus, text sizes and coloring buttons to set them further apart from the background. The user test for these have gone over well, too. I’ve used my roommates for testing this whole time, and the best piece of feedback on the final iteration was that “it feels more fluid now.” Which was a nice confidence boost. By and large though, text still feels a bit cramped, mostly because I have tried to stay within a single screen size. Which overall was challenging, but also limiting, but I refused to let go of my first idea, and ended up holding myself back with that worrying more about formatting for clarity than a proper spacing for all of the text on the screen. Below are some shots of the main screens in the final pass.
During the time we have off, I plan on revising and testing more, to have a solid set of screens for the beginning of next quarter. I’m happy with them and they function as designed according to testing, but it still feels lacking. Doing this again, I would have to say I would certainly use longer screens to as not to constrain myself to a small size and try to normalize a text size and reposition after it’s been formatted once. I would also make grouped pieces and paste them to all artboards to have a well a laid framework throughout the application.