Design

We began working on with quite a clear idea of the problems we wanted to solve and how the product would fit in to the ecosystem of enterprise workflows, social media, marketing, and smartphones. This gave us the architecture that our product should fit into, and defined the shape of a solution that would be familiar enough to encourage adoption. A PWA Admin interface for the social media managers, and a smartphone app for Talent.

Admin Interface

This was my first experience of an entire admin interface, so I was pretty excited to get started. Having an attitude of “design to learn” seems to have been useful here, as it kept experiments open ended enough to continually accelerate the process and then next flow or screen I’d design always started better than the last.

It was also the first time I started by prototyping in HTML. Starting from a library of common admin interface components and pages allowed us to get 80% of the way to a working solution with 20% of the work. It also allowed us to get very close to an MVP and use this as a robust starting point on which to iterate.

Seeing HTML prototypes early on with sample data and working navigation really crystallises what changes need to be made to the Information Architecture, what flows should use common components, what patterns may be familiar, and how we can get the data required to run the app. It really forces holistic, system thinking from the start which has proven to be hugely beneficial down the line in terms of aiding development of new features that can build on and tweak existing components and patterns.

Of course, it also gave us a big head start with font-end dev.

HTML prototype of the admin (left) and current admin interface (right)

Mobile App

We knew early on that there would be 4 key areas of the app that would cover our use cases:

  1. Share: Talent would find a feed of requests to share official content to their own social media accounts.
  2. Make: Talent would be asked to create content that could be used by the official social accounts of their show, and repurposed for marketing assets.
  3. Assets: where they would have access to photos, videos and GIFs that they could share and use spontaneously.
  4. Chat: for support using the app and anything else.

We also had two priorities in the first phase of design — bring familiarity to a new concept, and make the app feel trustworthy, secure, and private.

Early sketches considering what data could be useful in the app, and what familiar components could make sense.

This led us to begin by experimenting with what existing patterns could be adapted to work for our specific use cases. We used the idea of a feed for share requests, tags for sorting assets, an inbox style layout for make requests and a dark interface to help give the impression of privacy.

Early designs for the Share and Make sections of the HailTo App

Not much remains from these initial designs, as we simplified them to remove a lot of unnecessary clutter. We reduced the number of states used for components to avoid confusion, refined the layout and typography, and improved the information density based on how we thought the app would really be used.

Share section and Share details
Make section and Make details

Branding and Marketing

This was the most collaborative part of the project among the creative team at Storm Ideas. While I worked on some concepts, colour schemes, typography, and logos — everyone in the creative team made their mark on the project.

One of the key challenges was in clearly communicating the value of HailTo on the marketing website. Initially we used the slogan “Unleash your Talent” and created diagrams to explain the core functionality of the product. This has been continually refined to better show off HailTo.



Source link https://blog..io/designing-hailto-c08225062352?source=rss—-eb297ea1161a—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here